/irc-logs / w3c / #css / 2010-03-31 / end

Options:

# Session Start: Wed Mar 31 00:00:00 2010
# Session Ident: #css
# [00:00] <fantasai> stevez: handle the 2nd case when the author has changed the font-size
# [00:00] <dbaron> 4. Move towards replacing separate browser monospace font size prefs.
# [00:01] <fantasai> fantasai and stevez try to work through stevez's case
# [00:02] <dbaron> dbaron: Just set font-size-adjust: auto (or some other value) on the root element
# [00:04] * glazou BREAK...
# [00:04] <Zakim> -jdaggett
# [00:05] <fantasai> 3. Keeping exheights consistent throughout the document (requiring use of font-size-adjust) but wanting to set an exact size for the main document font without looking up the ex-height
# [00:05] * jfkthame also disappearing
# [00:05] <Zakim> -jfkthame
# [00:05] * howcome tests
# [00:05] <Zakim> -[Apple]
# [00:05] <Zakim> Team_(css)19:57Z has ended
# [00:05] <Zakim> Attendees were [Apple], jdaggett, +44.845.397.aaaa, jfkthame
# [00:05] <fantasai> e.g. Choose Palatino at 16pt, set font-size-adjust: foomatic
# [00:05] <fantasai> on the root
# [00:06] * jfkthame is now known as jfkthame|afk
# [00:06] <fantasai> and foomatic looks up Palatino's ex-height and set's font-size-adjust to that
# [00:06] <fantasai> so that Palatino's font size doesn't change from 16pt
# [00:06] <fantasai> *and* font-size-adjust takes care of ex-height adjustment across the document
# [00:06] <dbaron> The problem with foomatic is that f-s-a inherits.
# [00:23] * Zakim excuses himself; his presence no longer seems to be needed
# [00:23] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [00:23] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
# [00:31] * Joins: bradk (bradk@17.244.0.81)
# [00:35] <fantasai> Topic: i18n/bidi/ruby
# [00:36] <fantasai> Anne: HTML5 only includes simple ruby, which was implemented by IE
# [00:36] <fantasai> Anne: The module also has complex ruby
# [00:36] <fantasai> fantasai: I think Richard Ishida was planning to take that out of the CSS3 Ruby module
# [00:37] <fantasai> Anne: There was some discussion on www-international
# [00:37] <fantasai> Anne: It seems in general that the Japanese people think the simple model is adequate, because you can nest it
# [00:37] <fantasai> ChrisL: nesting is a hack
# [00:37] <fantasai> Anne doesn't particularly care
# [00:37] <ChrisL> s/is/was described as/
# [00:37] * Joins: paul_irish (paul_irish@151.203.209.194)
# [00:38] <fantasai> Deferring entire discussion without ishida
# [00:38] <fantasai> Steve: There's ruby that's attached to individual characters, and ruby attached gto groups of characters.
# [00:38] * Quits: paul_irish (paul_irish@151.203.209.194) (Client exited)
# [00:38] <fantasai> Steve: Different ways of attaching to characters, and that's where most of the trouble lies
# [00:39] <fantasai> Steve: I think we should wait and see what Richard's draft says
# [00:40] * Joins: fantasai_ (fantasai@17.244.2.198)
# [00:40] <fantasai_> Anne summarizes HTML5's rendering rules for ruby, which mostly defer to CSS by giving display types
# [00:41] <fantasai_> Steve: So most of the complexity on the ruby side comes from how you group the pieces
# [00:41] <fantasai_> and how you format across them
# [00:41] <fantasai_> howcome: Can you write CSS rules on the rt elements?
# [00:41] <fantasai_> Anne: The implementations so far have dedicated frame types in the rendering model
# [00:42] <fantasai_> howcome is asking if you can simulate ruby with existing CSS
# [00:42] <fantasai_> Alex and Steve think not
# [00:43] <fantasai_> SteveZ notes that there's a 96-page document that explains all the details
# [00:43] <fantasai_> by the JLTF
# [00:43] * Quits: TabAtkins (chatzilla@17.244.2.48) (Ping timeout)
# [00:44] <fantasai_> Steve: I think Richard is going to produce a new draft that is consistent with HTML and the JLTF drafts
# [00:45] <fantasai> Steve: The plan is to wait until he gives us a draft to look at
# [00:45] * Joins: TabAtkins (chatzilla@17.244.2.48)
# [00:45] <anne> http://lists.w3.org/Archives/Public/www-international/2010JanMar/
# [00:45] <fantasai_> Anne: Search for 'ruby'
# [00:46] <anne> thread on ruby: http://lists.w3.org/Archives/Public/www-international/2010JanMar/thread.html#msg107
# [00:46] <fantasai_> glazou: Arron told me we still have CSS2.1 issues to discuss
# [00:46] <fantasai_> glazou: Since there's nothing else we can move to this time in the day, I suggest we move to 2.1
# [00:46] <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-114
# [00:47] <fantasai_> Arron: I put all the results for the testcases
# [00:47] <fantasai_> ChrisL: I'm slowly converting those to SVG
# [00:47] <fantasai_> Arron: Each one of these testcases are slightly different. Several are parens/bracket/braces/quotes matching
# [00:47] <fantasai_> Arron: The first one is the most interesting, using invalid characters
# [00:47] <fantasai_> Arron: Trying to see if they match correctly
# [00:48] <fantasai_> Arron: There are lots of interop issues, but at least 2 impl for most results
# [00:50] <fantasai_> fantasai: I think we wrote the tests under the assumption that only nmchars are allowed in unquoted font names
# [00:50] <fantasai_> fantasai: brackets tests are more complex because they also test that they're matched correctly
# [00:51] <anne> 002.xht is fun
# [00:53] <fantasai_> dbaron: So, you're allowing idents, dimensions without + or decimal point, numbers without + or decimal point.
# [00:53] <fantasai_> Bert: you have to define in terms of tokens, not character sets
# [00:53] <fantasai_> Bert: Should allow periods
# [00:55] <fantasai_> dbaron: If we allow periods, we have the float round-tripping problem
# [00:56] <fantasai_> random discussion of various option
# [00:56] <fantasai_> Anne says we should just use ident+
# [00:57] <fantasai_> Bert says it's confusing not to allow numbers unquoted
# [00:57] <fantasai_> dsinger says it's reasonable to quote them
# [00:58] <bradk> FYI, the third test (Invalid curly brackets and pair matching) passes in a recent nightly download of Webkit, even though it fails in Safari. http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-003.xht
# [00:58] <fantasai_> general consensus that the discussion is going nowhere
# [00:59] <fantasai_> 1. identifiers only
# [00:59] <fantasai_> 2. nmchars tokens only
# [00:59] <fantasai_> 3. try to come up with a grammar to make the current prose more clear
# [00:59] <fantasai_> ChrisL: I need to take this back to the SVGWG and get feedback from them
# [00:59] <fantasai_> 1. http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html
# [01:00] <fantasai_> 2. http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
# [01:00] <fantasai_> 3. To Be Written
# [01:00] <fantasai_> Not By Me I Hope
# [01:00] * Quits: smfr (smfr@17.203.14.12) (Quit: smfr)
# [01:01] * Quits: wombat99 (jdaggett@110.4.186.83) (Quit: wombat99)
# [01:01] <fantasai_> FF and Safari are almost ident+
# [01:02] <fantasai_> or are ident+, but have bracket-matching bugs :)
# [01:02] <fantasai_> Opera is close to the current prose
# [01:02] <fantasai_> IE is somewhere in between
# [01:02] <fantasai_> but closer to Opera
# [01:03] <fantasai_> Anne: 1
# [01:03] <fantasai_> Steve: 1
# [01:03] <fantasai_> Sylvain: 1
# [01:03] <fantasai_> Alex: 2, but live with 1
# [01:03] <fantasai_> Beth: 2
# [01:03] <fantasai_> Bert: 3
# [01:03] <fantasai_> Arron: 2 or 3
# [01:03] <fantasai_> Elika: 2, live with anything as long as clear
# [01:03] <fantasai_> dbaron: 1
# [01:04] <fantasai_> Brad: don't care
# [01:04] <fantasai_> Tab: 1
# [01:04] <fantasai_> Tantek: Abstain
# [01:04] <fantasai_> Glazou: 1, but can live with everything
# [01:04] <fantasai_> ChrisL: 3, 2, 1
# [01:04] <fantasai_> Peter: 2 is slightly better for authors in that it would be a little surprising to not start with a number
# [01:05] <fantasai_> Peter: I don't like the fact that 2 introduces a new token type, so 1
# [01:05] <fantasai_> Bert: I think it can be done without
# [01:05] <fantasai_> Howcome: 3
# [01:05] * bradk just quotes whenever in doubt
# [01:06] <dbaron> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-002.xht is buggy because it has ( { ) and expects the ) to match the ( while you need to find a } first
# [01:06] <fantasai_> Elika: Actually, I'm going to change my vote to 2, then 1
# [01:06] <fantasai_> dsinger: abstain
# [01:06] <fantasai_> Steve: I can live with 2 also
# [01:06] <fantasai_> Steve: I don't really see much difference between 1 and 2
# [01:06] * Joins: smfr (smfr@17.244.3.222)
# [01:06] <fantasai_> Peter: My real preference is that people quote things more
# [01:07] <fantasai_> Steve: That's why I voted for 1
# [01:07] <fantasai_> glazou: Can't go further, Chris has to take this to SVGWG first
# [01:07] <fantasai_> glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone can live with everything
# [01:08] <fantasai_> glazou: which is cool
# [01:08] <fantasai_> ACTION: clilley Discuss font-family syntax with SVGWG
# [01:08] * trackbot noticed an ACTION. Trying to create it.
# [01:08] * RRSAgent records action 8
# [01:08] <trackbot> Created ACTION-216 - Discuss font-family syntax with SVGWG [on Chris Lilley - due 2010-04-06].
# [01:10] <Bert> (Minor flashback to 1996: font-face was modeled in part on Netscape's FACE attribute.)
# [01:10] <fantasai_> dbaron notes that Mozilla has seen only one bug, that dbaron could find, on this issue
# [01:11] <dbaron> I went through bugzilla.mozilla.org bugs with 'font-family' and 'quote'... there were 4 reported by users (also one internal code issue).
# [01:11] <dbaron> One was about this issue, two were complaining that font-family: 'sans-serif' didn't work, and one was complaining about font-family: 'Arial, Helvetica'; not working
# [01:11] <dbaron> The one that was about this issue was https://bugzilla.mozilla.org/show_bug.cgi?id=471300
# [01:12] * anne wonders why issue 129 is both resolved and has status set to discuss
# [01:12] * Joins: TabAtkins_ (chatzilla@17.244.0.185)
# [01:14] <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-163
# [01:14] * Quits: TabAtkins (chatzilla@17.244.2.48) (Ping timeout)
# [01:14] <fantasai_> dbaron: Anne, I don't understand why getComputedStyle is relevant
# [01:14] * TabAtkins_ is now known as TabAtkins
# [01:15] <fantasai_> Anne: http://dump.testsuite.org/2010/width-computed-value.htm
# [01:15] <fantasai_> Anne: If you set width: 10em on an inline, and then inherit it to a block, you get 10em
# [01:15] <fantasai_> Anne: But the spec says the computed value, the inherited value, should be 'auto'
# [01:16] <fantasai_> RESOLVED: Proposal accepted for Issue 163
# [01:17] <fantasai_> data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html lang%3D"en">%0D%0A <head>%0D%0A <title>Test<%2Ftitle>%0D%0A <style type%3D"text%2Fcss">%0D%0A <%2Fstyle>%0D%0A <%2Fhead>%0D%0A <body>%0D%0A <ul dir%3Dltr>%0D%0A <li dir%3Drtl>Bullet%0D%0A <%2Ful>%0D%0A <%2Fbody>%0D%0A<%2Fhtml>%0D%0A
# [01:18] <fantasai_> FF renders the bullet on the right
# [01:18] <fantasai_> as does Chrome
# [01:19] <fantasai_> Opera renders on the right
# [01:19] <fantasai_> IE renders on the right
# [01:19] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
# [01:19] <fantasai_> dbaron: So this is a proposed change where every impl we've tested matches the current spec
# [01:19] * Joins: alexmog (alexmog@17.244.1.2)
# [01:20] <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-162
# [01:20] <fantasai_> dbaron: Direction changes are a relatively rare case
# [01:22] <dbaron> ... especially in the middle of a list
# [01:22] <fantasai_> Daniel: If you have a <body dir=ltr> with <div display:list-item dir=rtl> then you wouldn't see the right direction for the marker
# [01:23] <dbaron> Yeah, I think this change seems wrong for the general display:list-item case.
# [01:23] <dbaron> Even if it might make sense for the way HTML li elements.
# [01:24] <fantasai_> Steve: the most obvious example I can think of this giving a list of phrases in different languages
# [01:24] <fantasai_> Steve: I'd want the bullets lined up
# [01:25] <fantasai_> dbaron: You don't want to change the block direction in Steve's case anyway.
# [01:25] <fantasai_> dbaron: Because the alignment will change
# [01:25] <fantasai_> Steve: Why can't I set text-align?
# [01:27] <fantasai_> ...
# [01:27] <fantasai_> Steve: I can't think of a case where you'd want the bullet on the right
# [01:27] <fantasai_> dbaron: You can have list items that are not using HTML list markup
# [01:28] * Quits: arronei (arronei@131.107.0.83) (Ping timeout)
# [01:28] <dbaron> http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
# [01:28] <fantasai_> Peter: so are we rejecting this then?
# [01:28] <TabAtkins> TabAtkins: As a side point, markers clearly belong to the list-item, not the enclosing block. The color of a list marker comes from the list-item.
# [01:28] <dbaron> ... says list items can float
# [01:28] <dbaron> ... and keep their marker
# [01:28] <fantasai_> Steve: What I've heard is that we're already committed that the marker is part of the list-item
# [01:29] <fantasai_> (Tab explained that concept using color etc as an example)
# [01:29] <fantasai_> (fantasai also pointed out that it would create an inconsistency with list-item-position: inside items if we swapped the direction of the bullet based on the parent for outside )
# [01:30] <fantasai_> dsinger: So we should resolve this and offer to i18n that we can add a note explaining how to get their desired effect
# [01:31] <fantasai_> RESOLVED: No change for Issue 162
# [01:32] <fantasai_> in normative behavior
# [01:34] <fantasai_> Bert and fantasai discuss ways to allow a switch in this behavior in CSS3, possibly using the bidi-isolate concept
# [01:34] * Joins: arronei (arronei@131.107.0.85)
# [01:35] <fantasai_> ACTION: fantasai move issue to css3-lists
# [01:35] * RRSAgent records action 9
# [01:35] * trackbot noticed an ACTION. Trying to create it.
# [01:35] <trackbot> Created ACTION-217 - Move issue to css3-lists [on Elika Etemad - due 2010-04-06].
# [01:35] <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-161
# [01:41] <TabAtkins> TabAtkins: [draws a picture with a containing block A, some number of descendants B, and a positioned descendant C. Any overflow on B has no effect on C, because A is C's containing block.]
# [01:41] <fantasai_> | In certain cases, a box may overflow, meaning its content lies
# [01:41] <fantasai_> | partly or entirely outside of the box, e.g.:
# [01:41] <fantasai_> | ...
# [01:41] <fantasai_> | A descendent box is positioned <del>absolutely</de>, partly outside the box.
# [01:41] <fantasai_> | Such boxes are not always clipped by the overflow property on
# [01:41] <fantasai_> | their ancestors. <ins>Note that absolutely positioned descendant
# [01:42] <fantasai_> | elements are not always clipped by the overflow property on their ancestors.</ins>
# [01:42] <fantasai_> dbaron: I thought the proposal was the replace the Such ... ancestors sentence
# [01:43] <fantasai_> fantasai: I think that makes a lot more sense
# [01:43] <fantasai_> apparently this was the original proposal
# [01:46] <fantasai_> Peter is concerned that "not always clipped" is unclear
# [01:47] <fantasai_> dbaron: I think the reason for the change from such to note is because we're removing absolutely from the first sentence
# [01:48] <bradk> "a positioned item is not affected by the overflow property of ancestors inside its positioning block."
# [01:48] <fantasai_> dbaron: And ambiguities in the second part of the sentence should be a new issue
# [01:49] <fantasai_> so s/are not always clipped by the overflow property/do not always cause overflow/ ?
# [01:50] <fantasai_> ACTION: Tab Rewrite proposal for Issue 161
# [01:50] * trackbot noticed an ACTION. Trying to create it.
# [01:50] * RRSAgent records action 10
# [01:50] <trackbot> Created ACTION-218 - Rewrite proposal for Issue 161 [on Tab Atkins Jr. - due 2010-04-06].
# [01:51] <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-160
# [01:52] <bradk> s/positioning block/containing block
# [01:52] <fantasai_> glazou: Melinda got it backwards
# [01:53] <fantasai_> ChrisL: Prefix the sentence with "For example", because Japanese top-to-bottom books start like rtl books do
# [01:54] <dbaron> css3-page says it the right way around in http://dev.w3.org/csswg/css3-page/#progression
# [01:54] <fantasai_> RESOLVED: Add non-normative for-example change
# [01:57] * dbaron wonders if the spec needs to change as a result of Håkon breaking his arm a few years back
# [01:57] <fantasai_> Proposal Fix 96px per inch. Whether inches fixed to reality or pixels fixed to screen res / viewing distance / something else may vary by UA. (Print would match real inches, screens tend to align with viewing distance and/or screen res.)
# [01:58] * fantasai_ is not minuting the discussion between peter and howcome
# [01:58] <fantasai_> Peter holds up his iphone.
# [01:58] <fantasai_> Peter: You are constantly zooming in and out on this device. There's no guarantee you'll ever get a physical inch for an 'in'
# [01:59] <fantasai_> SteveZ: You have the canvas, and the window onto the canvas.
# [01:59] * ChrisL considers writing a liaison to ISO saying we want to redefine the metre
# [02:00] <fantasai_> SteveZ: You have controls to change the window onto the canvas
# [02:00] <fantasai_> ...
# [02:00] <Bert> (The problem is not zooming on the iPhone, the pb is that a very small percentage of people thinks that it is illegal to use px on font-size. We just need to tell them that is not so.)
# [02:01] <fantasai_> dbaron: Are any other browser vendors willing to change their implementation to match the 'pt' unit to match physical 'pt' using monitor detection settings?
# [02:01] <fantasai_> dbaron: Everyone assumes 96dpi. So there's pressure on us to do that.
# [02:01] <fantasai_> Steve: It's all your fault Tantek.
# [02:01] <fantasai_> Peter: You and I had a discussion in an elevator where we agreed that Macs would use 96dpi instead of 72dpi
# [02:02] <fantasai_> Peter: And you showed me UI that would allow the user the ability to set an inch correctly by holding a ruler up to the screen, which was cool.
# [02:02] <fantasai_> Peter: I'm happy to give users that capability
# [02:03] <fantasai_> Peter: If the UA wants to have a zoom factor of Actual Size, then it can use the OS info to get the most accurate 1in == 1 inch rendering it can
# [02:05] <fantasai_> lots of conversations
# [02:05] * fantasai_ add to Peter's comment something about 10 years ago
# [02:06] <bradk> If the UA decides on having an "actual size" mode, and the monitor is not really 96ppi, then GIF images and such would have their pixels interpolated.
# [02:09] <ChrisL> "The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees. "
# [02:09] <ChrisL> http://www.w3.org/TR/REC-CSS1-961217#units
# [02:09] <fantasai_> Tantek talks about a meta-viewport problem
# [02:10] * dbaron wonders if he ever meta viewport he didn't like? :-P
# [02:11] <fantasai_> Alex: For Facebook, I found that in the virtual viewport the bar at the bottom was fixed-positioned, but you couldn't get to it unless you scrolled down
# [02:11] * Joins: paul_irish (paul_irish@71.192.163.128)
# [02:12] <fantasai_> Tantek: Shouldn't the meta viewport tag be a CSS thing, not a proprietary meta tag?
# [02:13] <fantasai_> Tantek: The exact problem that meta viewport solves, that should be in CSS
# [02:13] * Joins: paul_iri_ (paul_irish@71.192.163.128)
# [02:14] <fantasai_> glazou: What happens if you browse a meta-viewport page with Safari on the mac?
# [02:14] <fantasai_> smfr: It ignores it
# [02:15] <fantasai_> Anne, Sylvain: Meta-viewport is setting the size of the viewport
# [02:15] <fantasai_> and then the UA zooms in to that size
# [02:15] * Quits: paul_irish (paul_irish@71.192.163.128) (Ping timeout)
# [02:15] * Quits: jfkthame|afk (jonathan@95.150.118.177) (Quit: jfkthame|afk)
# [02:15] <fantasai_> Tantek: Most other mobile browsers display a page designed for mobile normally
# [02:16] <fantasai_> Tantek: But the iphone made it into this tiny box in the corner of the screen
# [02:16] <fantasai_> Tantek: Even if you do use a media query to select an appropriate styling, then it still doesn't behave appropriately
# [02:17] <fantasai_> Sylvain: It defines what a pixel is as a fraction of the viewport
# [02:17] * Joins: mjs (mjs@17.246.18.82)
# [02:18] <fantasai_> fantasai: So it's setting the size of the initial containing block
# [02:18] <fantasai_> fantasai: not the viewport
# [02:18] <fantasai_> smfr isn't sure
# [02:20] <fantasai_> Tantek: If I write a media query to serve appropriate style sheets for 350 pix, Safari scales the page down to a tiny thing in the corner
# [02:21] <fantasai_> smfr: That's a bug, and we have it filed
# [02:21] <tantek> http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
# [02:21] <fantasai_> fantasai: If we don't have a proposal on this, then I think we should close this topic
# [02:22] <fantasai_> dbaron: Did we have a resolution on the 2.1 issue we were talking about?
# [02:22] * Bert proposes a resolution: go after people who use pt in screen style sheets and threaten them with a hammer. :-)
# [02:22] <tantek> http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/html/const/viewport
# [02:23] <fantasai_> howcome: I want to see the proposal before deciding
# [02:24] <fantasai_> howcome: I think the spec already says this
# [02:24] <fantasai_> peter points out that it doesn't
# [02:24] <fantasai_> and we go around in circles again
# [02:24] <fantasai_> I'm so not minuting this
# [02:25] <anne> Bert, http://xkcd.com/386/ ;)
# [02:25] <fantasai_> Bert argues that we should evangelize the web
# [02:27] <fantasai_> Alex: In IE8 we tried matching px to in based on the resolution, and this broke lots of things so we changed back to pretending 96dpi
# [02:29] <glazou> aaaah PixaPowaaaaaa !
# [02:30] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
# [02:33] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
# [02:35] * dbaron predicted discussion of issue 149 would take the rest of the day back when we started
# [02:36] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-148
# [02:39] <dbaron> For issue 148, I'd like to figure out why we changed it in the other direction.
# [02:40] * Quits: sylvaing (sylvaing@17.244.2.236) (Quit: sylvaing)
# [02:40] * Quits: bradk (bradk@17.244.0.81) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [02:41] * anne can't find the email that corresponds to the change
# [02:41] * CSS-projector <br class="beer" ...>
# [02:42] * Quits: TabAtkins (chatzilla@17.244.0.185) (Ping timeout)
# [02:42] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
# [02:43] * Quits: smfr (smfr@17.244.3.222) (Quit: smfr)
# [02:44] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
# [02:44] * Quits: CSS-projector (apple@17.201.14.208) (Quit: IGI-0451I - Fortran PUFFT - Unrecoverable input/output erro)
# [02:45] * Quits: plinss_ (plinss@17.244.3.217) (Quit: plinss_)
# [02:45] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
# [02:46] * Quits: howcome (howcome@17.244.0.146) (Ping timeout)
# [02:46] * Quits: dsinger (dsinger@17.244.1.88) (Quit: dsinger)
# [02:47] * Quits: tantek (tantek@173.147.183.213) (Quit: tantek)
# [02:49] * Quits: dethbakin (dethbakin@17.244.1.101) (Quit: dethbakin)
# [02:50] * Quits: anne (annevk@17.244.3.72) (Ping timeout)
# [02:56] * Quits: mjs (mjs@17.246.18.82) (Quit: mjs)
# [02:57] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
# [02:59] * Quits: fantasai_ (fantasai@17.244.2.198) (Ping timeout)
# [03:16] * Joins: plinss_ (plinss@72.254.58.142)
# [03:23] * Joins: miketaylr (miketaylr@24.42.95.234)
# [03:35] * Joins: jdaggett_ (jdaggett@202.221.217.73)
# [03:50] * Quits: dino (dino@17.202.116.62) (Quit: dino)
# [05:26] * Joins: mjs (mjs@69.181.42.237)
# [06:05] * Quits: fantasai (fantasai@66.55.71.177) (Connection reset by peer)
# [06:05] * Joins: fantasai (fantasai@66.55.71.177)
# [06:06] * Quits: Curt` (DorkeyDear@76.241.90.62) (Quit: Leaving)
# [06:40] * Joins: glazou (glazou@173.200.179.65)
# [06:41] * Quits: glazou (glazou@173.200.179.65) (Quit: glazou)
# [06:47] * Joins: dbaron (dbaron@98.234.51.190)
# [06:47] * Joins: Arron (arronei@173.200.179.65)
# [07:03] * Joins: dsinger (dsinger@68.126.184.36)
# [07:08] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
# [07:16] * Joins: alexmog (alexmog@173.200.179.65)
# [07:17] * Joins: tantek (tantek@70.36.139.86)
# [07:17] * Quits: tantek (tantek@70.36.139.86) (Quit: tantek)
# [07:36] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [07:51] * Quits: plinss_ (plinss@72.254.58.142) (Quit: plinss_)
# [08:10] * Joins: TabAtkins (chatzilla@76.253.3.102)
# [08:15] * Joins: myakura (d2e8220d@64.62.228.82)
# [08:23] * Quits: myakura (d2e8220d@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
# [08:48] * Quits: jdaggett_ (jdaggett@202.221.217.73) (Quit: jdaggett_)
# [08:50] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
# [08:50] * Quits: Arron (arronei@173.200.179.65) (Ping timeout)
# [09:45] * Quits: alexmog (alexmog@173.200.179.65) (Ping timeout)
# [09:46] * Joins: alexmog (alexmog@173.200.179.65)
# [09:54] * Quits: fantasai (fantasai@66.55.71.177) (Ping timeout)
# [10:12] * Joins: lstorset (lstorset@213.236.208.22)
# [10:12] * Parts: lstorset (lstorset@213.236.208.22)
# [10:29] * Quits: alexmog (alexmog@173.200.179.65) (Quit: alexmog)
# [10:45] * Joins: fantasai (fantasai@66.55.71.177)
# [12:52] * Disconnected
# [12:53] * Attempting to rejoin channel #css
# [12:53] * Rejoined channel #css
# [12:53] * Topic is 'CSS WG -- logs: http://krijnhoetmer.nl/irc-logs/css -- blog: http://www.w3.org/blog/CSS'
# [12:53] * Set by anne on Thu Mar 11 21:03:19
# [14:22] * Joins: lstorset (lstorset@213.236.208.22)
# [14:29] * Parts: lstorset (lstorset@213.236.208.22)
# [15:11] * Joins: miketaylr (miketaylr@38.117.156.163)
# [15:38] * Quits: jdaggett (jdaggett@110.4.186.83) (Quit: jdaggett)
# [16:36] * Quits: dsinger (dsinger@68.126.184.36) (Quit: dsinger)
# [16:49] * Joins: TabAtkins (chatzilla@76.253.3.102)
# [16:53] * Joins: anne (annevk@76.253.3.102)
# [17:08] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
# [17:12] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [17:20] * Joins: plh-home (plh@128.30.52.28)
# [17:20] * plh-home looks around for glazou. no luck so far
# [17:26] * Joins: Arron (arronei@173.200.179.65)
# [17:40] * Quits: anne (annevk@76.253.3.102) (Ping timeout)
# [17:48] * Joins: apple (CSS-projec@17.201.14.208)
# [17:48] * apple Good morning!
# [17:49] * Quits: Arron (arronei@173.200.179.65) (Ping timeout)
# [17:50] * Joins: dsinger (dsinger@17.244.1.88)
# [17:50] * plh-home is now known as plh-lunch
# [17:55] * Quits: dydz (dydz@75.37.27.246) (Connection reset by peer)
# [18:01] * apple is now known as CSS-projector
# [18:03] * Joins: dydz (dydz@75.37.27.246)
# [18:03] * plh-lunch is now known as plh-home
# [18:04] * Joins: TabAtkins (chatzilla@17.244.0.185)
# [18:05] * Joins: anne (annevk@17.244.2.72)
# [18:07] * Joins: smfr (smfr@17.244.3.222)
# [18:10] * Joins: plinss_ (plinss@17.244.3.217)
# [18:12] * dsinger people are...gathering...
# [18:13] * Joins: dbaron (dbaron@63.245.220.11)
# [18:15] * Joins: dethbakin (dethbakin@17.244.1.101)
# [18:16] * Joins: sylvaing (sylvaing@17.244.2.236)
# [18:17] * Joins: Arron (arronei@17.244.2.216)
# [18:20] * Joins: bradk (bradk@17.244.0.81)
# [18:20] <TabAtkins> ScribeNick: TabAtkins
# [18:20] * Joins: glazou (glazou@17.244.3.28)
# [18:21] <TabAtkins> plinss: First topic this morning is CSSOM.
# [18:21] <TabAtkins> plinss: And impact on other specifications.
# [18:21] * Joins: ChrisL (ChrisL@128.30.52.169)
# [18:21] <TabAtkins> anne: While editting the spec, I noticed a few problems.
# [18:21] <TabAtkins> anne: One is that there's no real data model.
# [18:22] <TabAtkins> anne: The CSSOM is supposed to have a represetnation of what the stylesheet is like.
# [18:22] <TabAtkins> anne: But in the CSS specifications there is no clear mapping from the syntax to the data model behind it.
# [18:22] * Joins: szilles (chatzilla@17.244.3.121)
# [18:22] <TabAtkins> anne: A clear example is the font-family property.
# [18:22] <TabAtkins> anne: I think most impls internally represent them as strings, but that's not stated anywhere.
# [18:22] <TabAtkins> anne: So when you try to design a value API, you have to state it there.
# [18:23] <TabAtkins> fantasai: The font-family syntax I put up said explicitly that Computed Value should be strings, so I agree.
# [18:23] <TabAtkins> anne: We need Specified Value too. Basically, what you get after parsing.
# [18:23] <TabAtkins> anne: Two, there is surprising lack of consistency in the interface names.
# [18:23] <TabAtkins> anne: Like, an interface named CSSStyleRule, that maps to a css ruleset, but that term isn't really defined in the grammar.
# [18:24] <TabAtkins> anne: I'm not sure if we actually want to change the CSS spec, so this makes sense, or what?
# [18:24] * Joins: alexmog (alexmog@17.244.2.33)
# [18:24] <TabAtkins> anne: What I'm asking is if we want to adjust the terminology so that it's consistent between CSS and CSSOM.
# [18:24] <TabAtkins> anne: I'm guessing we can't change the interface, so it would be CSS that changes in a few points.
# [18:24] <TabAtkins> anne: Also, CSS spec refers to a lot of things as just 'values'.
# [18:25] <TabAtkins> anne: But in CSSOM, that needs to be something separate, like a 'value component', because a property can have multiple of them.
# [18:25] <TabAtkins> anne: The CSS spec is kind of loose with those things.
# [18:25] <TabAtkins> howcome: I agree, the spec shoudl change there.
# [18:25] <TabAtkins> ChrisL: The spec is focused on taking text into CSS, not in reverse. The OM spec should define that.
# [18:26] <TabAtkins> fantasai: No, I think the spec is ambiguous in a lot of places.
# [18:26] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
# [18:26] <TabAtkins> Bert: There is context where we call many things values, and if we introduce multiple terms for these it would be too confusing.
# [18:26] <TabAtkins> glazou: I heard the same thing when I introduced the [multiple types of selector groupings]
# [18:27] <TabAtkins> dbaron: I objected to that at the time because a term was actually being *redefined*.
# [18:27] <TabAtkins> anne: There are other specs where there are multiple concepts being referred to as the same thing. And that's fine, as long as there's a disambiguation at some point.
# [18:28] <TabAtkins> Bert: That disambiguation is present in the <> forms.
# [18:28] <TabAtkins> fantasai: I recommend 'property value' and 'component value', so they both abbreviate as 'value'.
# [18:28] <TabAtkins> howcome: Agreed, we shouldn't be changing tons of terms in the spec, but the disambiguation is needed.
# [18:29] <TabAtkins> ChrisL: Question about CSS color component. Is that used a lot, and is it memory constrained?
# [18:29] <TabAtkins> anne: We can change it if necessary. Specifics are still mutable.
# [18:29] <TabAtkins> anne: I can work around the lack of terminology, or invent my own, but it would be nice if it matched up.
# [18:29] <TabAtkins> fantasai: Do you have a list of terms that you need?
# [18:29] <TabAtkins> anne: No.
# [18:30] <ChrisL> would prefer to see attribute long red; instead of attribute short red; - color bit depth is increasing now
# [18:30] <TabAtkins> fantasai: I think the next step is to come up with that list of terms, so we can make sure it's defined somewhere.
# [18:30] <TabAtkins> anne: The grammar uses the term "statement" to refer to @ rules or rulesets, and the CSSOM spec refers to them as "CSSRules".
# [18:31] <TabAtkins> fantasai: I think CSSOM should be changed there.
# [18:31] <TabAtkins> anne: [describes the terminology, and how it can't be changed at this point]
# [18:31] <glazou> Present: Sam Weinig, smfr, annevk, szilles, dethbakin, sylvaing, alexm, Bert, arronei, fantasai, dbaron; bradk, TabAtkins, ChrisL, glazou, plinss, howcome, dsinger
# [18:31] <ChrisL> http://en.wikipedia.org/wiki/Deep_Color
# [18:31] <TabAtkins> fantasai: I'm not saying change the interface name, but you can say that "CSSRule" refers to what CSS calls "statement".
# [18:31] <TabAtkins> anne: I tried to do that before, but it didn't make much sense to me.
# [18:32] <TabAtkins> TabAtkins: I'd heard you talking before that it would be useful for specs to define how they should be reserialized, frex how to turn a gradient back into a string?
# [18:32] <TabAtkins> anne: Yeah, something in the future is for the CSS specs to be aware of the CSSOM in their writing.
# [18:33] <TabAtkins> anne: Like when you serialize the margin property, do you do as few values as possible, or write it out fully?
# [18:33] <TabAtkins> ChrisL: I agree with anne that specs should be aware of the CSSOM and write things in respect to that.
# [18:34] <TabAtkins> Bert: I think that the CSSOM should refer to CSS, not the other way around.
# [18:34] <TabAtkins> anne: There are several CSS specs that include interfaces.
# [18:34] <TabAtkins> Bert: Yeah, I think those should be taken out.
# [18:35] <TabAtkins> anne: I think it would be acceptable for me to have an ever-growing OM spec, but that isn't compatible with how the w3c does recs.
# [18:35] <TabAtkins> plinss: I think we agreed that specs going forward would define interfaces.
# [18:35] <fantasai> fantasai: We agreed that they would define serialization, not that they would define interfaces
# [18:36] <TabAtkins> plinss: It makes sense for the OM to define interfaces that are common across many specs, but we also shouldn't wait for a monolithic OM to include all the specialized interfaces that a module might have.
# [18:36] * Joins: dino (dino@17.202.116.62)
# [18:36] <fantasai> Bert: it doesn't have to be monolithic, you can publish a separate spec for each module's OM
# [18:37] <TabAtkins> plinss: We can have two conformance classes, if you support the OM you have to support X and Y, if not you just have to support X.
# [18:37] <TabAtkins> arronei: It's just a few lines in the conformance section to add the conformance requirements.
# [18:38] <TabAtkins> fantasai: But we have several specs in CR that don't include an OM section, and I don't want to pull them back to add that.
# [18:38] <TabAtkins> fantasai: We could create new OM specs just for those.
# [18:38] <TabAtkins> dbaron: That's a lot of specs.
# [18:38] <TabAtkins> anne: I'm fine with including that stuff in OM.
# [18:39] <TabAtkins> fantasai: If you can give me a template that I fill in to add OM stuff, I can do it. But until then, I don't want to have to add them to the spec.
# [18:39] <fantasai> fantasai: Half the generic stuff isn't even defined yet, and as for me I have *no clue* what to put in for the OM section
# [18:40] <TabAtkins> plinss: The person editting a given module may have no clue what the OM requires, what's a good idea, and so in that sense it may make sense to have a separate OM module for it.
# [18:40] <TabAtkins> anne: For value APIs, new values, we do want interfaces.
# [18:40] <TabAtkins> Bert: But for new keywords or lengths or numbers, those already exist?
# [18:40] <TabAtkins> anne: Yes.
# [18:41] <TabAtkins> anne: And for backgrounds, it might be sufficient already since it's a comma-separated list.
# [18:41] * Joins: myakura (myakura@122.17.119.104)
# [18:41] <TabAtkins> anne: For transforms, animations, they all introduce properties with slightly more complex values that need new value interfaces.
# [18:42] <TabAtkins> plinss: Any new @ rule needs an interface. And depending on how granular we get with the API, we may need to extend it for more things.
# [18:42] <TabAtkins> anne: And the Images module, it would need to define new interfaces for the new things in there.
# [18:43] <TabAtkins> plinss: Any conclusions on this?
# [18:43] <TabAtkins> Bert: There was something about numbering, and them having to be unique. Is there any way to avoid this?
# [18:43] <TabAtkins> anne: The pattern that is used all over most APIs is to use numbered constants.
# [18:44] <TabAtkins> anne: For CSSRule we cant' change the pattern. For CSSValue I suppose we could, but we haven't discussed it yet. I think it makes sense to keep it with the familiar way.
# [18:44] <TabAtkins> Bert: Does every @ rule need a new number then?
# [18:44] <TabAtkins> anne: If it exposed the same information as another @ rule, it can reuse a number.
# [18:45] <TabAtkins> plinss: @page introduces multiple different @ rules, which would all need a number.
# [18:45] <TabAtkins> anne: We have @page and friends, @font-face, @media, @import, and stylerules, all with different numbers.
# [18:46] <TabAtkins> anne: So far new @ rules probably want a new number.
# [18:46] * Quits: alexmog (alexmog@17.244.2.33) (Connection reset by peer)
# [18:46] <TabAtkins> anne: Like all the @margin rules might share a single number.
# [18:46] * Joins: alexmog (alexmog@17.244.2.33)
# [18:47] <TabAtkins> Bert: Numbers need coordination, which I think we should try to avoid if possible.
# [18:47] <TabAtkins> anne: I think we should just try to coordinate.
# [18:47] <TabAtkins> anne: We managed to do it pretty well for DOM Exceptions.
# [18:48] <TabAtkins> Bert: Who do we have to coordinate with. Just here, or do we have to coordinate with SVG?
# [18:48] <TabAtkins> anne: Officially SVG has to coordinate with us, but I've reserved some space for [something SVG-specific].
# [18:48] <TabAtkins> [talk about different impls stomping on numbers]
# [18:48] * Parts: alexmog (alexmog@17.244.2.33)
# [18:49] * Joins: alexmog (alexmog@17.244.2.33)
# [18:49] <fantasai> make the constant point to a UUID? :)
# [18:49] <TabAtkins> ChrisL: We need an easily referencable page where we can refer to this and stop conflicts.
# [18:49] <TabAtkins> [discussion on using a wiki for coordination]
# [18:49] <TabAtkins> anne: There is a way with WebIDL that you can extend an interface.
# [18:49] <TabAtkins> Bert: You can reference a wiki as an informative reference, but not a normative one.
# [18:50] <TabAtkins> anne: Yeah, sure, it can be informative. That's fine.
# [18:50] <TabAtkins> fantasai: So these numbers are all named constants, and people are supposed to use the names?
# [18:50] <TabAtkins> anne: Theoretically.
# [18:50] <TabAtkins> fantasai: Can we have the named constant return something other than a number?
# [18:50] <TabAtkins> anne: No, the type is a short.
# [18:51] <TabAtkins> anne: Same thing is done with, say, Nodes, but that doesn't change very often. CSS adds new things somewhat more often.
# [18:52] <TabAtkins> plinss: If you're implemeneting something early, like Paged Media in webkit, should prefixed versions use the same final number?
# [18:52] <TabAtkins> anne: No, it says right now that the CSSWG reserves the first 1000 values.
# [18:53] <TabAtkins> plinss: So proprietary versions should use a number above 1000.
# [18:54] <TabAtkins> ChrisL: Will implementations switch from >1000 to <1000 when they get standardized?
# [18:54] <TabAtkins> anne: When they drop the prefix should be fine.
# [18:54] <TabAtkins> plinss: Should we try to reserve blocks for individual browsers?
# [18:55] <TabAtkins> fantasai: Authors should just use the named constants.
# [18:55] <TabAtkins> smfr: Should the named constants be prefixed?
# [18:55] * Joins: howcome (howcome@17.244.0.146)
# [18:56] <TabAtkins> anne: Good question. If you don't prefix, there's a chance that code would still work when it moved to standardization. But if we changed anything, then it could break.
# [18:56] <TabAtkins> anne: Ideally we'd iterate fast enough that we don't run into that situation.
# [18:56] <TabAtkins> anne: If people want to write their thoughts to the list, it would be fine.
# [18:57] <TabAtkins> ACTION: anne to set up wiki page to list CSSOM constants for coordination
# [18:57] * trackbot noticed an ACTION. Trying to create it.
# [18:57] * RRSAgent records action 11
# [18:57] <trackbot> Created ACTION-219 - Set up wiki page to list CSSOM constants for coordination [on Anne van Kesteren - due 2010-04-07].
# [18:57] <TabAtkins> plinss: Did we come up with a decision for how to do OM sections for new modules?
# [18:58] <TabAtkins> anne: I think for specs in WD, it would make sense to have them in the spec. But perhaps we should defer that a little and discuss the value APIs first.
# [18:58] <TabAtkins> anne: So currently for the value apis you get a CSSStyleDeclaration object, with a long list of attributes that represent CSS properties.
# [18:58] <TabAtkins> anne: And they all return a string.
# [18:58] <smfr> http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface
# [18:58] <TabAtkins> anne: The initial idea we had was that instead of a string it would return something special, that would act like a string but would allow extensions.
# [18:59] <TabAtkins> anne: I brought it up on public-script-coord, where ecmascript guys hang out, but they didn't think it was a good idea.
# [18:59] <TabAtkins> anne: [some examples of breakage]
# [18:59] <TabAtkins> anne: Based on that we have a new idea. The CSSStyleDeclaration object would have a new property called values, which would return a CSSStyleVales object.
# [19:00] <TabAtkins> anne: It would act like StyleDeclaration, but when you access a property, it would return a CSSValue object rather than a string.
# [19:00] <TabAtkins> anne: The object would have a cssText attribute that lets you set a string or get a serialization, which is equivalent to the existing API.
# [19:00] <TabAtkins> anne: So then the question is how to define the new value APIs on top of that.
# [19:00] <TabAtkins> anne: I think we want interfaces for the components.
# [19:01] <TabAtkins> anne: So an interface for %, for lengths, for color values
# [19:01] <fantasai> anne, http://wiki.csswg.org/spec/cssom-constants
# [19:01] <TabAtkins> anne: And if you have a width property, that supports both lengths and %, the object returned would implement both.
# [19:01] <smfr> http://dev.w3.org/csswg/cssom/#the-cssvalue-interface
# [19:01] <TabAtkins> anne: It would have an .px and .em accessor, but also a percentage accessor so you could set and get %.
# [19:01] <TabAtkins> anne: So how far do we want to go? Each and every property, or start out witha limited subset?
# [19:02] <TabAtkins> anne: And do we need a "type" like CSSRule so you can figure out what kind of value was set?
# [19:03] <TabAtkins> anne: Like, ComponentValue would return a type of lengthEm, lengthPx, etc. Would that be a short, like the other types? Or a string that could be interned, which could be more extensible.
# [19:03] <TabAtkins> anne: If we did numbers, then if we start filling in spots, say if we added a new length, it could be very separated from the other lengths. px could be 12, and rem could be 100.
# [19:04] <TabAtkins> plinss: As long as people use names, the numbers wouldn't matter much anyway.
# [19:04] <TabAtkins> plinss: We could also reserve blocks.
# [19:04] <TabAtkins> szilles: So what's the downside on strings?
# [19:04] <TabAtkins> plinss: Pereformance.
# [19:04] <TabAtkins> anne: If they're interned, it would just be pointer comparisons.
# [19:05] <TabAtkins> plinss: I'm concerned more with author script stuff. Will I be doing a thousand string comparisons, or a thousand short comparisons?
# [19:05] <Bert> s/Pereformance/Performance/
# [19:05] <TabAtkins> smfr: Potentially, we could have them do atomic string comparisons.
# [19:05] <fantasai> You might also want to answer things like "is this a length (any kind)" or "is this a percentage"
# [19:06] <fantasai> ?: Can we define constants that are strings?
# [19:06] <plinss_> s/?/anne/
# [19:06] <TabAtkins> ?: Nothing theoretically wrong with it. The strings are essentially immutable.
# [19:07] <TabAtkins> s/?/Sam Weinig/
# [19:07] * Joins: weinig (weinig@17.244.2.164)
# [19:07] <TabAtkins> anne: How do we, at the object level, distinguish between value components and things that are separated lists of value components.
# [19:07] <TabAtkins> anne: Like, background-position takes two values.
# [19:08] <TabAtkins> anne: So how do we represent that?
# [19:08] <TabAtkins> plinss: I think it should return a backgroundPosition object that has two values.
# [19:09] <TabAtkins> glazou: We could return an array with the components in the order they appear.
# [19:09] <TabAtkins> plinss: Or an object with queryable values, so it's more extensible.
# [19:10] <TabAtkins> anne: Also, do we want a special interface for shorthands? Like margin, should we implement a margin property or only margin-left, margin-right, etc?
# [19:10] <TabAtkins> dbaron: Also there are some non-shorthand values that are rather complex, like shadows or border-image.
# [19:11] <TabAtkins> plinss: We could pretend they are shorthands and expose them as such in the object model.
# [19:11] <TabAtkins> anne: But then we're stuck if a property later becomes a shorthand.
# [19:11] <TabAtkins> fantasai: Like we're going to do with whitespace.
# [19:11] <TabAtkins> smfr: I think the hash-table approach would work for shorthands.
# [19:13] <fantasai> fantasai: So, for the 'margin' shorthand you'd be able to look up the 'margin-left' value and 'margin-right' value?
# [19:13] <dbaron> A bunch of the complex-valued properties are arbitrary-length lists, which are hard to represent as shorthands.
# [19:13] <TabAtkins> glazou: If possible, harmonize things across properties, so "x" is the same for all the values.
# [19:13] <TabAtkins> sam: In that case you wouldn't have named components, but rather numbered components.
# [19:14] <fantasai> fantasai: You could have named components that are lists
# [19:14] <TabAtkins> plinss: We've already had things that take a single value and turned them into lists of that value.
# [19:15] <TabAtkins> anne: A simple example would be background-image, which would return a css url, but also have a way of getting a list of css urls.
# [19:15] <TabAtkins> dbaron: I think the single-value thing should only return the single value if there *is* a single value, and otherwise complain about being a wrong tpe.
# [19:16] <dbaron> s/complain about/do whatever happens when it is/
# [19:16] <dbaron> s/being a wrong tye/the wrong type/
# [19:17] <TabAtkins> glazou: Recursively nested values.
# [19:17] <dbaron> What's interesting with url() values is often an absolute URL rather than a relative URL relative to the style sheet.
# [19:17] <TabAtkins> glazou: In the case of color, rgb returns a single color value, which also has .r, .g, .b.
# [19:17] <TabAtkins> glazou: etc.
# [19:19] <TabAtkins> glazou: Editors will *massively* use CSSOM if it is easier to use, but not if they have to reparse/rebuild values into a useful form every time.
# [19:20] <TabAtkins> anne: I think you want interfaces for this.
# [19:21] <TabAtkins> glazou: Another thing I want to see in the CSSOM, some things just for editors.
# [19:21] <TabAtkins> glazou: Like not just the reserialized text, but the original parsed text.
# [19:22] <TabAtkins> glazou: Like if the @style attribute has something wrong, browsers currently throw it away and it's hard to get at that.
# [19:22] <TabAtkins> glazou: Browsers don't need that, so they can just return null or whatever, but editors are allowed to return the full thing.
# [19:23] <TabAtkins> sam: Is that confusing for authors?
# [19:23] <TabAtkins> anne: If it's not for browsers, do we need it in the spec?
# [19:23] <TabAtkins> glazou: Yes, if you have multiple editors you want interop.
# [19:24] <TabAtkins> smfr: So what if someone wants to write a javascript editor tool in a normal browser?
# [19:24] <TabAtkins> TabAtkins: Like FireBug would love this.
# [19:24] <TabAtkins> smfr: Isn't this what UnknownRule is for?
# [19:24] <TabAtkins> dbaron: UnknownRule was designed by someone who doesn't understand CSS parsing.
# [19:25] <TabAtkins> plinss: We could just tell browsers to *not* throw away these things.
# [19:25] <TabAtkins> sam: For Firebug and Web Inspector we use internal hooks, and don't need the specced thing.
# [19:25] <TabAtkins> arronei: What if I'm a brand new editor for HTML and CSS? This is where having a spec would be great.
# [19:26] <TabAtkins> sam: The issue is that it would slow down browsers. We can either decide that we have it anyway, or not.
# [19:26] <TabAtkins> smfr: We could have a runtime switch controlled by the OM. It's weird, but shrug.
# [19:26] * ChrisL bijectively
# [19:27] <TabAtkins> [discussion about editors and browsers throwing things away]
# [19:27] <TabAtkins> glazou: A live editing tool for HTML and CSS right now is impossible because of this limitation.
# [19:27] <fantasai> I don't think UnknownRule or UnknownAnything is necessarily the way to go. You should have a unified API insofar as possible. You can have MalformedRule or something for things that can't be parsed...
# [19:27] <TabAtkins> anne: We've had this discussion before. I thinkwe might want some editing features already, and we might want to move those upward.
# [19:28] <TabAtkins> anne: But I think we need a more concrete proposal for how to modify the OM for editors.
# [19:28] <fantasai> But if it's clearly propertyname : valueIcan'tUnderstand, you should get an api that works the same as for color: blue;
# [19:28] <fantasai> and returns the propertyname and the string representation of the value
# [19:28] <TabAtkins> glazou: concrete example: firebug, dragonfly, etc, from a given element, you can climb up the cascade to find which element triggered the current rule. But it's not standard!
# [19:28] <TabAtkins> glazou: We all use proprietary interfaces to do it.
# [19:29] <TabAtkins> anne: That's something we can definitely standardize.
# [19:29] <TabAtkins> anne: For changing the parsing engine we need more detailed proposals.
# [19:29] <TabAtkins> dbaron: CSS is harder to get right because you've got comments anywhere.
# [19:30] <TabAtkins> glazou: My own impl preserves comments between rules and between declarations. But that's a big bloat for browsers.
# [19:30] <TabAtkins> plinss: in the early days of gecko I made something that preserved all the information, and if it found a comment somewhere odd, it would shove it forward to the next 'normal' point for comments.
# [19:31] <TabAtkins> glazou: That's not perfect, but yeah it works.
# [19:31] <TabAtkins> glazou: I perfectly understand the browser's concerns wrt bloat and footprint.
# [19:31] <TabAtkins> glazou: But adding nothing at all shuts the door to a whole class of live applications on the web that are everywhere these days.
# [19:31] <TabAtkins> glazou: Wikis are everywhere, styles are everywhere, and we still can't edit styles.
# [19:32] <TabAtkins> anne: We can largely edit it. Not every property, but most of them.
# [19:32] <TabAtkins> anne: I think most editors let you edit the text file.
# [19:32] <TabAtkins> ChrisL: Because the OM isn't up to the task yet.
# [19:32] <TabAtkins> howcome: That's what the spec is trying to fix, right?
# [19:33] <TabAtkins> anne: For WYSIWYG you don't need comments, so I see some conflicts.
# [19:33] <TabAtkins> howcome: I think Anne is trying to get this done, and you're being aggressive to him.
# [19:33] <TabAtkins> glazou: I'm not aggressive, I love what you've done, I just want to see more.
# [19:34] <TabAtkins> smfr: You should both be able to edit the text directly, and move to doing sliders and such, and go back. We need that for our editor.
# [19:35] <TabAtkins> plinss: The Web has a legacy of documents being editted by hand, and we can't just throw that away into a non-hand-editable spec as soon as machines touch it.
# [19:35] <TabAtkins> sam: I think that Anne's work doesn't impede any of this.
# [19:35] <TabAtkins> glazou: I think that when OM was first created, editors weren't in anyone's mind.
# [19:36] <TabAtkins> plinss: Gecko actually got built to be an editor. The fact that it turned into a browser is happenstance.
# [19:37] <TabAtkins> plinss: While we were designing that stuff, we saw the convergence of editors and browsers as the web develops.
# [19:37] <TabAtkins> plinss: We eventually realized that the only difference between gecko being a browser and being an editor was a stylesheet.
# [19:38] <TabAtkins> anne: We just need to find what the cost for benefit is. If browsers already preserve comments, we can look into that, but we can't put comments everywhere.
# [19:38] <TabAtkins> anne: And what about whitespace?
# [19:39] <TabAtkins> glazou: What's important is maintaining what was entered. Like for border-radius, you can't just have everything but the -moz-border-radius thrown away just because that's the only one that was recognized.
# [19:39] <TabAtkins> anne: If someone can define what sort of string would be produced, and browsers are okay with the footprint, we'd be okay.
# [19:40] <TabAtkins> fantasai: I think you would start parsing, and get the property name as an ident.
# [19:40] <TabAtkins> plinss: ident, colon, stuff, semicolon.
# [19:41] <TabAtkins> sam: So basically we'd have something more than unknown rules, for unknown declarations too, and a browser mode that would change that.
# [19:41] <TabAtkins> fantasai: For all rules too.
# [19:41] <TabAtkins> alexmog: Let's have a CSS editing requirement TF and come up with a list of requirements for object model, for editors, and other features, so we can figure out what the goals we're trying to achieve are.
# [19:42] <TabAtkins> alexmog: Right now we're designing a partial object model. We can possible change the OM into something that does what we need, or something completely different for editors.
# [19:43] <TabAtkins> alexmog: [he talks to VS people twice a year about this, various requests]
# [19:43] <TabAtkins> RESOLVED: Alex and Daniel will start a CSS Editing TF.
# [19:44] <TabAtkins> anne: I think if you want it to end up in browsers you want it to reconcile with the OM.
# [19:44] <TabAtkins> glazou: Yes.
# [19:44] <TabAtkins> alexmog: I'm not quite convinced if a high-powered editor needs to be built on the object model.
# [19:45] <TabAtkins> alexmog: Like if there are only a small number of companies building major editors, they may not need a full OM in favor of just a more editing-friendly interface.
# [19:46] <TabAtkins> plinss: The same thing happened with HTML. First browsers didn't remember anything about the HTML, and the object model got thrown away as it was parsed. But we gradually kept around more of the model.
# [19:47] <TabAtkins> plinss: So we need to extend this over CSS.
# [19:47] <TabAtkins> plinss: We didn't build the DOM to build an editor, it just happens to also be useful for this.
# [19:47] <TabAtkins> glazou: We know there are some things that we always can't do, like preserving comments everywhere.
# [19:50] <bradk> It would be nice if the various developer tools (FireBug, etc.) preserved (and flagged somehow) properties and values that had typos or spelling mistakes, so that they can be edited and fix in-browser.
# [19:52] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
# [19:56] <dbaron> glazou, http://dbaron.org/css/timing-function-graphs
# [19:57] * Joins: bradk (bradk@17.244.0.81)
# [20:03] * Quits: myakura (myakura@122.17.119.104) (Quit: Leaving...)
# [20:04] * howcome has put up som snapshots from yesterday http://www.wiumlie.no/img/2010/03-csswg-cupertino/best.html
# [20:06] * Quits: alexmog (alexmog@17.244.2.33) (Connection reset by peer)
# [20:06] * Joins: alexmog (alexmog@17.244.2.33)
# [20:12] <TabAtkins> anne: We need to have the hash-table concept for values that are space-separated, and a list concept for values that are comma separated?
# [20:13] <TabAtkins> anne: for margin, you'd return a hashtable-like interface with each property
# [20:14] <TabAtkins> TabAtkins: We just need to make sure that properties that later turn into shorthands still work by themselves.
# [20:15] <TabAtkins> sam: My suggestion to anne was to take some of the more complex examples of syntax, break it down into concrete proposals, and put that on the list.
# [20:15] <TabAtkins> fantasai: I suggest border image.
# [20:15] <TabAtkins> glazou: Font stuff too.
# [20:15] <TabAtkins> sam: Whatever is *as hard* for anne as possible.
# [20:15] * Quits: weinig (weinig@17.244.2.164) (Quit: weinig)
# [20:15] <TabAtkins> fantasai: shadows and the content property.
# [20:16] <TabAtkins> ACTION: anne to produce concrete examples of complex properties and put it on the list
# [20:16] * RRSAgent records action 12
# [20:16] * trackbot noticed an ACTION. Trying to create it.
# [20:16] <trackbot> Created ACTION-220 - Produce concrete examples of complex properties and put it on the list [on Anne van Kesteren - due 2010-04-07].
# [20:17] <TabAtkins> smfr: We also need to define if every property has a canonical form. If someone specifies 'ease' in a timing function, do they get 'ease' back or a bezier function?
# [20:17] <TabAtkins> plinss: As much as possible we should return what the author specified.
# [20:18] <TabAtkins> anne: We could have a .keyword value that would return a keyword if the value corresponds to a keyword.
# [20:18] <TabAtkins> glazou: Same with color - if the author says "red", do we do 'red', '#f00', rgba(255,0,0,1), or what?
# [20:18] <TabAtkins> anne: Browsers try to store as little as possible right now.
# [20:20] <TabAtkins> plinss: For a browser, no matter what gets specified it'll be stored as a [r,g,b] or whatnot, and I'd want back what the author actually said sometimes if possible.
# [20:20] <TabAtkins> anne: We might have a bit that says if the color was originally a keyword or whatnot.
# [20:20] <TabAtkins> anne: Currently there are a number of normalization rules for various things.
# [20:20] <TabAtkins> plinss: I'm concerned that some of them go too far.
# [20:21] <TabAtkins> plinss: If you have multiple ways to pull a value back out of the OM, that's fine, but when serialized to text it should be as close to what the author said as possible. We can change "Red" to "red", don't need bit-for-bit, but the spirit should be the same.
# [20:22] <TabAtkins> smfr: One problem I have with gradients is that there's no canonicalization.
# [20:22] <TabAtkins> TabAtkins: Agreed, I need to add that.
# [20:22] <TabAtkins> plinss: CSS3 Color Issues
# [20:22] <dbaron> http://wiki.csswg.org/spec/css3-color
# [20:22] * Joins: szilles (chatzilla@17.244.3.121)
# [20:23] <TabAtkins> Currently the editors draft addresses most of these issues, but I haven't yet replied to the emails with these comments.
# [20:23] <TabAtkins> First is issue 5.
# [20:24] <TabAtkins> dbaron: At first I thought it was someone who didn't understand the spec, but I realize now that there isn't a good description of what rgba means.
# [20:24] <TabAtkins> ChrisL: And I think it should explain how it interacts with opacity (multiplied together).
# [20:24] <TabAtkins> dbaron: A repeated comment we got was the gamma correction section being out of date; I think I've addressed that.
# [20:24] <TabAtkins> ChrisL: Yeah, looks like it.
# [20:24] <smfr> editor's draft: http://dev.w3.org/csswg/css3-color/
# [20:24] <TabAtkins> ChrisL: Beth will send me an email that gamma has changed between Leopard and Snow Leopard.
# [20:25] <TabAtkins> dbaron: The wording of the spec in general isn't great about what conformance requirements are, so there are some issues where I think I can improve that relatively easily.
# [20:25] <TabAtkins> dbaron: Frex, it says "here is how to convert hsl to rgb", but it doesn't say you *have* to do that.
# [20:25] <TabAtkins> ChrisL: yeah, that should be normative.
# [20:26] <TabAtkins> ChrisL: Also there was an issue about color spaces and color width and such. All colors should be sRGB, and 0-255.
# [20:26] <TabAtkins> dbaron: Issue 13
# [20:26] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
# [20:27] <TabAtkins> dbaron: Someone suggested we remove the statement about clipping values outside the device gamut, which makes me wonder what to replace it with.
# [20:27] <TabAtkins> ChrisL: I don't think they understood the issue. Do we have a conformance reuqirement to display colors you can't physically display?
# [20:27] <TabAtkins> dbaron: I think that we might not quite want to clip, but might do some special mapping near the edge.
# [20:28] <TabAtkins> ChrisL: [example with differing gamuts]
# [20:28] <TabAtkins> ChrisL: After doing gamut mapping, if I still end up with values outside the displayable colors, it must be clipped.
# [20:28] <TabAtkins> dsinger: Are you modifying what you remember the user asked for, or what you are trying to display?
# [20:29] <TabAtkins> ChrisL: If it's implying that what is specified goes 1-1 with device gamut, that needs to be changed.
# [20:29] <TabAtkins> dbaron: Right, that's why I want to change "clipped" to "clipped or mapped".
# [20:29] <TabAtkins> ChrisL: "clipped or mapped" isn't fine.
# [20:30] <TabAtkins> ChrisL: You need to say "values outside source gamut should be mapped to device gamut, values outside device gamut must be clipped".
# [20:30] <TabAtkins> dbaron: What's the source gamut?
# [20:30] <TabAtkins> ChrisL: The color space you're coming from, sRGB.
# [20:30] <TabAtkins> dbaron: CSS allows values outside of sRGB.
# [20:31] <TabAtkins> ChrisL: Yes, that's fine. If you have a printer that can do blues outside of sRGB, that's fine, CSS lets you express that.
# [20:31] * Joins: szilles (chatzilla@17.244.3.121)
# [20:31] <TabAtkins> ChrisL: But if you're showing on a screen, you can clip to the device's gamut.
# [20:31] <TabAtkins> dbaron: How is the source gamut related to things here?
# [20:32] <TabAtkins> ChrisL: I should have flagged 'device gamut' more. Once you've mapped to the device gamut, *then* you need to clip anything outside of it.
# [20:32] <TabAtkins> Bert: The device clips them for you, right?
# [20:33] <TabAtkins> ChrisL: Typically the driver clips them for you.
# [20:33] <TabAtkins> ChrisL: You need to introduce the term source gamut and device gamut, and use them separately.
# [20:33] <TabAtkins> dbaron: What is the source gamut?
# [20:33] <TabAtkins> ChrisL: In here, sRGB, or any other color space if we allow more later.
# [20:34] <TabAtkins> dbaron: But we allow things outside of sRGB.
# [20:34] <TabAtkins> ChrisL: Right, nobody is talking about clipping source gamut.
# [20:35] <TabAtkins> ChrisL: I can take an action to give a better description here.
# [20:35] <TabAtkins> szilles: [suggestion for communicating this without using the term gamut]
# [20:37] <TabAtkins> ACTION: clilley to rewrite the paragraph in CSS color concerning gamuts and clipping
# [20:37] * trackbot noticed an ACTION. Trying to create it.
# [20:37] * RRSAgent records action 13
# [20:37] <trackbot> Created ACTION-221 - Rewrite the paragraph in CSS color concerning gamuts and clipping [on Chris Lilley - due 2010-04-07].
# [20:37] <TabAtkins> dbaron: issue 18, from xsl-fo.
# [20:37] <smfr> http://wiki.csswg.org/spec/css3-color#issue-18
# [20:39] <smfr> http://lists.w3.org/Archives/Public/www-style/2008Sep/0006.html
# [20:39] <TabAtkins> dbaron: It's one of the later messages in the thread.
# [20:40] <TabAtkins> ChrisL: Marbux is a troll.
# [20:40] <TabAtkins> glazou: We still need to respond to trolls.
# [20:40] <TabAtkins> glazou: Talked to AC people, they said it was no problem.
# [20:41] <TabAtkins> glazou: So we have an answer. It's member-only, but it's not a technical issue, only a legal one. It probably deserves a member-only answer.
# [20:41] <TabAtkins> ChrisL: So resolution is no change?
# [20:41] <TabAtkins> szilles: The "be" change should happen, though, right?
# [20:41] <TabAtkins> dbaron: That's editorial, yeah.
# [20:42] <TabAtkins> ChrisL: So we can say "We agree with the editorial comments from the XSL-FO working group". It makes it clear who we're agreeing with.
# [20:42] <TabAtkins> dbaron: There's a note at the bottom of the system colors section that I think is wrong.
# [20:42] <TabAtkins> dbaron: It says the computed value of a system color is the keyword itself.
# [20:43] <TabAtkins> dbaron: First it's weird that a normative requirement is a note, and I think it's wrong anyway.
# [20:43] <TabAtkins> dbaron: So system colors should compute to a color.
# [20:43] <TabAtkins> ChrisL: Sounds good.
# [20:44] <TabAtkins> ChrisL: I've seen Issue 20 come up in hypertext coordination group before, and so we need to say what we mean by 'deprecated'.
# [20:44] <TabAtkins> dbaron: We mean that impls should still implement it, but new content shouldn't use it.
# [20:44] <TabAtkins> ChrisL: Issue 27, we should discuss it.
# [20:45] <TabAtkins> ChrisL: I assume it's because we can get it out this decade?
# [20:45] <TabAtkins> dbaron: It doesn't have real dependencies; it can go to 2.1 just fine.
# [20:46] <dbaron> Sounds like people are all happy with depending on CSS 2.1
# [20:46] * plh-home is now known as plh-away
# [20:46] <TabAtkins> plinss: Next topic is animation of gradients.
# [20:46] <TabAtkins> smfr: I think this came up because the Transitions spec said gradients were animatable.
# [20:46] * Quits: alexmog (alexmog@17.244.2.33) (Connection reset by peer)
# [20:46] * Joins: alexmog (alexmog@17.244.2.33)
# [20:46] <TabAtkins> smfr: I think this is a mistake because gradients aren't a property, but rather a type of image, and we don't know how to transition images yet.
# [20:47] <TabAtkins> smfr: Also I think this might be someething for the public-fx group to input into as well.
# [20:48] <TabAtkins> ChrisL: Could you send a mail to the list about that?
# [20:48] <TabAtkins> ChrisL: [talks about how animating gradients in SVG is easy]
# [20:49] <TabAtkins> TabAtkins: I've got a goal with shepazu to unify some underlying concepts in CSS and SVG, to make those things easier.
# [20:49] <TabAtkins> plinss: Next topic is image-fit and image-position
# [20:49] <TabAtkins> fantasai: We can't do much, since that was supposed to be for SVG coord.
# [20:49] <TabAtkins> fantasai: But one thing we can talk about is naming. SVG wanted new names for things.
# [20:49] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
# [20:49] <TabAtkins> fantasai: We might be able to discuss that.
# [20:49] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
# [20:51] <anne> btw, http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
# [20:52] <TabAtkins> howcome: image-* isn't perfect for video either
# [20:52] <TabAtkins> fantasai: fit-aspect-ratio says that you're fitting the aspect ratio to the box.
# [20:52] <TabAtkins> fantasai: As far as the most useful information you can stuff into the property, that's fine.
# [20:53] <TabAtkins> ChrisL: So fit-aspect-ratio and fit-position are good?
# [20:53] <TabAtkins> howcome: No. What if you put it on a <p>?
# [20:53] <TabAtkins> fantasai: No aspect ratio, so it's no good.
# [20:54] <TabAtkins> howcome: Are there other suggestions?
# [20:54] <TabAtkins> Bert: Without something pointing to images or replaced content, this sounds too general.
# [20:54] <fantasai> s/it's no good/it doesn't apply/
# [20:54] <TabAtkins> dbaron: What's the list of values for this?
# [20:55] <TabAtkins> TabAtkins: For aspect ratio: fill, cover, and contain. For position, a bg-position.
# [20:55] <TabAtkins> howcome: Why isn't image good enough for SVG?
# [20:56] <TabAtkins> dbaron: If I hear "aspect-ratio", I expect something that looks like a ratio.
# [20:57] * dsinger needs a link to the spec. in which they occur
# [20:57] <TabAtkins> fantasai: Maybe aspect-ratio-fit, but then it's weird to combinee them into a shorthand.
# [20:57] * TabAtkins Paged Media spec.
# [20:58] <TabAtkins> smfr: content-fit, or just fit?
# [20:58] <TabAtkins> Bert: We had that.
# [20:58] <dsinger> here http://dev.w3.org/csswg/css3-page/
# [20:58] <TabAtkins> TabAtkins: We had content-fit, said it was too general, and changed it to image-fit.
# [20:58] <smfr> http://dev.w3.org/csswg/css3-page/#img-fit
# [20:59] <TabAtkins> TabAtkins: This specifically says "replaced elements", which isn't great for SVG.
# [21:00] <TabAtkins> fantasai: When SVG imports it, they can clarify wording for their own purposes.
# [21:00] <TabAtkins> fantasai: In CSS, all values have no effect on non-replaced content.
# [21:00] <TabAtkins> Bert: content-* has another advantage, in that it refers back to the content property, which can produce a replaced element.
# [21:01] * fantasai thinks that nobody will find 'fit-content' when they're looking for it if it has neither aspect-ratio nor image in its name
# [21:01] <Bert> 'content-fit' not 'fit-content'
# [21:02] <TabAtkins> [naming discussions]
# [21:02] <bradk> 'scale-how' and 'position-how'
# [21:02] <Bert> (I still prefer 'image-fit', though)
# [21:02] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
# [21:03] <fantasai> 'aspect-ratio-fit'
# [21:03] <fantasai> 'fit-aspect-ratio'
# [21:03] <fantasai> 'content-fit'
# [21:03] <fantasai> 'fit-content'
# [21:03] <fantasai> 'fit-scaling'
# [21:03] <fantasai> 'scaling-fit'
# [21:03] <dsinger> fitting?
# [21:04] <dsinger> 'replaced-element-fit-behavior'?
# [21:04] <bradk> fitting:have(1)
# [21:04] <fantasai> q+ for motion to switch topics until Molly can join the discussion
# [21:05] * Quits: alexmog (alexmog@17.244.2.33) (Ping timeout)
# [21:05] <TabAtkins> <br type=lunch>
# [21:05] * Quits: dethbakin (dethbakin@17.244.1.101) (Quit: dethbakin)
# [21:06] * Quits: smfr (smfr@17.244.3.222) (Quit: smfr)
# [21:06] <sylvaing> image-spread
# [21:06] * Quits: glazou (glazou@17.244.3.28) (Quit: glazou)
# [21:06] * Joins: smfr (smfr@17.244.3.222)
# [21:06] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
# [21:06] * Bert sandwich-spread ?
# [21:07] * Quits: smfr (smfr@17.244.3.222) (Quit: smfr)
# [21:07] * CSS-projector digestion-fit-width
# [21:07] * Quits: plinss_ (plinss@17.244.3.217) (Quit: plinss_)
# [21:09] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
# [21:09] * Quits: sylvaing (sylvaing@17.244.2.236) (Ping timeout)
# [21:22] * plh-away is now known as plh-home
# [21:42] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [21:43] * Joins: Lachy (Lachlan@85.196.122.246)
# [22:03] * Joins: smfr (smfr@17.244.3.222)
# [22:04] * Joins: sylvaing (sylvaing@17.244.2.236)
# [22:04] * Joins: mjs (mjs@17.246.16.64)
# [22:04] * Quits: mjs (mjs@17.246.16.64) (Quit: mjs)
# [22:05] * Joins: dethbakin (dethbakin@17.244.1.101)
# [22:06] * CSS-projector viewing-scale : letterbox | crop | fill; viewing-position : ...
# [22:07] * Joins: Arron (arronei@17.244.2.216)
# [22:09] * Joins: bradk (bradk@17.244.1.52)
# [22:12] * Joins: plinss_ (plinss@17.244.3.217)
# [22:12] * Joins: mjs (mjs@17.246.16.64)
# [22:12] * Joins: mollydotcom (mollyh@68.111.14.133)
# [22:13] <mollydotcom> Hi all - guessing you're off for lunch?
# [22:13] <TabAtkins> just getting back, actually
# [22:13] * Quits: bradk (bradk@17.244.1.52) (Quit: Computer has gone to sleep)
# [22:13] <mollydotcom> hi Tab, how's it been going?
# [22:13] <TabAtkins> Excellent!
# [22:13] <mollydotcom> great to hear
# [22:14] <TabAtkins> Sad I didn't get to meet you this time. ;_;
# [22:14] <mjs> did you guys solve all problems with CSS yet?
# [22:14] <anne> we added some problems
# [22:14] <mollydotcom> I know, I was looking forward to it, but boy did I catch some kind of crud.
# [22:14] <mollydotcom> Ah, Anne, ever the optimist.
# [22:14] <mjs> anne: dammit!
# [22:16] * Joins: glazou (glazou@17.244.3.28)
# [22:19] * Joins: bradk (bradk@17.244.1.52)
# [22:20] * Joins: alexmog (alexmog@17.244.2.170)
# [22:20] <glazou> hi mollydotcom
# [22:20] <mollydotcom> Hi Daniel!
# [22:21] <TabAtkins> [continuing discussion about combining animations and gradients]
# [22:21] <TabAtkins> [specifically, maybe attaching animations to transitions, rather than states?]
# [22:22] <fantasai> RRSAgent: pointer
# [22:22] <RRSAgent> See http://www.w3.org/2010/03/29-CSS-irc#T20-19-54
# [22:22] <TabAtkins> [dean talking about animations with implicit start and end, like transitions do]
# [22:23] <TabAtkins> [if, say, you animate left when you transition a color, what's the final value of left?]
# [22:23] <Bert> (If 'transition-properties' has a value foo, then foo animates, even if the start and end values are the same.)
# [22:24] <TabAtkins> [discussion about new selectors to address the hover/unhover animations]
# [22:24] <TabAtkins> [something more analogous to mouseenter/mouseleave, rather than mouseover like :hover is]
# [22:25] <TabAtkins> [or something that explicitly captures a state transition, like :transition(:hover,:not(:hover))]
# [22:25] <TabAtkins> [combinatorial number of state transitions]
# [22:33] <TabAtkins> [event-based CSS property]
# [22:34] <TabAtkins> [back to keyframes for transitions?]
# [22:35] * Joins: jdaggett (jdaggett@110.4.186.83)
# [22:36] <anne> you could have something like :leave(:hover) or :leave(.test) for when something stops applying...
# [22:36] <anne> but keyframes for transitions is prolly an easier solution
# [22:37] <TabAtkins> plinss: Back to naming of image-fit and image-position, sincy mollydotcom is here.
# [22:37] <glazou> mollydotcom, we need your expertise finding names...
# [22:37] <fantasai> Topic: image-fit
# [22:37] <mollydotcom> I'm here to talk about that
# [22:37] <TabAtkins> smfr: dsinger had a suggestion that he put into irc earlier
# [22:37] <TabAtkins> smfr: viewing-scale : letterbox | crop | fill; viewing-position : ...
# [22:38] <plinss_> zakim, make room for 3
# [22:38] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [22:38] <plinss_> zakim, make room for 3
# [22:38] <Zakim> I don't understand 'make room for 3', plinss_
# [22:38] <plinss_> zakim, room for 3
# [22:38] <Zakim> I don't understand 'room for 3', plinss_
# [22:39] <plinss_> zakim, room for 3?
# [22:39] <Zakim> ok, plinss_; conference Team_(css)20:36Z scheduled with code 26632 (CONF2) for 60 minutes until 2136Z
# [22:39] <mollydotcom> do you want me to call in or shall I just type? Both hurt, typing less so as my throat is so swollen.
# [22:39] <glazou> mollydotcom: see conf call data just above
# [22:39] <fantasai> how about we call in, and you type?
# [22:39] <fantasai> that way you can hear everything
# [22:39] <glazou> Zakim, code?
# [22:39] <Zakim> the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou
# [22:40] <mollydotcom> ok, I'll call in and say hi and then type
# [22:40] <mollydotcom> thanks
# [22:40] <fantasai> :)
# [22:40] <plinss_> (or not quite hear as the case may be...)
# [22:40] <Zakim> Team_(css)20:36Z has now started
# [22:40] <Zakim> +[Apple]
# [22:40] <TabAtkins> mollydotcom: You can call in now.
# [22:40] <Zakim> +Molly_Holzschlag
# [22:41] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
# [22:42] <TabAtkins> mollydotcom: Elika has caught me up a little bit on the issue.
# [22:42] <TabAtkins> mollydotcom: We've been talking about this for a long time.
# [22:42] <TabAtkins> mollydotcom: If someone can pinpoint the terminology that we're struggling with, I can help out.
# [22:42] <TabAtkins> fantasai: We got a message from SVGWG, prompting the discussion.
# [22:43] <TabAtkins> mollydotcom: Main concern with image-fit and content-fit is that we're really not talking about images or content.
# [22:43] <TabAtkins> mollydotcom: It *may* be an image, but it's not traditionally what we call 'content'.
# [22:43] <TabAtkins> mollydotcom: I suggest, for semantic rationale, 'object-fit'.
# [22:44] <TabAtkins> howcome: Steve suggested that over lunch as well. I think it covers the things we're talking about here.
# [22:44] <TabAtkins> mollydotcom: Right, whether it's a video or some SVG or an image or an applet, we can call all those 'object'.
# [22:44] <mjs> does 'object-fit' really add any meaning to 'fit'?
# [22:44] <mjs> pretty much anything can be arguably an 'object'
# [22:44] <TabAtkins> mollydotcom: I have a problem from an educational perspective with using 'image'.
# [22:45] <TabAtkins> mollydotcom: I think 'object' does add meaning to 'fit'.
# [22:45] <TabAtkins> mollydotcom: I don't think it's true that *anything* can be an object. In the markup world, that always refers to a replaced element or similar.
# [22:45] <TabAtkins> fantasai: Agreed.
# [22:45] <mjs> in HTML there is specifically the <object> element, and people would think the property is referring to that
# [22:45] <TabAtkins> smfr: That could also bring up the reference to <object>, which would suggest an exclusion of <video> and similar.
# [22:45] <fantasai> fantasai: I don't think anyone thinks of a paragraph as an object
# [22:46] <TabAtkins> mollydotcom: Yeah, that's possible confusion.
# [22:46] <bradk> object has another meaning in JavaScript too.
# [22:46] <mjs> as a browser implementor, I certainly think of a paragraph as an object
# [22:46] <mjs> HTMLParagraphElement to be specific
# [22:46] <TabAtkins> As an author, do you think of it that way?
# [22:46] <mjs> no idea if authors think of it that way; I would imagine authors would do a lot of scripting would think of every element as an object
# [22:46] <TabAtkins> mollydotcom: To designers, 'image-fit' would say to them that we can't put a java applet in there.
# [22:46] <TabAtkins> mollydotcom: They come at us from a different perspective.
# [22:47] <mjs> if the intent is to capture all replaced elements, then maybe it should be replaced-fit
# [22:47] <TabAtkins> smfr: What's the objection to content-fit?
# [22:47] <TabAtkins> mollydotcom: Too broad.
# [22:47] <bradk> sometimes, when I'm dealing with an element in JS
# [22:47] * TabAtkins maciej, this will be more than just replaced content when SVG imports the property.
# [22:47] <TabAtkins> mollydotcom: It seems to me that 'object' is a happier medium.
# [22:47] <fantasai> mollydotcom: And for content authors, content refers to the text content of the document
# [22:48] <mjs> TabAtkins, what does SVG intend to apply it to? everything?
# [22:48] <TabAtkins> object-fit: fill | contain | cover
# [22:48] <fantasai> object-fit: fill | contain | cover
# [22:48] * TabAtkins maciej, ask ChrisL.
# [22:48] <fantasai> object-position: <bg-pos>
# [22:48] <fantasai> ?
# [22:48] <fantasai> mollydotcom: To me it looks good, and I think I can have that make sense to people
# [22:49] <fantasai> mollydotcom: I think it's much harder to convey this than image-*
# [22:49] <fantasai> howcome: I can live with image-* too, but this is better
# [22:49] <mjs> I really doubt that "object" adequately distinguishes the set of SVG, CSS and HTML constructs it applies to, from the set of things it doesn't apply to
# [22:49] * TabAtkins maciej, it seems that there *is* no single word that does it. Everything sucks somehow.
# [22:49] * anne doesn't really like object either
# [22:49] <mjs> TabAtkins, why not just name the property "fit"? does it need a noun?
# [22:49] <fantasai> mollydotcom: We were also talking about scaling
# [22:50] <TabAtkins> howcome: I think 'fit' is just too generic.
# [22:50] <Bert> (We had 'fit' at one point, and decided to change it.)
# [22:50] <TabAtkins> fantasai: It seems like it could be a shorthand for fit-position and something else.
# [22:50] <fantasai> it seems like it would be a shorthand for fit-position and something else
# [22:50] <TabAtkins> mollydotcom: Let's throw it in front of the SVGWG and see what they have to say.
# [22:51] * TabAtkins Next public-fx telcon!
# [22:51] <fantasai> mollydotcom: We talked about fit-scaling
# [22:51] <bradk> I still prefer 'scaling-fit'
# [22:51] <mjs> random proposal: fit-rule: fill | contain | cover, fit as a shorthand for fit-rule and fit-position
# [22:51] <TabAtkins> mollydotcom: Problem with me is the active word of scaling. It's not quite actively scaling.
# [22:51] <ChrisL> rrsagent, here
# [22:51] <RRSAgent> See http://www.w3.org/2010/03/29-CSS-irc#T20-49-43
# [22:52] <TabAtkins> mollydotcom: fit-scale, alone, makes sense to designers and similar people.
# [22:52] <TabAtkins> mollydotcom: if I say you ahve to scale this particular object, that makes more sense to me than saying 'fit-scaling'.
# [22:52] <TabAtkins> mollydotcom: In PS and you want to keep the aspect ratio, you just click "keep aspect ratio" and just change one value, or do it in %s.
# [22:53] <TabAtkins> mollydotcom: And that's a very familiar paradigm.
# [22:53] <TabAtkins> mollydotcom: So I think the word 'scale' is better, but there's vaguery in all of this.
# [22:53] <TabAtkins> mollydotcom: We just have to pick the one that is closest and most understandable to the most people.
# [22:53] <fantasai> fit-scale: fill | cover | contain
# [22:53] <fantasai> fit-position: <bg-pos>
# [22:53] <TabAtkins> howcome: So should we just list the alternatives?
# [22:53] <fantasai> could append <percentage> to fit-scale
# [22:53] <bradk> On a fit-scale of 1-10, I'm about a 5 maybe.
# [22:53] <fantasai> 100% would replace none
# [22:53] <fantasai> fit-scale: fill | cover | contain | <percentage>
# [22:54] <fantasai> mollydotcom: just giving one would preserve aspect ratio
# [22:54] <fantasai> mollydotcom: fit-scale: 100% would be the image its actual size
# [22:54] <fantasai> mollydotcom: fit-scale: 50% scales it down by 1/2
# [22:55] <fantasai> mollydotcom: Could allow 2 values would allow different scaling for different dimensions
# [22:55] <fantasai> howcome writes on the board
# [22:55] <fantasai> fit-scale
# [22:55] <fantasai> fit-position
# [22:55] <TabAtkins> howcome: Are these the two proposals we have?
# [22:55] <fantasai> ---
# [22:55] <fantasai> object-fit
# [22:55] <fantasai> object-position
# [22:55] <fantasai> ---
# [22:55] <fantasai> iage-fit
# [22:55] <fantasai> image-position
# [22:55] <fantasai> s/iage/image/
# [22:55] <fantasai> ---
# [22:55] <fantasai> aspect-ratio-fit
# [22:55] <fantasai> fit-position
# [22:55] <fantasai> ---
# [22:55] <fantasai> scaling-fit
# [22:55] <fantasai> fit-position
# [22:56] <fantasai> ---
# [22:56] <fantasai> and either of last two with 'fit' in the front
# [22:57] <fantasai> howcome adds numbers
# [22:57] <fantasai> 1. fit-scale / fit-position
# [22:57] <fantasai> 2. object-fit / object-position
# [22:57] <fantasai> 3. image-fit / image-position
# [22:57] * glazou making mollydotcom laugh is a bad idea
# [22:57] <fantasai> 4. aspect-ratio-fit (or fit-aspect-ratio) / fit-position
# [22:57] * ChrisL mdr, literally
# [22:58] <mollydotcom> 2 from me
# [22:58] <fantasai> smfr: prefer 3, but 2 is ok
# [22:58] <fantasai> anne: same
# [22:58] <fantasai> steve: 1 or 2, not 3
# [22:59] <fantasai> beth: 2, fallback to 3 if it has to
# [22:59] <fantasai> sylvain: 3, then 2
# [22:59] <fantasai> alex: 3, then 2
# [22:59] <fantasai> alex: for the same reason I prefer mouse over pointer
# [22:59] <fantasai> bert: 2, 3
# [22:59] <fantasai> arron: 2, then 3
# [22:59] <fantasai> fantasai: 1, then 2
# [22:59] <fantasai> dbaron: 2 then 3
# [23:00] <fantasai> tantek: abstain
# [23:00] <fantasai> brad: 2 then 1
# [23:00] <fantasai> tab: 1 then 2
# [23:00] <fantasai> chris: 1 then 2
# [23:00] <fantasai> daniel: 2 then 1
# [23:00] <fantasai> peter: 1 then 2
# [23:00] <fantasai> dsinger: 1 then 2
# [23:01] <fantasai> howcome: 2 then 3
# [23:01] <fantasai> dbaron: 2 was first or second choice from everybody
# [23:03] <fantasai> fantasai: my one concern with 1 is that if you want to ad percentage scaling, it doesn't work with the object-fit name
# [23:03] <fantasai> anne points out that if you made a shorthand with these, the shorthand would be called object
# [23:03] <TabAtkins> s/anne/smfr/
# [23:03] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
# [23:03] <mollydotcom> my cat apparently has some opinions about all this, but darned if I can understand her ;)
# [23:03] <TabAtkins> s/s\/anne\/smfr\///
# [23:04] <bradk> meow-fit
# [23:04] <mollydotcom> She keeps saying it
# [23:04] <ChrisL> but its merely anecdotal
# [23:04] <mollydotcom> We are now the Cat Style Sheet Working Group, apparently
# [23:04] <mollydotcom> haha
# [23:04] <mollydotcom> short paw
# [23:05] <mollydotcom> Anne: you do make a good point
# [23:05] <mollydotcom> no shorthand should be called object IMO
# [23:05] <mollydotcom> is there going to be a real need to do that?
# [23:05] * ChrisL catastrophic transmogrification
# [23:05] <TabAtkins> smfr: object-fit-scale, object-fit-position
# [23:05] <fantasai> smfr: Could combine them and have object-fit-scale and object-fit-position
# [23:06] <Zakim> -Molly_Holzschlag
# [23:06] <Zakim> -[Apple]
# [23:06] <Zakim> Team_(css)20:36Z has ended
# [23:06] <Zakim> Attendees were [Apple], Molly_Holzschlag
# [23:06] <glazou> mollydotcom: I'll cough for you in the meantime
# [23:06] * dbaron remembers Hixie's proposal for the Cascadable Abstract Tree Selectors specification
# [23:07] <mollydotcom> bye folks!
# [23:07] <mollydotcom> @glazou, I hear wine relaxes the bronchial tubes :p
# [23:07] <TabAtkins> fantasai: smfr's suggestion would address the shorthand and make more sense with %s.
# [23:07] <glazou> mollydotcom: I'm not able to have a glass of wine at this time, trust me
# [23:09] <fantasai> TabAtkins: percentages would make a shorthand impossible to parse
# [23:10] <TabAtkins> RESOLVED: use object-fit and object-position for the properties
# [23:10] <fantasai> Topic: Advanced Layout Modules
# [23:10] <dbaron> ScribeNick: fantasai
# [23:10] <fantasai> TabAtkins: So, this is going to be less direct suggestions and more mjy plan of action in the future about what to do
# [23:11] <fantasai> TabAtkins: I'm a Google employee now, and will soon be chrome liaison
# [23:11] <fantasai> TabAtkins: I want to take the layout drafts and turn them into something we wnat to implement and use soon
# [23:11] <fantasai> TabAtkins: Specifically, Template, Flex, Grid, and a few others maybe
# [23:11] <fantasai> TabAtkins: I've been thinking for a while what the underlying abstractions are in the different layout drafts
# [23:12] <fantasai> TabAtkins: and also in the different layout modesl I as an authro want to do
# [23:12] <fantasai> TabAtkins: I would like to combine into one model, but don't think I can quite do that
# [23:12] <fantasai> alexmog: Why do you want to do this?
# [23:12] <fantasai> TabAtkins: Because I as an author want to use them. Because laying out in CSS sucks
# [23:12] <fantasai> alexmog: But you also want one or more browsers to implement
# [23:13] <fantasai> TabAtkins: I'd also hope to implement some of this myself
# [23:13] <fantasai> TabAtkins: So, the first model that layout things will be built on is table layout
# [23:13] <fantasai> TabAtkins: turns out talbe layout is super useful for layouts I've done, for doing things I didn't expect before I started playing with it
# [23:13] <fantasai> TabAtkins: Talbe alyout by itself is good, I like the way it lays out as a grid
# [23:14] <fantasai> TabAtkins: the problem is that it restricts your site markup: you need to put in containers and order things so that it lays out
# [23:14] <fantasai> TabAtkins: which can be bad for accessibility
# [23:14] <fantasai> TabAtkins: Template layout fixes this
# [23:14] <Bert> s/ talbe / table /g
# [23:14] <fantasai> TabAtkins: Once you look into it, it looks just like magic on top of table layout
# [23:14] <fantasai> TabAtkins: So I want to take Template Layout, slightly change it so that it is magic on top of table layout
# [23:14] <fantasai> TabAtkins: That would basically entail setting up the properties so set up a table grid out of pseudo eleents
# [23:15] <fantasai> TabAtkins: and hopefully discussing how content is flowed into the pseudo elements
# [23:15] <fantasai> TabAtkins: hopefully not a significant change in the draft, just conceptual
# [23:15] <fantasai> TabAtkins: Another thing to add would be another table layout model that's sane
# [23:15] <fantasai> TabAtkins: fixed table layout is sane
# [23:15] <fantasai> dbaron: no it's not, it's just nobody uses it so nobody knows how messed up it is
# [23:16] <fantasai> alexmog: Even if I don't understand table layout, I can ...?
# [23:16] <fantasai> dbaron: Another problem with table layout is that putting large things into small cells often doesn't do what you want
# [23:16] <fantasai> dbaron: eg. have one thing wider than viewport
# [23:16] <fantasai> dbaron: makes the whole table wider than the viewport
# [23:17] <fantasai> TabAtkins: might be an artifact of auto layout righ now
# [23:17] <fantasai> TabAtkins: Could consider putting out a new table layout model along with the mathching template model
# [23:17] <fantasai> TabAtkins: ...
# [23:17] <fantasai> dbaron: I removed support for * widths from Gecko because the implementation didnt do much
# [23:18] <fantasai> dbaron: And the HTML4 description of * widths said do what browsers do for percentage widths, and the spec for percentage widths said something else
# [23:18] <fantasai> alexmog: WPF does use table layout internally, and it implements * widths
# [23:19] <fantasai> alexmog: The advantage is that you can put content into any slot into the table
# [23:19] <fantasai> Bert: We could add a third algorithm to table-layout property
# [23:19] <fantasai> TabAtkins: Building off of table then lets you use auto or fixed layout if that happens to be what you want
# [23:19] <fantasai> Bert: That new algorithm would also allow the flex property in that case
# [23:20] <fantasai> Brad: Would you bring that into the table display types, too?
# [23:20] <fantasai> TabAtkins: Yes, if we add it to table-layout
# [23:20] <fantasai> TabAtkins: the only magic in Template would be to create pseudo elements that represent talbe parts and putting the content in there
# [23:20] <fantasai> TabAtkins: I'm going to start working on the drafts for these
# [23:20] <Bert> s/talbe/table/
# [23:20] <fantasai> TabAtkins: Just wanted to give everyone a heads up
# [23:21] <fantasai> howcome: You have an implementation as template layout, right?
# [23:21] <fantasai> Bert: Yes, 3 impls. One uses same syntax as the draft
# [23:21] <TabAtkins> from alexis deveria
# [23:21] <fantasai> Bert: The other impls are the ones from Cesar, which uses an older syntax
# [23:21] <fantasai> Bert: And there's an impl from Andrew F. which uses another variant syntax
# [23:21] <fantasai> Bert: I like the idea
# [23:22] <fantasai> howcome: We need something like this, we haven't talked aobut htis for years
# [23:22] <fantasai> howcome: what about multicol?
# [23:22] <fantasai> TabAtkins: interact the same way as multicol and tables do now
# [23:23] <fantasai> alexmog: If you are creating a new kind of a grid, that grid could supercede grid positioning
# [23:23] <fantasai> alexmog: you could use that grid to position floats and have them interact with other content
# [23:23] <fantasai> Bert: My template draft has that, the grid is defined by the template grid
# [23:24] <fantasai> howcome confirms that grid units are defined in various drafts
# [23:24] <fantasai> Tantek: what's the general class of use cases that you're going for?
# [23:24] <fantasai> TabAtkins: Overall site layout
# [23:24] <fantasai> TabAtkins: I want to make sure that either htis directly or this plus other stuff is also useful for applications
# [23:25] <fantasai> TabAtkins: e.g. replace Gmail's hacky stuff
# [23:25] <fantasai> Tantek: Traditionally, grid-based layouts are really useful for application UI
# [23:25] * anne can't figure out how to interject a question; so IRC; did he say he's going to base this on top of table layout?
# [23:25] * anne ... also, does that mean someone is going to define table layout first?
# [23:25] * fantasai yes
# [23:25] * fantasai no clue
# [23:25] * fantasai probably not
# [23:25] <glazou> http://glazman.org/howcome-cupertino/
# [23:26] * anne ... seems somewhat important to define those primitives if we are going to build on top of it
# [23:26] <fantasai> Tantek: There are a whole class of applications that are doing ridiculous backflips to do UI
# [23:26] * anne ... we always have long discussions on anything table related and without a clear overall picture of how that works it's just going to get worse
# [23:26] <fantasai> Tantek: Having a model that solves those use cases could cause a renaissance of web applications
# [23:27] <fantasai> TabAtkins: If we can come up with necessary flexibility with grid then building them together would be great .. (?)
# [23:27] <fantasai> Tantek: Consider the use cases together, and consider also the implementors
# [23:27] <fantasai> alexmog: I'm not against unifying the grid
# [23:27] <fantasai> alexmog: but I don't want to have super-complicated interactions across multiple models
# [23:27] <fantasai> dbaron: I don't think gmail is that gridlike
# [23:28] <fantasai> dbaron: The layouts tend to be more about taking one piece of UI and pushing it against the edge of the space, and then having the rest of the area taken up by the rest of the app
# [23:28] <fantasai> dbaron: You have menus and toolbars and sidebars
# [23:28] <fantasai> dbaron: In all these cases you're taking the rectangle
# [23:29] <fantasai> dbaron: taking up one part of it with a UI element, and then filling the remaining space
# [23:29] <fantasai> Tantek: Check out iPhone apps, they have very different UI models
# [23:30] <fantasai> howcome: We havent' really been able to exploit our table model because it hasn't been widely implemented
# [23:30] <fantasai> ...
# [23:30] <fantasai> discussion of WebKit-specific apps and table layout
# [23:31] <fantasai> Tantek: Interface builders have lots of interesting ways of laying out UI elements. It makes sense
# [23:31] <fantasai> snap-to-grid
# [23:31] <fantasai> pin one object to anther object
# [23:31] <fantasai> Tantek: just spend 15 min with interface-builder
# [23:32] <fantasai> howcome: Do we consider apps to be the driving force or documents?
# [23:32] <fantasai> fantasai: Both. We need to handle both.
# [23:33] <fantasai> Tab talks about grids defined by templates and tables and grids defined by content
# [23:33] <fantasai> alexmog: The grid I imagine is independent of content. You either place stuff on the gridlines, or snap to them
# [23:33] <fantasai> alexmog: The only thing you need to add is size to fit
# [23:34] <fantasai> alexmog: perhaps horizontal lines should fit to content
# [23:34] <fantasai> alexmog: that switches grid from trivial to complicated
# [23:34] <fantasai> Tantek: grids aren't just for UIs either
# [23:34] <fantasai> Tantek: Things like baseline-alignment across the page is super-hard to do today
# [23:34] <fantasai> Tantek: Grid would presumably solve that
# [23:34] <fantasai> TabAtkins: You could set up a grid with those line
# [23:35] <fantasai> TabAtkins: and then with some other mechanism tell text to line up to that
# [23:35] <fantasai> TabAtkins: You would need separate grids
# [23:36] <fantasai> TabAtkins: Whether layout grid + baseline grid is sufficient or we need author-named grids, not sure
# [23:36] <fantasai> fantasai thinks we should have named grids
# [23:36] <fantasai> Bert: Anne ask on IRC, so do you have to write the table module first if you are going to do this?
# [23:36] * Joins: tantek (tantek@17.244.3.100)
# [23:36] * Joins: szilles (chatzilla@17.244.3.121)
# [23:37] <fantasai> Anne: What does 'width' mean, what does 'height' mean
# [23:37] <fantasai> TabAtkins: Don't have to define that, can just say "do what you do currently"
# [23:38] <fantasai> TabAtkins: and build a new sane table model
# [23:38] <fantasai> alexmog would like a sane table model
# [23:39] <fantasai> Anne: I think we might get a bid of redundancy because only a few people know what the current one covers and what algorithms are defined that we might want to reuse
# [23:39] <fantasai> Steve: One requirement that I have is that I be able to describe the area into which thigns flow separately from the stuff that's flowing into it.
# [23:40] <fantasai> Steve: Right now table is entirely wound around the content that's in the table. I don't want that
# [23:40] <fantasai> Steve: I want to describe whatever it is without having the content
# [23:40] <fantasai> several, supported by Template module
# [23:40] <fantasai> smfr: Can you split content up between boxes?
# [23:40] <fantasai> TabAtkins: Not currently. No non-rectangular regions and no disconnectd regions
# [23:41] * plh-home is now known as plh-dinner
# [23:41] <fantasai> TabAtkins: would like to add later
# [23:41] <fantasai> howcome: Did you see the very first draft from 1997?
# [23:41] <fantasai> TabAtkins: No, just seen since Advanced Layout just before it got split into Template
# [23:41] <Bert> http://www.w3.org/TR/NOTE-layout
# [23:42] <dbaron> As far as defining table layout, http://dbaron.org/css/intrinsic/ and a spec that Markus was working on both define significant pieces of the width calculation
# [23:42] <dbaron> I actually think I like the height calculation that IE6 does more than what Gecko does.
# [23:42] * fantasai notes that you're probably the only one who understands the implications of that comment :)
# [23:43] <fantasai> TabAtkins: I'm not doing box-to-box flow in order to be conservative in level 3
# [23:43] <fantasai> TabAtkins: I think it would still be useful
# [23:43] <fantasai> ... printing ...
# [23:43] <fantasai> TabAtkins: Printing does bring up other issues. It does matter.
# [23:44] <fantasai> non-rectangular layout is difficult if multiple parts have flexible height
# [23:45] <fantasai> TabAtkins: Next layout topic
# [23:45] <fantasai> TabAtkins: Also related to table layout
# [23:45] <fantasai> TabAtkins: In my current use of tables, I often want to set up a ton of things in a grid
# [23:45] <fantasai> TabAtkins: but in my markup they're just a linear progression
# [23:45] <fantasai> TabAtkins: and I want them to fill through and automatically find the right number of rows
# [23:45] <fantasai> TabAtkins: so like normal table layout except without set rows
# [23:46] <fantasai> TabAtkins: either by filling the width of a space, or specifying a number of columns
# [23:46] <fantasai> howcome: Another idea is columns first
# [23:46] <fantasai> TabAtkins: also want to determine direction of cell flow
# [23:47] <fantasai> TabAtkins: When you loosen constraints on tables, then tend to become more similar to flexbox
# [23:47] <fantasai> TabAtkins: So does anyone theoretically object to these additions to table stuff?
# [23:47] <bradk> block-progression-direction to flow vertically, possibly
# [23:47] <fantasai> * flowing cells into rows without row containers
# [23:48] <fantasai> * cell progression direction: changin direction, changing itnto columns-first
# [23:48] * Quits: dethbakin (dethbakin@17.244.1.101) (Quit: dethbakin)
# [23:48] <fantasai> dbaron: If you switching block-progression direction, you'll also switch the width and height algorithms
# [23:49] <fantasai> dbaron: Do you mean cell-progression-direction as a subfeature of the cell flow idea?
# [23:49] <fantasai> TabAtkins doesn't knowe
# [23:49] <fantasai> howcome complains about being forced to change markup to do layouts
# [23:50] <fantasai> howcome wants a property for det whether talbe is column-primary or row-primary
# [23:50] <fantasai> dbaron: One thing I liked about table height algorithms in IE6 is that they were much more similar to the width algorithms
# [23:51] <fantasai> howcome: You also had an idea about saying which cells you want to start a new row
# [23:51] <fantasai> TabAtkins: If you just want to fill to a specific width, then that doesn't work
# [23:51] <fantasai> TabAtkins: but for other cases it works
# [23:51] <fantasai> TabAtkins: you can use :nth-child to do a specific number of rows
# [23:52] <fantasai> fantasai: A problem with fill to a width is that you layou out your table, splitting into say 4 cols
# [23:52] <fantasai> fantasai: but then you find a really big cell and find you can only fit 2 cols
# [23:52] <fantasai> fantasai: then you have to go back and relayout the whole table
# [23:53] * Quits: smfr (smfr@17.244.3.222) (Quit: smfr)
# [23:53] <fantasai> fantasai: (which is already a 2-3 pass algorithm)
# [23:53] <fantasai> TabAtkins: Ok, maybe that's not a good idea then. Dont' like iterative layouts
# [23:53] <bradk> container has 'table-flow: rows(4)' to auto flow table-cells vertically into 4 rows, with as many columns as it takes.
# [23:53] <fantasai> TabAtkins: you might also want to flow into multiple rows, but not line up column-wise
# [23:54] <fantasai> TabAtkins: They flow and wrap around, and each row is height-equalized
# [23:54] <fantasai> TabAtkins: can fake it with inline-block, but doesn't handle all cases
# [23:54] <fantasai> TabAtkins: Can't justify to exactly fit the row
# [23:54] <Bert> (We did have a tabulation proposal some time ago. It was dropped when leaders() could do 80% of that.)
# [23:54] * Quits: sylvaing (sylvaing@17.244.2.236) (Quit: sylvaing)
# [23:54] <fantasai> ...
# [23:54] <fantasai> alexmog: That's a multi-line flexbox
# [23:55] <fantasai> http://fantasai.inkedblade.net/style/specs/tabs/
# [23:55] <fantasai> TabAtkins: Almost
# [23:55] <fantasai> TabAtkins: box-pack-justify and a flexbox automatically sets all margins to be equivalent
# [23:55] <fantasai> TabAtkins: but if you want finer control voer that, you can't express it in those terms
# [23:56] <fantasai> TabAtkins: you can't set flex on margins
# [23:56] <Bert> (Different kind of "tabs" :-) )
# [23:56] <fantasai> TabAtkins: I think that's only place where flexbox is lacking.. it lays out from the container's perspective but not the childrens
# [23:56] <fantasai> alexmog: that's the point
# [23:56] <fantasai> alexmog: Everywhere else in CSS every element has its own opinion on how it wants to be laid out
# [23:57] <fantasai> alexmog: Flexbox allows introducing simple or different layout algorithms because it doesn't interfere with anything else in the system
# [23:57] * fantasai missed something in the middle
# [23:57] <fantasai> alexmog: The layout is totally governed by the container
# [23:57] <fantasai> alexmog: that's why it's a clean, easy-to-implement, easy-to-use spec
# [23:57] <fantasai> alexmog: If you let it allows margin collapsing and everything else that happens in CSS, then you create a monster
# [23:58] <fantasai> TabAtkins: I would like to dive down and try to design with flexbox, and then bring back anything I find that's insufficient
# [23:58] <fantasai> TabAtkins: But I'm willing to put htat off and do experimentation
# [23:58] <fantasai> dbaron: I think box-pack is pretty rarely used
# [23:58] <fantasai> in xul
# [23:58] <fantasai> dbaron: What's used instead is having more nested boxes
# [23:58] <fantasai> TabAtkins: I do something imilar to flexbox using table layout
# [23:59] <fantasai> TabAtkins: For a horizontal nav, I'll use auto or fixed table layout on a <ul>
# [23:59] <fantasai> TabAtkins: to either space out the links, or the space between the links
# [23:59] <fantasai> TabAtkins: in the first case, the white space between them changes, but their centers are spaced evenly
# [23:59] * Quits: szilles (chatzilla@17.244.3.121) (Ping timeout)
# [23:59] <fantasai> TabAtkins: auto layout almnost equalizes the spaces in between
# Session Close: Thu Apr 01 00:00:00 2010

The end :)