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

Options:

# Session Start: Thu Jun 04 00:00:00 2009
# Session Ident: #css
# [00:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [01:15] * Quits: arronei (arronei@131.107.0.112) (Client exited)
# [01:15] * Joins: arronei (arronei@131.107.0.114)
# [01:34] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
# [03:47] * RRSAgent excuses himself; his presence no longer seems to be needed
# [03:47] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [04:31] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [05:13] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [07:04] * Joins: ChrisL (ChrisL@128.30.52.30)
# [07:31] * Quits: ChrisL (ChrisL@128.30.52.30) (Ping timeout)
# [08:01] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [08:04] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [08:06] * Joins: annevk (opera@82.227.229.89)
# [08:18] * Quits: jdaggett (jdaggett@82.242.111.184) (Quit: jdaggett)
# [08:29] * Joins: jdaggett (jdaggett@82.242.111.184)
# [08:46] * Joins: mollydotcom (molly@193.51.208.72)
# [08:48] * Quits: jdaggett (jdaggett@82.242.111.184) (Quit: jdaggett)
# [08:55] * Quits: annevk (opera@82.227.229.89) (Quit: annevk)
# [09:05] * Joins: alexmog (alexmog@193.51.208.72)
# [09:18] * Quits: mollydotcom (molly@193.51.208.72) (Quit: mollydotcom)
# [09:22] * Joins: sylvaing (sylvaing@131.107.0.114)
# [09:27] * Quits: sylvaing (sylvaing@131.107.0.114) (Ping timeout)
# [09:28] * Joins: dbaron (dbaron@193.51.208.72)
# [09:28] * Joins: mollydotcom (molly@193.51.208.72)
# [09:30] * Joins: glazou (glazou@193.51.208.72)
# [09:30] <glazou> hi
# [09:30] <dbaron> trackbot, start meeting
# [09:30] * trackbot is starting a teleconference
# [09:30] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [09:30] <RRSAgent> logging to http://www.w3.org/2009/06/04-CSS-irc
# [09:30] <trackbot> RRSAgent, make logs member
# [09:30] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [09:30] <RRSAgent> I have made the request, trackbot
# [09:30] <trackbot> Zakim, this will be Style_CSS FP
# [09:30] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [09:30] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [09:30] <trackbot> Date: 04 June 2009
# [09:30] <dbaron> Zakim, remind us in 8 hours to go home
# [09:30] <Zakim> ok, dbaron
# [09:31] * Joins: sylvaing (sylvaing@193.51.208.72)
# [09:31] <sylvaing> scribenick:sylvaing
# [09:31] <sylvaing> topic: gcpm
# [09:31] <sylvaing> hakon: at last f2f, changes to the draft included: image res property, list of features for WD
# [09:31] * Joins: ChrisL (ChrisL@128.30.52.30)
# [09:32] <dbaron> Present: Sylvain Galineau, Steve Zilles, Daniel Glazman, Bert Bos, Anne van Kesteren, Alex Mogilevsky, Håkon Wium Lie, Molly Holzschlag, Elika Etemad, Arron Eicholtz, Chris Lilley, David Baron
# [09:32] <sylvaing> hakon: i proposed to drop anything that has to do with moving elements
# [09:33] * Joins: Arron (arronei@193.51.208.72)
# [09:33] <sylvaing> hakon: floating into footnotes remain
# [09:33] <sylvaing> hakon: moving elements may conflict with generated content
# [09:34] <sylvaing> hakon: what's left now is mostly implemented by two UAs
# [09:34] <sylvaing> hakon: Prince and Antenna House
# [09:37] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [09:40] <sylvaing> (hakon showing updated GCPM spec)
# [09:40] <sylvaing> hakon: dropping moving elements e.g. target-text
# [09:41] <sylvaing> hakon: one issue is what do we do with advanced multicolumn features since no one has implemented it
# [09:43] <sylvaing> discussion of CMYK and whether it makes sense for publishing
# [09:44] <sylvaing> hakon: this is customer requirement to produce PDFs for instance
# [09:44] <sylvaing> chrisl: this should really be called device cmyk
# [09:45] <sylvaing> chrisl: there is a standard to specify color profiles
# [09:45] <sylvaing> ACTION: review GCPM CMYK (section 16) and suggest changes/improvements (ChrisL)
# [09:45] * trackbot noticed an ACTION. Trying to create it.
# [09:45] <trackbot> Sorry, couldn't find user - review
# [09:45] * RRSAgent records action 1
# [09:47] <sylvaing> hakon: note that character substitution (text-replace) "applies only to batch processors"
# [09:47] * Joins: szilles (chatzilla@193.51.208.72)
# [09:47] <dbaron> http://dev.w3.org/csswg/css3-gcpm/#text-replace
# [09:47] <sylvaing> szilles, others: what is a batch processor ?
# [09:48] * Joins: howcome (howcome@193.51.208.72)
# [09:48] <sylvaing> dglazman, chrisl: non-interactive agent
# [09:48] <howcome> http://dev.w3.org/csswg/css3-gcpm/#text-replace
# [09:49] <sylvaing> hakon: note that "This property is evaluated after the content property and before text-transform....it is applied after the white-space property"
# [09:49] <sylvaing> dglazman: this is useful for localization. but is it style ?
# [09:50] <sylvaing> dglazman: why not keep the feature, remove the batch processor qualifier and put it at risk ?
# [09:51] <sylvaing> glazou: alternatively, we need a profile or a statement that interactive rendering engines are not required to support the feature
# [09:51] <sylvaing> fantasai: I don't think it belongs to CSS. it changes content.
# [09:52] <sylvaing> glazou: if not then the content property is not a style property either
# [09:53] <sylvaing> chrisl, hakon: this property does not alter the DOM
# [09:53] <dbaron> "This property is applied after the ‘white-space’ property." needs to be defined much more carefully, since 'white-space' applies at multiple stages of the processing model
# [09:55] <sylvaing> ACTION: howcome to rewrite scope of character substitution; from batch processors to not requiring support from interactive rendering engines
# [09:55] * trackbot noticed an ACTION. Trying to create it.
# [09:55] * RRSAgent records action 2
# [09:55] <trackbot> Created ACTION-150 - Rewrite scope of character substitution; from batch processors to not requiring support from interactive rendering engines [on Håkon Wium Lie - due 2009-06-11].
# [09:55] <sylvaing> ACTION: chrisl to review GCPM CMYK (section 16) and suggest changes/improvements
# [09:55] * RRSAgent records action 3
# [09:55] * trackbot noticed an ACTION. Trying to create it.
# [09:55] <trackbot> Created ACTION-151 - Review GCPM CMYK (section 16) and suggest changes/improvements [on Chris Lilley - due 2009-06-11].
# [09:58] <sylvaing> (discussion follows of text processing issues deemed beyond the grasp of 'normal people'; minute-taker assumes he's one of them)
# [10:00] * Joins: jdaggett (jdaggett@193.51.208.72)
# [10:00] <dbaron> Present+: John Daggett
# [10:00] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [10:06] <sylvaing> discussion about a more complete cascading transformation language that would be more useful to printers and drop the feature from the WD
# [10:07] <sylvaing> glazman: this is not a stylistic feature and therefore belongs outside the specification
# [10:15] <sylvaing> glazman: we can keep as is and scope it to make it optional for interactive rendering engines; or we drop the section from GCPM
# [10:16] <sylvaing> hakon: i'm not comfortable with dropping something that is both pragmatic and useful to printers today
# [10:18] * Quits: ChrisL (ChrisL@128.30.52.30) (Quit: Fire on main board error, client combusted)
# [10:18] <sylvaing> dbaron: as an inherited property, i'm not sure it'd make sense to use it more than once per document
# [10:18] * Joins: ChrisL (ChrisL@128.30.52.30)
# [10:19] <sylvaing> glazman: which brings us some other issues about the feature e.g. whether it's inherited or not
# [10:19] <sylvaing> s/glazman/glazou
# [10:22] <sylvaing> fantasai: the main issue is tha the feature as specified is is incomplete/insufficient and will be hard to complete within the context of CSS
# [10:29] <sylvaing> glazou: third option for the property is to scope it to @media print
# [10:29] <sylvaing> anne: does this mean browsers have to implement it for print ?
# [10:29] <anne> [apparently yes]
# [10:31] <sylvaing> vote: dbaron #2, chrisl #2, arronei #2, elika #2, molly abstains, hakon not 2, alex #2, anne abstains, bert #2, dglazman #2, szilles #2, sylvaing #3
# [10:31] <sylvaing> options were
# [10:31] <sylvaing> #1 scope feature to exclude rendering engines
# [10:31] <sylvaing> #2 drop feature
# [10:32] <sylvaing> #3 like #1 + restrict to @media print
# [10:35] <sylvaing> alexmog: my problem with this doesn't have anything to do with what it does or why but the state of the feature wrt the rest of the spec. I can't implement it as is and I'd rather implement a spec completely
# [10:41] <sylvaing> RESOLVED: character substitution is dropped out of the GCPM working draft
# [10:43] * Quits: Arron (arronei@193.51.208.72) (Connection reset by peer)
# [10:54] * Joins: Arron (arronei@193.51.208.72)
# [10:56] <sylvaing> WG proceeds with quick review of GCPM sections to decide its publication as a WD
# [10:58] <dbaron> Hmm, now that we have leaders and leading I wonder if we could get some other variants of either of the base words so we can confuse ourselves more. :-)
# [11:00] * glazou mentions the Talmud as a good example for multiple footnotes :-)
# [11:04] <sylvaing> fantasai: two issues about footnotes. 1) steve's comment about multicolumn footnotes and 2) what happens to footnotes in scrolling media
# [11:05] <sylvaing> fantasai: specifically, where is the footnote box in the document in that case ?
# [11:06] <glazou> (ongoing discussion about css3-gcpm)
# [11:09] <sylvaing> renaming border-parts to border-clip
# [11:15] <sylvaing> ACTION: howcome to compare and reconcile GCPM border-clip syntax with border-image's
# [11:15] * trackbot noticed an ACTION. Trying to create it.
# [11:15] * RRSAgent records action 4
# [11:15] <trackbot> Created ACTION-152 - Compare and reconcile GCPM border-clip syntax with border-image's [on Håkon Wium Lie - due 2009-06-11].
# [11:15] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [11:19] <dbaron> 00B9;SUPERSCRIPT ONE;No;0;EN;<super> 0031;;1;1;N;SUPERSCRIPT DIGIT ONE;;;;
# [11:19] <dbaron> 00B2;SUPERSCRIPT TWO;No;0;EN;<super> 0032;;2;2;N;SUPERSCRIPT DIGIT TWO;;;;
# [11:19] <dbaron> 00B3;SUPERSCRIPT THREE;No;0;EN;<super> 0033;;3;3;N;SUPERSCRIPT DIGIT THREE;;;;
# [11:19] <dbaron> 2074;SUPERSCRIPT FOUR;No;0;EN;<super> 0034;;4;4;N;SUPERSCRIPT DIGIT FOUR;;;;
# [11:19] <dbaron> 2075;SUPERSCRIPT FIVE;No;0;EN;<super> 0035;;5;5;N;SUPERSCRIPT DIGIT FIVE;;;;
# [11:19] <dbaron> 2076;SUPERSCRIPT SIX;No;0;EN;<super> 0036;;6;6;N;SUPERSCRIPT DIGIT SIX;;;;
# [11:19] <dbaron> 2077;SUPERSCRIPT SEVEN;No;0;EN;<super> 0037;;7;7;N;SUPERSCRIPT DIGIT SEVEN;;;;
# [11:19] <dbaron> 2078;SUPERSCRIPT EIGHT;No;0;EN;<super> 0038;;8;8;N;SUPERSCRIPT DIGIT EIGHT;;;;
# [11:19] <dbaron> 2079;SUPERSCRIPT NINE;No;0;EN;<super> 0039;;9;9;N;SUPERSCRIPT DIGIT NINE;;;;
# [11:19] <dbaron> 2070;SUPERSCRIPT ZERO;No;0;EN;<super> 0030;;0;0;N;SUPERSCRIPT DIGIT ZERO;;;;
# [11:24] <dbaron> we should probably be adding this new type to http://dev.w3.org/csswg/css3-lists/#numeric as well
# [11:25] <fantasai> yeah
# [11:33] <fantasai> http://dev.w3.org/csswg/css3-lists/#super-decimal
# [11:38] <sylvaing> ACTION: howcome fantasai to move super-decimal counter type from GCPM to Lists
# [11:38] * trackbot noticed an ACTION. Trying to create it.
# [11:38] * RRSAgent records action 5
# [11:38] <trackbot> Created ACTION-153 - Fantasai to move super-decimal counter type from GCPM to Lists [on Håkon Wium Lie - due 2009-06-11].
# [11:38] <sylvaing> previous action is on howcome+fantasai
# [11:50] <sylvaing> ACTION-153 should be removed. instead....
# [11:50] <sylvaing> RESOLVED: super-decimal counter type moves from GCPM to Lists
# [11:55] * Quits: szilles (chatzilla@193.51.208.72) (Client exited)
# [12:02] <anne> fwiw "It's easier to ask forgiveness than it is to get permission"
# [12:03] <sylvaing> ACTION: chrisl to email plinss regarding the removal from CSS2.1 of 'without reliable resolution information' from intrinsic dimensions definition in section 3.1
# [12:03] * trackbot noticed an ACTION. Trying to create it.
# [12:03] * RRSAgent records action 6
# [12:03] <trackbot> Created ACTION-154 - Email plinss regarding the removal from CSS2.1 of 'without reliable resolution information' from intrinsic dimensions definition in section 3.1 [on Chris Lilley - due 2009-06-11].
# [12:03] <anne> (i.e. just make the change)
# [12:05] <sylvaing> (actually, we want Peter and HP's opinion)
# [12:06] <anne> (Are we skipping css3-flexbox and Fonts?)
# [12:07] <sylvaing> (text-replace: "css3-flexbox" "gcpm")
# [12:08] <anne> heh
# [12:11] <sylvaing> RESOLVED: GCPM page-bleed renamed to bleed
# [12:16] <sylvaing> RESOLVED: keep page floats in the GCPM WD
# [12:20] <sylvaing> szilles: I am concerned about the clarity of the dependencies between our outstanding drafts
# [12:21] <sylvaing> szilles: while i'm happy to publish this as a working draft, I'm concerned on our ability to resolve and fix the issues and conflicts that may arise due to those dependencies
# [12:23] <sylvaing> hakon: should we rename this module ?
# [12:23] <sylvaing> chrisl: garbace collection placeholder module ?
# [12:23] <sylvaing> (laughter)
# [12:24] <ChrisL> s/garbace/garbage/
# [12:24] <sylvaing> text-replace: "garbace" "garbage";
# [12:24] <glazou> lol
# [12:27] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [12:27] * Quits: jdaggett (jdaggett@193.51.208.72) (Quit: jdaggett)
# [12:28] * Joins: glazou (glazou@193.51.208.72)
# [12:28] * Quits: mollydotcom (molly@193.51.208.72) (Quit: mollydotcom)
# [12:29] <sylvaing> <lunch />
# [12:30] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
# [12:31] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [12:33] * Joins: glazou (glazou@193.51.208.72)
# [12:44] * Joins: mollydotcom (molly@90.52.22.95)
# [12:45] * Parts: mollydotcom (molly@90.52.22.95)
# [12:51] * Quits: alexmog (alexmog@193.51.208.72) (Ping timeout)
# [13:02] * Joins: myakura (myakura@122.29.15.50)
# [13:31] * Quits: sylvaing (sylvaing@193.51.208.72) (Ping timeout)
# [13:44] * Joins: jdaggett (jdaggett@193.51.208.72)
# [13:47] <anne> jdaggett, you can use javascript:alert(navigator.userAgent)
# [13:51] * Joins: sylvaing (sylvaing@193.51.208.72)
# [13:51] * Joins: alexmog (alexmog@193.51.208.72)
# [13:52] * Joins: Arron (arronei@193.51.208.72)
# [13:53] <fantasai> ScribeNick: fantasai
# [13:53] <fantasai> Topic: Flexbox
# [13:54] <dbaron> http://dev.w3.org/csswg/css3-flexbox/
# [13:54] <fantasai> dbaron: we resolved to publish this awhile ago
# [13:54] <fantasai> but it took me awhile to get it into the right format
# [13:54] <fantasai> dbaron: The editor token passed through a lot of revisions
# [13:54] <fantasai> dbaron: The most recent one had a lot of examples removed
# [13:54] <fantasai> dbaron: and also a lot of prose change
# [13:54] <fantasai> dbaron: So somebody ought to evaluate those changes
# [13:55] <fantasai> dbaron: but I also want to get published, because we've been discussing this a lot
# [13:55] <fantasai> dbaron: There are other related proposals too, but I'd like to publish what we have, just to get a draft out
# [13:55] <fantasai> Daniel: Any outstanding issues we should address before publishing?
# [13:56] <fantasai> dbaron: The major issue is interaction with other layout proposals
# [13:56] <fantasai> discussion of Ian's affiliation
# [13:56] <fantasai> Daniel: We preserve the affiliation at the time of the work being done
# [13:57] <fantasai> Alex: Can you give me a summary?
# [13:57] <fantasai> dbaron: A flexible box has children laid out either horizontally or vertically
# [13:57] <fantasai> dbaron: You have a property to choose which direction they go in
# [13:58] <fantasai> dbaron: What you do with the extra space ...
# [13:58] * sylvaing thinks of Ghostbusters everytime someone says 'XUL'. Very annoying.
# [13:58] <fantasai> dbaron: In the dimension the children are laid out in, you can put the space at the beginning, at the end, center the children, or spread the space out
# [13:59] <fantasai> dbaron: Then in the direction that's not the direction you're laying out, you can align the children to one side or the other
# [13:59] <fantasai> dbaron: You can also assign flex to some or all of the children
# [13:59] <fantasai> dbaron: flex controls where the space gets distributed
# [13:59] <fantasai> dbaron: That I think is the part that is implemented in both Mozilla and Webkit
# [13:59] <fantasai> dbaron: There's an unimplemented box-ordinal part
# [14:00] <fantasai> dbaron: Which lets you say that flex goes to groups of elements in priorities
# [14:00] <fantasai> dbaron: I'm not actually sure of the details, and the spec is all we have to go on wrt what it was intended to be because nobody implemented it
# [14:00] <fantasai> dbaron: A lot of the sizes by default, without flex, deal with intrinsic sizes
# [14:00] <fantasai> dbaron: You can sometimes flex down instead of up
# [14:01] <fantasai> dbaron: Because usually you use the preferred width, but you can flex things down to the minimum width
# [14:01] <fantasai> dbaron: There's also another piece that wasn't implemented, box-lines, that allows boxes to lay out in multiple lines
# [14:01] <fantasai> dbaron: The draft might be short on mathematical details for things like preferred and minimum widths...
# [14:02] <fantasai> dbaron: and some of that is its interaction with other parts of the CSS box model
# [14:02] <fantasai> Alex: This is already implemented?
# [14:02] <fantasai> dbaron: yes
# [14:02] <fantasai> Alex: You don't know how it interacts with other models?
# [14:02] <fantasai> dbaron: To some extent, not very well.
# [14:02] <fantasai> dbaron: The important use cases... the one's where you really care about interaction with other models
# [14:02] <fantasai> dbaron: The main one is putting a chunk of block-and-inline layout inside a xul flexbox
# [14:03] <fantasai> dbaron: the other is building some widget-like thing that goes inside HTML
# [14:03] <fantasai> dbaron: In the first case, essentially what you're doing is most of the time the chunk of block-and-inline layout takes up all the available space
# [14:03] <fantasai> dbaron: so you're not using its intrinsic width
# [14:03] <fantasai> dbaron: The not-ver-well understood case is when you're using the intrinsic width for this
# [14:04] <fantasai> dbaron: but shrink-to-fit.... it doesn't work very well half the time in the cases where we use it,too ????
# [14:04] <fantasai> dbaron: .... in floats, most of the time authors give a width
# [14:04] <fantasai> Alex: The challenge is to define the behavior of what David refers to as not very well
# [14:04] <fantasai> Alex: The scenarios that we weouldn't really care about for the purposes of this
# [14:05] <fantasai> dbaron: I think some of that is just getting a definition so everybody does the same thing, nevermind trying to figure out something good to do
# [14:05] <fantasai> Alex: So this is flex layout, but also float:right or tables.. are there issues with that?
# [14:05] <fantasai> dbaron: This is triggered by an additional value of the display property. If you float it, it's a block, no longer a flexbox.
# [14:06] <fantasai> Alex: this is used to create layout. Is this a complete layout model that is good for building user interfaces, or are there other pieces that you'd want?
# [14:06] <fantasai> dbaron: This draft does not have the grids that we use in it
# [14:07] <fantasai> dbaron: The firefox UI is built using the primitives here plus a grid that sort of works the same way, except it lays out its children in both dimensions instead of one
# [14:07] <fantasai> anne says something about tables
# [14:07] <fantasai> dbaron: Our grids are weird, because they're neither row-primary or column-primary
# [14:07] <fantasai> dbaron: I don't know if it's something we'd be happy standardizing
# [14:07] <fantasai> jdaggett: good weird or bad weird?
# [14:07] <fantasai> dbaron: some of both
# [14:08] <fantasai> dbaron: you can have a grid, give it a set of rows, then a set of columns
# [14:08] <fantasai> anne: They overlap?
# [14:08] <fantasai> dbaron: yes (?)
# [14:08] <fantasai> Chris: It might be useful to give some background on what XUL uses
# [14:09] <fantasai> Daniel: you can also say it's already implemented and this is a standardization of the model use by XUL
# [14:09] <fantasai> anne: I still think it's confusing that Ian Hickson is listed as active editor and from Opera Software
# [14:09] <fantasai> Daniel: We can write formerly of Opera Software, or list him as a Previous Editor
# [14:09] <fantasai> people prefer Previous Editor
# [14:10] <fantasai> Alex: I don't think it conflicts with grid-positioning. Overlaps, probably yes
# [14:10] <fantasai> dbaron: I think there's a lot of overlap
# [14:10] <fantasai> dbaron: There's been some discussion on www-style about ways to do flex in other things rather than just the box
# [14:10] <fantasai> dbaron: For example, making margins flexible
# [14:11] <fantasai> dbaron: Some people have been saying flex could be units.. there have been a lot of ideas thrown in here
# [14:11] <fantasai> Daniel: From my experience building apps with XUL, what we have here is adequate
# [14:12] <fantasai> fantasai: You'd have to use a lot of extra elements
# [14:12] <fantasai> dbaron: Yeah, in XUL you typically use spacer elements
# [14:12] <fantasai> jdaggett: Is there interest at Apple for doing more with this?
# [14:12] <fantasai> dbaron: I think so. I think they use this in things like iPhone apps
# [14:13] <fantasai> dbaron: and widget things that use WebKit
# [14:13] <fantasai> Anne: Opera has interest in adding a third implementation, if it's better defined than now
# [14:13] <fantasai> Anne: We haven't started because we think adding a third implementation of vagueness wouldn't be a good idea
# [14:14] <fantasai> RESOLVED: Change Ian's editor's status and publish flexbox as FPWD
# [14:16] <fantasai> Topic: Vertical-align issue
# [14:16] <fantasai> Steve: I had an action item to come up with more testcases
# [14:18] <fantasai> ACTION: Steve post testcase to www-style
# [14:18] * RRSAgent records action 7
# [14:18] * trackbot noticed an ACTION. Trying to create it.
# [14:18] <trackbot> Created ACTION-155 - Post testcase to www-style [on Steve Zilles - due 2009-06-11].
# [14:18] <fantasai> Steve loads his testcase into Safari, IE, and Firefox
# [14:18] <fantasai> Steve: I've got Opera somewhere else...
# [14:19] <fantasai> Steve: Basically the issue was, if I've got large things that are bottom and top aligned, where does the text show up?
# [14:19] <fantasai> Steve: The arrow points up if it's top-aligned, down if it's bottom-aligned
# [14:19] <fantasai> Steve: On all of these, they're the same but
# [14:20] <fantasai> Steve: if I pick up Opera ...
# [14:20] <fantasai> Steve: What we can tell is, if I have only one object that is top or bottom aligned, it makes a difference to these various things
# [14:20] <fantasai> Testcase 1 shows TEST plus an arrow pointing up
# [14:21] <fantasai> all browsers align the top of the text aligned to the top of the container
# [14:21] <fantasai> Testcase 2 shows TEST plus an arrown down
# [14:21] <fantasai> Safari, IE, and Firefox bottom-align TEST, but Opera top-aligns it
# [14:24] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [14:24] <fantasai> Testcase 3 shows TEST plus an arrow up followed by an arrow down
# [14:25] <fantasai> All but Firefox align TEST to the top; Firefox aligns it down
# [14:25] <fantasai> Testcase 4 shows TEST plus an arrow down followed by an arrow up
# [14:26] <fantasai> All but Opera align TEST to the bottom; Opera aligns it to the top
# [14:26] * ChrisL loves "firefox is kind of like anti-opera"
# [14:26] <fantasai> Testcase 5 shows TEST plus a tall arrow up followed by a short arrow down
# [14:27] <fantasai> TEST is aligned to the top in all but Firefox
# [14:27] <fantasai> Firefox shifts TEST down about 1em
# [14:28] <fantasai> dbaron: It looks like Firefox, whenever it sees something bottom-aligned, it pushes the root so that it's bottom-aligned
# [14:28] <fantasai> dbaron: But it does so only for the height of the things that are bottom-aligned
# [14:28] <fantasai> dbaron: It's pushing the root down to match the bottom-aligned thing, assuming there are no top-aligned things
# [14:29] <fantasai> Testcase 6 shows TEST plus a tall arrow down followed by a short arrow up
# [14:29] <fantasai> All but Opera aligns to the bottom; Opera aligns to the top
# [14:30] <fantasai> Testcase 7 shows TEST plus a short arrow up followed by a tall arrow down
# [14:30] <fantasai> Safari aligns TEST about 1em above the bottom
# [14:31] <fantasai> IE aligns TEST to the bottom
# [14:31] <fantasai> Opera aligns TEST to the top
# [14:31] <fantasai> Firefox aligns TEST to the bottom
# [14:31] <fantasai> Steve: Opera always aligns to the top
# [14:32] <fantasai> Steve: IE seems to be aligning to the biggest thing
# [14:32] <fantasai> Steve: What Safari is doing here seems to be similar to what mozilla is doing, except the other way around
# [14:33] <fantasai> Testcase 8 shows TEST plus a short arrow down followed by a tall arrow up
# [14:33] <fantasai> Safari aligns TEST about 1em below the top
# [14:33] <fantasai> IE aligns to the top
# [14:33] <fantasai> Opera aligns to the top
# [14:33] <fantasai> Firefox aligns TEST about 1em below the top
# [14:34] <fantasai> General agreement that IE's behavior seems to make the most sense
# [14:34] <fantasai> dbaron: So the largest wins, but if there are multiple the same size then the first one wins
# [14:34] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
# [14:37] <fantasai> concern about randommness when things are close to the same size
# [14:38] <fantasai> dbaron: You can get into that with fonts that are close to the same size, but may or may not be depending on what's available on the system
# [14:40] <fantasai> ....
# [14:40] <fantasai> dbaron: Basically these things are all subtrees, when you're using top/bottom alignment
# [14:40] <fantasai> dbaron: non-top/bottom alignment are all linked up into subtrees
# [14:40] <fantasai> dbaron: When you're doing top/bottom alignement, you're aligning the subtrees
# [14:40] <fantasai> dbaron: Whichever subtree is tallest, that determines the height of the line
# [14:41] <fantasai> (dbaron is addressing Alex's concern about whether alignment will affect line breaking)
# [14:41] <fantasai> dbaron: By the time you do top/bottom align, you've already figured out the height of the line
# [14:42] <fantasai> ...
# [14:44] <fantasai> Steve: You could do what IE does and align to the biggest thing, and then if there are multiple always align to the top or always align to the bottom
# [14:44] <fantasai> Steve: Instead of taking the first
# [14:44] <fantasai> Steve: So the alignment doesn't depend on the order of items
# [14:44] <fantasai> Bert: ...
# [14:44] <fantasai> Steve: We had a discussion about where inline blocks should align
# [14:44] <fantasai> Steve: We went and looked at a bunch of books
# [14:44] <fantasai> Steve: at Tantek's
# [14:44] <fantasai> Steve: went to a bookstore
# [14:45] <fantasai> Steve: Came to the conclusion that the inline block should align its bottom line with the baseline
# [14:45] <fantasai> Steve: I don't know if there's an equivalent thing here, to assume bottom.. would that match what designers would expect
# [14:45] <fantasai> Bert: That might depend on the writing system. Here we might assume bottom, but in India not
# [14:46] <fantasai> Steve: We could ask the design community, but I'm not sure how to express the question in a way that they'd understand
# [14:46] * Joins: myakura (myakura@122.29.15.50)
# [14:46] <fantasai> Steve: But there's no obvious choice from what's implemented
# [14:46] <fantasai> Steve: I think trying to avoid having order matter would be a better solution
# [14:47] <fantasai> Alex: I'm not sure. You might have seven bottom aligned and one top aligned
# [14:47] <fantasai> Alex: ...
# [14:47] <fantasai> Steve: My main reason for concerning myself with ordering is that I suspect the behavior will appear to be more random if I take it into account
# [14:48] * fantasai thinks we should just center it
# [14:52] <fantasai> Steve: I'm willing to take an action item to write the rules if we can decide whether we want it order-specific or not
# [14:52] <fantasai> Bert: If I'm mixing things, I don't think I care.
# [14:53] <fantasai> Alex: IE prefers order dependent alignment :)
# [14:54] <fantasai> ...
# [14:55] <fantasai> Steve: The default for images is to baseline-align
# [14:55] <fantasai> dbaron: I'd like to keep order-dependence because we had three browsers that followed it
# [14:55] <fantasai> correction, only two
# [14:58] <fantasai> IE7 and below render like Opera
# [14:58] <anne> yay for Opera!
# [14:58] <fantasai> dbaron: Then let's do what IE7 and Opera do
# [15:00] <fantasai> Steve: But it gives the wrong answer when you have one thing that's bottom-aligned
# [15:05] * sylvaing -ms-vertical-align-replace: ie7;
# [15:08] <dbaron> http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
# [15:09] <fantasai> ACTION: Steve write proposals for both order-dependent and order-independent vertical-alignment
# [15:09] * trackbot noticed an ACTION. Trying to create it.
# [15:09] * RRSAgent records action 8
# [15:09] <trackbot> Created ACTION-156 - Write proposals for both order-dependent and order-independent vertical-alignment [on Steve Zilles - due 2009-06-11].
# [15:32] <anne> scribenick: anne
# [15:32] <anne> Topic: Paged Media
# [15:33] <anne> [silence]
# [15:38] <anne> Topic: Paginating content into zero height pages or columns
# [15:38] <anne> dbaron: don't
# [15:38] <anne> fantasai: what do you do
# [15:38] <anne> alexmog: you have to avoid inifinite loops
# [15:38] <anne> fantasai: we can say it's undefined
# [15:39] <anne> [missed]
# [15:39] <anne> fantasai: you need to know when it ends
# [15:39] <anne> s/[missed]/Arron: don't render them
# [15:39] <anne> alexmog: every pagination engine i worked on forced one character on a page
# [15:40] <anne> alexmog: it would have a boolean somewhere "I've put something on this page"
# [15:40] <anne> alexmog: maybe a border, or some other continuation
# [15:40] <anne> fantasai: if I have a 10px box and put it into 3 zero height columns
# [15:40] <anne> fantasai: what do I geT?
# [15:40] <anne> alexmog: I don't think we should define it here
# [15:40] <anne> alexmog: 1px could be considered process
# [15:41] <anne> alexmog: could give up and continue to the next one
# [15:41] <anne> alexmog: we could say that the user agent should make sure there's a finite number of pages
# [15:41] <anne> Topic: image-fit and image-position
# [15:41] <anne> fantasai: SVG didn't like these property names
# [15:41] <anne> fantasai: we have no suggestions
# [15:42] <anne> fantasai: maybe merge with preserveAspectRatio
# [15:42] <anne> fantasai: best I came up with was content-fit
# [15:42] <anne> dbaron: what's wrong with image-fit?
# [15:42] <anne> fantasai: doesn't make sense what SVG would use it for
# [15:42] <anne> fantasai: we called it image-fit to make it clear it does not apply to non replaced element
# [15:42] <fantasai> s/maybe/SVG wants to/
# [15:42] <anne> s/SVG/SVG WG/g
# [15:43] <anne> dbaron: if you don't like a name please propose a better name
# [15:43] <anne> ChrisL: I thought a name was proposed
# [15:43] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0134.html
# [15:44] <anne> anne: that's actually a message from zcorpan and not from the SVG WG
# [15:44] <shepazu> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
# [15:45] <fantasai> dbaron: content doesn't sound like something that applies only to replaced elements
# [15:45] <anne> dbaron: content doesn't sound like something that only applies to images or just replaced content
# [15:46] <shepazu> http://www.w3.org/2009/03/16-svg-minutes.html#item06
# [15:46] <anne> ChrisL: Opera has asked for a new property from CSS to which the SVG preserveAspectRatio attribute would match
# [15:46] <shepazu> dbaron: content doesn't sound like something that only applies to images or just replaced content
# [15:46] <anne> ChrisL: however that SVG feature applies to the whole document so naming need to take that into account
# [15:46] * MikeSmith to shepazu - I reckon ed needs to figure out how to quote messages little more succinctly.. instead of ">>>>>>>" x N, with one sentence of actual response
# [15:47] <anne> dbaron: I prefer fit over content-fit
# [15:47] <anne> s/dbaron:/dbaron,/
# [15:47] <dbaron> s/dbaron,/dbaron:/
# [15:47] <anne> s/dbaron: content/dbaron, content/
# [15:47] * shepazu oops... that link is to the minutes where SVG discussed it
# [15:47] * shepazu @MikeSmith yeah :)
# [15:48] <anne> SZ: the natural thing would be fit-replacement
# [15:48] <anne> dbaron: we don't expose the term replace to authors and I'd like to keep it that way
# [15:48] <anne> SZ: if that's what it applies to it seems natural to call it that
# [15:48] <anne> ChrisL: with renaming it the values need to change [example not scribed]
# [15:49] <anne> fantasai: people gave feedback that the new keywords are much clearer
# [15:49] <anne> fantasai: these are fill, cover and contain
# [15:49] <anne> SZ: how does that map to SVG?
# [15:49] <anne> SZ: I think SVG has keywords for things map into a box
# [15:50] <anne> dbaron: fill is the same as slize and cover is the same as meet or is it the other way around?
# [15:50] <fantasai> various suggestions that came in: content-fit + content-position, fit-scaling + fit-position, object-fit or object-scale ...
# [15:50] <anne> SZ: slice and meat both preserve aspect ratio?
# [15:50] <anne> fantasai: cover is the same as slice, contain is the same as meat, and none is the same as fill
# [15:50] <fantasai> s/meat/meet/
# [15:50] <ChrisL> http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute
# [15:50] * sylvaing "it's cool" "wow"
# [15:51] <anne> s/meat/meet/g
# [15:51] <dbaron> [working group undoes substitution and arrives at Salami]
# [15:52] <fantasai> The alignment parts of pAR are a separate property, currently called image-fit
# [15:52] <fantasai> It takes all the value that background-position takes
# [15:52] <anne> ChrisL: I think background-position covers all, yes
# [15:53] <anne> [i.e. covers the same features as SVG]
# [15:54] <anne> fantasai: we can go back to fit and fit-position
# [15:54] * Joins: szilles (chatzilla@193.51.208.72)
# [15:54] <anne> anne: I'd support that
# [15:54] <anne> fantasai: my main problem is that fit is not a shorthand
# [15:54] * Zakim anne, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [15:55] <anne> Zakim, no
# [15:55] <Zakim> I don't understand 'no', anne
# [15:55] <anne> Zakim, mu
# [15:55] <Zakim> I don't understand 'mu', anne
# [15:55] <anne> anne: we could merge them; i.e. fit: <keyword> <background-position>
# [15:55] <anne> fantasai: fit-position and fit-scale
# [15:55] <anne> anne: why not make it a single property?
# [15:56] <anne> fantasai: position doesn't need to be specified in a lot of cases?
# [15:56] <anne> anne: could make it optional
# [15:56] <anne> SZ: what about inheritance? typical reason for splitting properties
# [15:57] <anne> fantasai, it is currently inherited
# [15:57] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
# [15:57] <anne> s/fantasai,/fantasai:/
# [15:58] <anne> dbaron: existing cases where we have a property that is a superstring of another is font-size and font-size-adjust, pitch and pitch-range and color-interpolation and color-interpolation-filters
# [15:59] <anne> dbaron: plus fill-* and a bunch of stroke-*
# [15:59] <anne> anne: in SVG it's a single attribute and it doesn't seem to be a problem there
# [15:59] <anne> ChrisL: true
# [16:00] <anne> fantasai: would be ok with me; HP prolly has an implementation but they are prolly ok with changing it
# [16:00] <fantasai> Melinda checked with the print implementors before she left
# [16:00] <dbaron> also speak and speak-*
# [16:01] <anne> SZ: one example Melinda was using was generation of compact sheets
# [16:01] <anne> s/compact/contact/
# [16:01] <anne> SZ: rather than taking every image I would like to able to put the fit piece into the body but separately set the position
# [16:02] <anne> SZ: whether that's true or not I don't know
# [16:02] <anne> fantasai: anne said that if we find out there's a reason to split them we can split them later
# [16:02] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [16:03] <anne> SZ: you might not know what the keyword is
# [16:03] * billyjackass is now known as MikeSmith
# [16:04] <anne> SZ: I don't know; I just tend to distrust pulling things together
# [16:04] <anne> anne: could have fit-type
# [16:04] <anne> fantasai: fit-style!
# [16:04] <dbaron> We could just have a fit. :-)
# [16:05] <anne> [and there was much rejoicing]
# [16:05] <anne> szilles: tentative resolution is to have one property called fit consisting of two components
# [16:06] <anne> SOMEWHAT RESOLVED: have one property called fit that pulls together image-fit and image-position
# [16:06] <anne> Topic: difference between forced page breaks and natural page breaks
# [16:07] <anne> howcome: you edited 9.4 which is currently projected
# [16:07] <anne> howcome: I think rule 1 should be simpler
# [16:07] <anne> howcome: that when a forced page break occurs margins are preserved
# [16:07] <anne> howcome: and when natural page break occurs margins are set to zero
# [16:08] <anne> howcome: I'm suggesting a principle where we also preserve margin-bottom
# [16:08] <anne> howcome: it's a simpler principle
# [16:08] <anne> fantasai: then you'd end up with a gap on the next page
# [16:08] <anne> fantasai: e.g. when you have a 6em bottom margin and 3em space we don't want a new page
# [16:09] <anne> fantasai: how about we say that the margin is truncated
# [16:09] <anne> howcome: I don't reallycare but the principle simpler
# [16:09] <anne> s/reallycare/really care/
# [16:09] <anne> s/principle/principle is/
# [16:09] <anne> dbaron: if there was a border or background on an ancestor then you can tell the difference
# [16:10] <anne> dbaron: the question is how low the background and/or border of the parent has to go
# [16:10] <anne> dbaron: if the border needs some sort of visual space you need some kind of padding
# [16:10] <anne> howcome: I'm ok leaving this as is
# [16:11] <anne> howcome: shouldn't forced page breaks be discussed in the next section
# [16:11] <anne> Topic: border-break properties
# [16:11] <anne> s/border-break/break-*/
# [16:12] <anne> fantasai: I can put those new properties in here
# [16:12] <anne> howcome: that's all I wanted to know
# [16:12] <anne> fantasai: the main concern is that implementations of this module have to implement the new names
# [16:12] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
# [16:12] <anne> howcome: isn't that what we want?
# [16:12] <anne> anne: you could say that some of the values are conditional on the multicol draft
# [16:13] <anne> fantasai: multicol can define those
# [16:13] <anne> howcome: fits better here
# [16:13] <anne> howcome: that's it for me
# [16:13] <anne> glazou: anything else?
# [16:13] <anne> [silence]
# [16:14] <anne> Topic: CSS 2.1 grammar issue
# [16:14] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-71
# [16:15] <anne> fantasai: Bert said this was already clearly defined in 2.1 but the resolution was to change 2.1
# [16:15] <anne> fantasai: the resolution we had was that if you see something that looks like an @rule within a declaration block you have to parse it as if it was an @rule
# [16:16] <anne> Bert: this means that the rule that was in the spec doesn't apply and that implementations have to change
# [16:16] <anne> Bert: i believe we decided that nested @rules have to come at the end
# [16:17] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Sep/0076.html
# [16:17] <anne> Bert: otherwise CSS 2.1 parsers would not skip the @rules
# [16:17] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [16:17] <anne> Bert: margin boxes inside @page
# [16:18] <anne> Bert: the CSS 2 spec is more stable
# [16:19] <anne> anne: for forward compatible parsing it would be better if @rules were parsed correctly
# [16:19] <anne> Bert: it would be better if @rules where not nested at all
# [16:19] * billyjackass is now known as MikeSmith
# [16:20] <anne> fantasai: change definition of @page to allow atrules
# [16:20] <anne> fantasai: or make it general that it can be done everywhere
# [16:20] <anne> ChrisL: i think it should be general
# [16:20] <anne> glazou: I agree
# [16:20] <anne> anne: I also agree
# [16:21] <ChrisL> better to make the general change, otherwise we always have to explain why @page is special
# [16:21] <anne> dbaron: do these @top-... things take other properties than content?
# [16:21] <anne> fantasai: yes
# [16:21] * Quits: szilles (chatzilla@193.51.208.72) (Ping timeout)
# [16:22] <anne> dbaron: your compat issues would go away if you remove the @ and add a semi colon
# [16:22] <dbaron> top-left: { content: "foo"; };
# [16:22] <anne> dbaron: actually, I was suggesting making the block a value of a property
# [16:23] <fantasai> fantasai: The problem isn't where does the @rule end, it's does the @rule
# [16:23] <fantasai> end the declaration.
# [16:23] <fantasai> property: value; @key { ... } property2: value;
# [16:23] <fantasai> fantasai: The question isn't whether @key { ... } stays together, it's
# [16:23] <fantasai> whether it's considered part of the property2 declaration or not
# [16:23] <anne> Bert: in @page they're not; they're declarations
# [16:25] <anne> glazou: do you have a proposal Bert?
# [16:25] <anne> Bert: as far as I can see it already ignores @rules
# [16:26] <anne> Bert: we recently updated this text
# [16:27] <anne> Bert: statements cannot start with a property
# [16:27] <anne> Bert: @page contains declarations
# [16:28] <anne> Bert: people didn't want a mixture of declarations and atrules
# [16:29] <anne> dbaron: it seems a problem if we extend beyond the room forward compatible parsing rules give
# [16:29] <anne> dbaron: we need either need more room or take better care of what is provided
# [16:30] <anne> Arron: proposals?
# [16:30] <anne> Bert: my proposal was from January '09
# [16:31] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Jan/0173.html
# [16:35] <anne> [proposals on whiteboard; insert possible photo here]
# [16:35] <anne> dbaron: I'm gonna say it's too late for 4
# [16:35] <anne> fantasai: 4 was our last resolution
# [16:37] <anne> Bert: we can define a new construct but we still need implementations to align
# [16:38] <anne> Bert: my proposal grammatically allows mixing of atrules and declarations but atrules have to come after declarations
# [16:38] <anne> Bert: that is compatible with existing implementations, but maybe not good for @page
# [16:39] <anne> howcome: number 3 is just a grammar thing?
# [16:39] <anne> Bert: it would introduce a block in the grammar
# [16:39] <anne> fantasai: the implementations that implement @page have to change
# [16:40] <anne> [some resentment over the design of @page]
# [16:40] <anne> [also some support]
# [16:41] <anne> fantasai: least disruptive solution would be 3
# [16:41] <anne> howcome: yes
# [16:41] <anne> glazou: yes
# [16:41] <anne> Bert: really?
# [16:41] <anne> fantasai: we could make a rule that atrules have to come after declarations
# [16:42] <anne> fantasai: but implementations that support nested atrules will have to keep their support in the current way
# [16:42] <anne> fantasai: it's non-conforming for an @margin- rule to come before declarations
# [16:43] <anne> fantasai: in a conforming CSS file you'd parse it ok regardless of your implementation, but for non-conforming files you keep the current behavior
# [16:43] <anne> Bert: I think less disruptive would be to take the atrules out of @page
# [16:43] <anne> fantasai: there's deployed implementations and content
# [16:43] <anne> howcome: yeah, I think that train has left
# [16:44] <anne> fantasai: my proposal is 3 -- @page can take a mix of atrules and declarations + margin boxes must come after declarations
# [16:45] <anne> anne: please don't bother authors for eternity with a silly conformance requirement because of some two year compat issue
# [16:49] <fantasai> fantasai: So my proposal is a combination of 2 and 3
# [16:49] <fantasai> 1. @margin-box rules must end in semicolon. (Print impl must change)
# [16:49] <fantasai> 2. @margin-box rule smust come after all declarations in @page. (Print impl must change)
# [16:49] <fantasai> 3. @page takes a new mixed declarations+@rules construct
# [16:50] <fantasai> (Impl must change invalid parsing inside @page)
# [16:50] <fantasai> 4. All declaration blocks can parse @rules that take the place of a declaration. (All impl must change invalid parsing in all declarations blocks.)
# [16:50] <fantasai> 4 is our previous resolution
# [16:50] <fantasai> 1 and 2 mess with existing implementations and content the most
# [16:51] <fantasai> 3 is probably the least disruptive
# [16:51] <fantasai> if we combine it with a recommendation that authors keep their @margin-box rules at the end of the @page rule
# [16:51] <fantasai> then they get backwards compatibility with current implementations
# [16:53] <anne> dbaron: I think just 3
# [16:53] <anne> anne: 3
# [16:54] <anne> sylvaing: 3 + 2 as note
# [16:54] <anne> Arron: 3 + 2 as note
# [16:56] <anne> SZ: 3 + 2
# [16:56] <anne> glazou: just 3
# [16:56] <anne> jdaggett: pass
# [16:56] <anne> Bert: 1
# [16:56] <anne> (second best, prefers something else)
# [16:56] <anne> alexmog: pass
# [16:56] <anne> howcome: pass
# [16:57] <anne> fantasai: 3 + 2 as actual req
# [16:57] <anne> ChrisL: 3 + 2 as ...
# [16:58] <fantasai> 3 passes
# [16:58] <fantasai> 2 passes as well, but should it be a note, a recommendation, or a requirement?
# [16:59] <ChrisL> zakim, remind us in 987 hours that its late
# [16:59] <Zakim> ok, ChrisL
# [17:00] <anne> dbaron: note
# [17:00] <anne> sylvaing: note
# [17:00] <anne> SZ: rec
# [17:01] <anne> glazou: abstain
# [17:01] <anne> Bert: rec
# [17:01] <anne> anne: note
# [17:01] <anne> jdaggett: abstain
# [17:01] <anne> alexmog: abstain
# [17:01] <anne> s/rec/req/
# [17:01] <anne> howcome: abstain
# [17:01] <anne> fantasai: rec/req
# [17:01] <anne> Arron: note
# [17:01] <anne> ChrisL: rec
# [17:02] <anne> 4 note
# [17:03] <anne> 4 rec/req
# [17:03] <anne> glazou: move to rec
# [17:03] <anne> dbaron: put it in as PR
# [17:04] <anne> RESOLVED: 3 + 2 = 5
# [17:04] <fantasai> RESOLVED: @page takes a new construct that mixes declarations and @rules (2.1 and css3-page)
# [17:04] <fantasai> RESOLED: css3-page includes a RECOMMENDATION that @margin-box rules come after all declarations in the page context
# [17:04] <fantasai> s/RESOLED/RESOLVED/
# [17:05] <fantasai> s/includes a RECOMMENDATION/RECOMMENDS/
# [17:06] * Parts: howcome (howcome@193.51.208.72)
# [17:15] <dbaron> Is this the group in question? http://www.itu.int/ITU-T/IPTV/
# [17:17] * Joins: howcome (howcome@193.51.208.72)
# [17:18] * Joins: dsinger (dsinger@17.202.35.52)
# [17:18] <dsinger> good evening
# [17:18] <dsinger> you came through as 'unknown' on my cell phone
# [17:19] <dsinger> I'm at my desk, so +1 408 974 3162 should work...
# [17:20] <Bert> http://www.itu.int/ITU-T/studygroups/com16/index.asp
# [17:20] <dbaron> http://www.itu.int/ITU-T/studygroups/com16/sg16-q13.html
# [17:21] <dbaron> dsinger, Bert is dialing
# [17:21] <glazou> calling now
# [17:22] <fantasai> ScribeNick: fantasai
# [17:22] <fantasai> Daniel: We received a liaison statement from the ITU and Bert sent a few comments about it
# [17:23] <howcome> daniel: we receved draft document, bert has commented
# [17:23] <fantasai> ScribeNick: howcome
# [17:23] <howcome> david: theiy're trying to describe a limited environment, but I'm not sure which one
# [17:24] <howcome> stevez: do we want to authorize any subset?
# [17:24] <anne> profiles are teh evil
# [17:24] <howcome> David: we already have a TV subset, no?
# [17:24] <howcome> Bert: webtv was the driver for that, we still have the draft
# [17:25] <howcome> Bert: one of my suggestions was to only have one TV draft
# [17:25] <dsinger> sounds like a good idea. profile proliferation (profileration?) is not good
# [17:25] <howcome> Daniel: whould we reference or publish a document?
# [17:25] <howcome> Bert: in the past, W3C has published
# [17:26] <howcome> Bert: the proposed subset for TV is quite similar to the mobile subset we already have
# [17:26] <howcome> Daniel: lists numerous differences....
# [17:27] <howcome> Various: similarities and differences are discussed
# [17:27] * dsinger that is too far away from the mike (tho I still agree)
# [17:27] <howcome> Chris: we should say: we're interested in your work, but you should reference our documents, not copy for them.
# [17:29] <howcome> SteveZ: I'd like to have a discussion on principles on subsetting. There should be as few as possible
# [17:29] <howcome> Chris: it would be good to have CSS on many devices
# [17:29] <howcome> SteveZ; maybe...
# [17:29] <howcome> <microphones moved>
# [17:30] <howcome> Chris: we shouldn't put them off, but find out what they want to do with it
# [17:30] <howcome> Chris: I'm concerned that they modify our definitions
# [17:30] <Zakim> dbaron, you asked to be reminded at this time to go home
# [17:30] <howcome> Anne: spending time educating them may not be worthwhile
# [17:31] <howcome> Bert: I understand that they want a definition...
# [17:31] <howcome> David: if they're defining a profile, they're not interested in interoperating with the web
# [17:33] <howcome> s/David/DavidBaron/
# [17:34] <howcome> Håkon/Anne: Opera implement CSS on various set-top boxes. We don't really like profiles.
# [17:35] <howcome> Håkon: if they need a profile, we can offer CSS1, CSS Mobile, or CSS 2.1
# [17:35] <dsinger> so, our response.
# [17:35] <dsinger> We're not sure whether you are
# [17:35] <dsinger> a) defining a limited implementation of web services, suitable for deployment on small devices like set-tops or TVs, but handling general web content
# [17:35] <dsinger> b) or defining a restricted environment for restricted purposes, such as displaying menus or other TV-specific content
# [17:35] <dsinger> Our comments are rather tentative, and are based on the assumption that it's (b).
# [17:35] <dsinger> We're unhappy about the fact that your spec. copies our document, and we'd prefer that you reference it, and (if a subset is needed) you identify the sections that you adopt. It's important to us (and implementors) that there not be differences between an 'IPTV' implementation and a 'W3C' implementation, and if you copy our specification and we later, for example, fox an error, that could occur. Even simple re-phrasing can result in subtle, awkward, difference
# [17:35] <dsinger> This is effectively defining a new profile, and we are hesitant to define many, and would prefer to do this collaboratively.
# [17:35] <dsinger> It is important to analyze such a restricted profile from two directions:
# [17:35] <dsinger> * is what is chosen to be included consistent, and complete, and implementable, or is there important functionality missing?
# [17:35] <dsinger> * what are the consequences of the missing material? what functionality and interop is lost?
# [17:35] <howcome> Bert: this makes sense
# [17:36] <howcome> Daniel: happy?
# [17:36] <dsinger> in particular, given general web content, and two browsers, one implementing IPTV CSS and the other W3C CSS, what happens when features in W3C but not IPTV are used in that content?
# [17:36] * Joins: MoZ (chatzilla@82.230.92.154)
# [17:36] <howcome> Elika: we are cocerned...
# [17:36] * glazou waves at MoZ
# [17:36] <howcome> Chris: we are heartbroken...
# [17:37] <glazou> s/cocerned/concerned
# [17:37] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-125
# [17:37] * MoZ google waves glazou
# [17:37] <howcome> Bert: they're expecting us to be stable -- what do we tell them?
# [17:37] <howcome> John: CSS 2.1 is relatively stable...
# [17:38] <howcome> David Singer: CSS3 is also on the way. It's difficult to answer them before we know what they're trying to do.
# [17:39] <dsinger> if they want a subset for a restricted purpose, we don't know what that purpose is...
# [17:39] <howcome> Elika: they should also look at the snapshot...
# [17:39] <fantasai> http://www.w3.org/TR/css-beijing/
# [17:39] <fantasai> It explains a lot of important things about our specs and their relative stability/obsolescence
# [17:39] <howcome> David Singer: ahh
# [17:39] <Bert> liaison statement: http://www.w3.org/Style/Group/2009/ls047-16.doc
# [17:40] * dsinger oohh
# [17:41] <howcome> David Singer: should I draft a response you can look at tomorrow morning? What else should be in there? Beijing draft?
# [17:41] <howcome> Elika: yes
# [17:43] <howcome> Håkon: we should say why we don't like profiles: we like interoperability
# [17:43] <howcome> SteveZ: we don't like ghettos
# [17:45] <howcome> SteveZ: one thing to ask for is a set of requirements
# [17:47] <howcome> Bert/Chris will add general text about W3C to be added to the reply
# [17:47] <Bert> http://www.w3.org/Style/Group/meetings.html
# [17:47] <howcome> DanielG: 2010 meeetings: one meeting will be in the bay area on 22-24 march, 2010 -- can Apple host?
# [17:48] <howcome> DanielG: we need projector, network, room for 15 people
# [17:49] <howcome> David Singer: I can't book a room until 6 months before, but in principle I agree.
# [17:49] * sylvaing free Macbooks ?
# [17:51] * dsinger a zip archive with an HTML page and a stylesheet
# [17:52] <howcome> various discussions: what format should we use for our reply?
# [17:52] * dsinger using features of CSS they chose not to include... :-)
# [17:53] <howcome> <phone hung up>
# [17:53] <sylvaing> cessation of hostilities #2
# [17:53] <howcome> meeting adjourned
# [17:54] * Quits: sylvaing (sylvaing@193.51.208.72) (Quit: sylvaing)
# [17:55] * Quits: dsinger (dsinger@17.202.35.52) (Quit: dsinger)
# [17:55] * Quits: glazou (glazou@193.51.208.72) (Quit: glazou)
# [17:59] * Quits: ChrisL (ChrisL@128.30.52.30) (Client exited)
# [18:01] * Joins: dsinger (dsinger@17.202.35.52)
# [18:02] <fantasai> http://test.csswg.org/source/submitted/css2.1/tables/
# [18:02] * Quits: jdaggett (jdaggett@193.51.208.72) (Quit: jdaggett)
# [18:05] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009May/0213.html
# [18:08] * Quits: howcome (howcome@193.51.208.72) (Ping timeout)
# [18:13] * Quits: Arron (arronei@193.51.208.72) (Ping timeout)
# [18:21] * Quits: dbaron (dbaron@193.51.208.72) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:25] * Quits: alexmog (alexmog@193.51.208.72) (Ping timeout)
# [19:13] * Quits: dsinger (dsinger@17.202.35.52) (Quit: dsinger)
# [19:30] * Quits: myakura (myakura@122.29.15.50) (Quit: Leaving...)
# [19:30] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.84 [Firefox 3.0.10/2009042315])
# [20:19] * RRSAgent excuses himself; his presence no longer seems to be needed
# [20:19] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [22:17] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# Session Close: Fri Jun 05 00:00:01 2009

The end :)