16:06:00 <RRSAgent> RRSAgent has joined #css
16:06:00 <RRSAgent> logging to http://www.w3.org/2011/07/25-css-irc
16:06:07 <Zakim> Zakim has joined #css
16:06:41 <plinss_> rrsagent, make logs public
16:06:47 <bradk> Is it david.baron on skype then?
16:06:57 <dino> dino has joined #css
16:07:04 <smfr> smfr has joined #css
16:07:04 <nimbupani> ScribeNick: nimbu
16:08:02 <dbaron> bradk, having trouble getting the thing to work
16:08:10 <florian> florian has joined #css
16:08:16 <nimbupani> Topic: CSSOM
16:08:32 <bradk> dbaron, OK, will wait for further instructions.
16:08:41 <nimbupani> glazou: report whats going on with CSSOM, what are the stuff we need to add, change. 
16:08:59 <shans> shans has joined #css
16:09:21 <nimbupani> glazou: anne, tell us where you are right now, what you need to add, change, etc
16:09:37 <dbaron> bradk, see /query
16:09:43 <kimberlyblessing> kimberlyblessing has joined #css
16:09:47 <nimbupani> anne: the OM covers how to serialize mediaq, selectors, stylesheets in general
16:09:59 <sylvaing> http://dev.w3.org/csswg/cssom/
16:10:06 <nimbupani> anne: it has alt stylesheet api so people can control stylesheet sets from scripts. 
16:10:17 <JohnJansen> JohnJansen has joined #css
16:10:23 <nimbupani> anne: it def processing requirements for the link header so you can associate stylesheets with documents via http
16:10:35 <nimbupani> anne: it then defines the "real" OM all the stylesheet rules and their apis
16:10:43 <nimbupani> anne: e.g. @import, @media, font-face, etc
16:10:56 <nimbupani> anne: there is a new thing called the values api, so far OM has been string based.
16:11:20 <dbaron> does somebody with a Mac want to try running skype on their machine for brad?
16:11:29 <nimbupani> anne: in 2003 we obsoleted parts of DOM level2 style that were object based but never wrote a replacement, section 6.6 in CSSOM draft sketches out how Object based API would look
16:11:47 <nimbupani> anne: lacking: implementors need to look at it to poke holes in idea before we formally define it.
16:12:00 <nimbupani> anne: this was the case a year ago, so people have not gotten around to looking at it yet
16:12:08 <arronei> http://dev.w3.org/csswg/cssom/
16:12:30 <nimbu> anne: there is a priority of list of features, e.g. to get to results styles of elements.
16:12:50 <smfr> s/results/resolved
16:13:25 <konaya> konaya has joined #css
16:13:36 <nimbu> anne: I would like to not add too much features before current features are interoperably implemented.
16:13:57 <nimbu> anne: we need to find out a plan on how to, since css is fairly modularized, how we do the same for the OM 
16:14:13 <nimbu> anne: if we get interfaces for components like callers, it would be best if they are defined in their respective drafts.
16:14:22 <nimbu> anne: it would mean those drafts would ahve some dependency on the OM
16:14:35 <nimbu> fantasai: could we split out the serialization into its own module
16:14:54 <nimbu> smfr: for css transforms we need to expose an api for matrix transformations. 
16:15:07 <stearns> s/callers/colors
16:15:11 <nimbu> anne: the color module needs to expose an api. 
16:15:23 <nimbu> anne: its not just serialisation but the whole…
16:15:40 <hober> good morning
16:15:46 <nimbu> anne: each draft that defines a "bracketed new thing", needs to define an interface to it as well. 
16:15:52 <nimbu> fantasai: two ways to do that
16:16:02 <nimbu> fantasai: have it paired with the module to define OM stuff
16:16:08 <vhardy> vhardy has joined #css
16:16:20 <nimbu> fantasai: for drafts that are advanced publish a .1 which includes OM stuff
16:16:43 <nimbu> fantasai: e.g. css color 3.1 or css color object model. 
16:17:17 <nimbu> fantasai: in some cases the editor of the module can do the OM stuff but in other cases the editor might not have the expertise, so we need two editors or more.
16:17:29 <nimbu> florian: if we have 3 3.1 and 4 some people can get confused
16:17:35 <nimbu> anne: maybe we have it into 4. 
16:17:53 <nimbu> anne: i think its best if its in same module as def and such will be tightly coupled
16:18:04 <nimbu> fantasai: going forward we can do that, but for some specs we cant do that
16:18:17 <nimbu> anne: maybe put them into 4 for current specs that you cant change.
16:18:29 <nimbu> florian: it might be quite a while before it becomes stable
16:18:49 <arno> arno has joined #css
16:18:58 <nimbu> fantasai: anther problem with OM is that it might hold back development of rest of the spec. 
16:19:11 <nimbu> anne: we might have to separate them
16:19:17 <nimbu> fantasai: we can cross-link the documents
16:19:32 <nimbu> arno: we might have conformance problem too, as OM is not necessary for implementations
16:19:36 <szilles> szilles has joined #css
16:19:59 <nimbu> s/arno/ aaronei
16:20:28 <nimbu> fantasai: suggestion to go with separate modules but paired, if we want to merge we can merge them later.
16:20:35 <nimbu> mollydotcom: what does it look like.
16:21:37 <nimbu> vhardy: for specs like css3 regions which have a little bit of OM in them, keep them in the spec rather than splitting
16:22:13 <nimbu> glazou: apart from css values, this doc is specification of current implementation, what are the plans for the future? 
16:22:26 <nimbu> glazou: i am a heavy user of OM it is not practical at this point
16:22:35 <nimbu> anne: it needs improvements we need more tests for existing stuff first.
16:22:57 <nimbu> anne: it has better def for DOM level 2 styles, which lacked a lot of details
16:23:12 <florian> s/improvements we/improvements but we/
16:23:37 <nimbu> glazou: everybody knows that OM is resolved, its probably time to push for new things. 
16:23:56 <nimbu> anne: making it more interoperably and finding more stuff …
16:24:33 <nimbu> glazou: if we do stabilization for the next 3 years, it requires commitment from editors, implementors. it would be more than 2 years before we implement the new stuff
16:24:48 <nimbu> glazou: we are not able to serialise stylesheets, css text.
16:24:58 <nimbu> anne: those are minor features its not smthing developers really want
16:25:02 <nimbu> glazou: they are not minor
16:25:11 <dbaron> s/css text/cssText/
16:25:22 <nimbu> arronei: they maybe minor for devs, but not for web browsers
16:25:43 <nimbu> glazou: people who are writing editors need to play with these things every day. we need to improve the OM for new services on the web
16:25:58 <szilles> szilles has joined #css
16:26:04 <nimbu> anne: we have not defined serialization for most of the things. Just adding new things does not seem to be a good way forward.
16:26:21 <nimbu> glazou: i know, we should start collecting new things we are doing to the OM, and what are the expectations from web authors.
16:26:29 <nimbu> anne: sure getting feedback from web authors would be great
16:26:57 <shepazu> (another interesting thing might be font/text metrics: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0004.html)
16:27:04 <nimbu> anne: better value api, once that is there, they want to have access to resolved vaules, there are various features browsers have added for their debugging tools, figure out which property calls current styles.
16:27:11 <nimbu> glazou: what are the rules that are being called at a given time
16:27:42 <nimbu> shepazu: in svg wg we have thought about adding font metric api, i thought it might be interesting 
16:27:45 <nimbu> anne: like in canvas?
16:27:58 <nimbu> shepazu: the thing in canvas might be suitable why not generalize for genereal users
16:28:13 <nimbu> dino: you do not exactly know thats the font being used. 
16:28:33 <nimbu> dino: all the canvas does is how long the piece of text was, does not tell you the ascenders,
16:28:41 <nimbu> szilles: or where the baselines are
16:28:48 <nimbu> shepazu: the things the canvas one does is useful
16:29:03 <nimbu> shepazu: i suspect chris saying web fonts working group will be interested in
16:29:23 <nimbu> anne: there have been requests for font loading api, but we have not figured out right way to do it
16:29:28 <tantek> tantek has joined #css
16:29:33 <nimbu> vhardy: how do you capture requirements? do u have a place for that?
16:29:48 <nimbu> anne: there is a page in whatwg wiki. we should probably create a place in csswg
16:30:15 <nimbu> glazou: long ago we had a list of suggestions for css3 we can have the list of suggestions for cssom
16:30:17 <anne> http://wiki.csswg.org/spec/cssom
16:30:31 <nimbu> sylvaing: do we have use cases? 
16:30:43 <nimbu> anne: it does not have much yet.
16:30:57 <nimbu> florian: anne says stabilize, glazou says new features
16:31:04 <nimbu> glazou: not new features now, but soon
16:31:17 <nimbu> anne: i am also curious what implementors think, last year, we discussed this
16:31:30 <nimbu> anne: TabAtkins said google was planning on experimenting on values api
16:31:35 <nimbu> TabAtkins: we are still planning on it
16:31:46 <nimbu> anne: it kinda depends on implementors as well how fast it will move forward
16:32:07 <nimbu> anne: if there is not sufficient interest there is no point in adding a bunch of things and spend time on this if there are other things more interesting
16:32:23 <szilles> szilles has joined #css
16:32:32 <kojiishi> kojiishi has joined #css
16:32:45 <nimbu> vhardy: would it make sense to get a list of features and get feedback from community. we have some input and prioritize which are important
16:33:19 <nimbu> glazou: microsoft has been doing online applications using formats that are not based on w3c standards. 
16:33:35 <ChrisL> ChrisL has joined #css
16:33:40 <nimbu> glazou: the cost for that [feedback] is low
16:33:46 <nimbu> glazou: anything else to decide o OM
16:34:16 <ChrisL> rrsagent, here
16:34:16 <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T16-34-16
16:34:28 <nimbu> vhardy: first set of extensions and ask for feedback?
16:34:33 <nimbu> glazou: no just ask for feedback
16:34:45 <nimbu> shepazu: i would like people to see action to review it
16:34:53 <nimbu> anne: that is more problematic than community input
16:35:26 <nimbu> anne: we have got a few feedback like features like resolved value, authors want access to browser's proprietary extensions for their debugging tools
16:35:33 <nimbu> anne: problem is getting implementors attention.
16:35:44 <nimbu> anne: i work for an implementor but I dont think opera can really drive this.
16:36:04 <nimbu> glazou: user feedback can help. the feedback for css3 created traction. 
16:37:22 <tantek> anne, are there particular web applications that would be helped (e.g. made faster, or new higher fidelity features) by more CSSOM features?
16:37:43 <nimbu> arronei: you have unique knowledge in the room, so your feedback would be useful
16:38:10 <nimbu> glazou: cost of a single missing feature of OM can be about 2000 likes of code. as you start duplicating the cost becomes prohibitive. 2 or 3 lines in c++ for 1000 lines of js
16:38:39 <nimbu> ACTION: glazou collect feedback from webdev community for CSSOM and put it on the wiki http://wiki.csswg.org/spec/cssom
16:38:39 <trackbot> Created ACTION-349 - Collect feedback from webdev community for CSSOM and put it on the wiki http://wiki.csswg.org/spec/cssom [on Daniel Glazman - due 2011-08-01].
16:38:58 <alexmog> alexmog has joined #css
16:39:13 <nimbu> anne: can we do one more item
16:39:19 <arno> let's get input from framework vendors as well (jQuery, Sencha, etc…)
16:39:31 <nimbu> anne: there is also the view module? can we publish it once more, so there is a link to the editor's draft
16:39:36 <nimbu> fantasai: its already in the module template
16:39:53 <nimbu> anne: since it is not published already, so it does not have that link
16:40:06 <nimbu> szilles: he says the view module does not have the new template	
16:40:12 <nimbu> fantasai: we can publish then
16:40:27 <nimbu> RESOLVED: Publish the CSSOM View module
16:41:20 <nimbu> Topic: CSS Regions and CSS Exclusions Floats
16:41:25 <tantek> possible classes of use-cases to drive CSSOM evolution: web app games, where greater responsiveness (speed) and higher fidelity experience are both desired.
16:41:34 <nimbu> vhardy: last meeting we decided to name it CSS Floats not Exclusions
16:41:49 <nimbu> vhardy: there is a ED that has resolution from last f2f there is a wd that was published after f2f as well
16:42:03 <nimbu> vhardy: wiki has a bunch of issues and usecases that we will go over
16:42:14 <nimbu> alan hooked up the test harness and the spec references it now 
16:42:40 <nimbu> vhardy: next step is to go over the bunch of issues we have and pub together a new draft
16:42:53 <nimbu> vhardy: for css exclusions we have the original fraft same as kyoto
16:43:06 <nimbu> vhardy: ms sent a proposal and glazou sent one over email
16:43:32 <nimbu> vhardy: we tried to converge on the proposals and the next step is to resolve issue sand produce new ED to propose as WD
16:43:46 <ChrisL> rrsagent, this meeting spans midnight
16:43:51 <szilles> s/sand/and/
16:44:35 <smfr> http://wiki.csswg.org/spec/css3-regions
16:44:57 <nimbu> vhardy: we discussed there was no formal resolution in previous meeting. there was a q on the amiling list if css regions should allow copying from element into flow instead of moving content into flow. the editors agree this is something we should move to future release might be interesting but more complicated, so proposal is not to do it now and see if there is consensus in not adding this feature at this time
16:45:04 <nimbu> smfr: def agree on that
16:45:20 <nimbu> RESOLVED: Issue 4: Copying Flow Content is not something we are looking at right now. 
16:45:25 <lhnz> lhnz has joined #css
16:45:55 <nimbu> vhardy: next issue is CSSOM issue. we dont have absility to find out which element is in a named flow
16:46:01 <nimbu> vhardy: there is no way to find that out right now.
16:46:23 <nimbu> vhardy: our proposal is to get an action item for alexmog and me to add to the next draft unless someone thinks this feature should not be in the draft
16:46:34 <nimbu> florian: are u going to do this programmatically or declaratively
16:46:42 <nimbu> smfr: that could be regions plural right
16:46:53 <nimbu> vhardy: programatically, plural
16:47:38 <nimbu> glazou: this will be useful for debugging tools
16:47:57 <nimbu> ACTION: vhardy alexmog to add an api to find out which element is in a named flow
16:47:57 <trackbot> Created ACTION-350 - Alexmog to add an api to find out which element is in a named flow [on Vincent Hardy - due 2011-08-01].
16:48:33 <nimbu> vhardy: in css should you be able to set display on grid cell?
16:48:43 <nimbu> vhardy:  how do we integrate with css grid
16:48:54 <nimbu> vhardy: one is to have a way to adress a gridcell to make it a region 
16:48:56 <nimbu> Hixie: 
16:49:17 <nimbu> vhardy: second, add an element as a child to the grid and declare it a region
16:49:46 <nimbu> alexmog: it would be interesting to have pseud elements for other virtual things like grid regions for really advanced scenarios. 
16:50:54 <nimbu> alexmog: in pseudo elements you cant get a OM you need an entirely diff mechanism
16:51:14 <nimbu> alexmog: it has to be a parallel model. 
16:51:15 <bradk> So one HTML element to create a grid slot, and another inside it to hold a flow?
16:51:26 <nimbu> szilles: there needs to be a CSSOM module that gives us back the faciilities
16:51:29 <JohnJansen> correct Brad
16:52:16 <nimbu> RESOLVED: Change the grid to integrate with css regions through regular elements
16:52:56 <nimbu> vhardy: if you want to grab content from flow, you use content property with from-flow. 
16:52:56 <JohnJansen> (in other words, not do anything special for grid)
16:53:22 <nimbu> vhardy: there was an alt proposal you should make two properties parallel and it should be separate from content use float from and use the flow name to get the content from the flow
16:53:36 <nimbu> vhardy: should we make it through two parallel properties
16:54:00 <nimbu> vhardy: after we have had more discussions we think this is more clear use flow-form: <flow name>
16:54:09 <nimbu> smfr: would flow-from work on pseudo elemtn before / after
16:54:13 <nimbu> alexmog: vhardy yes
16:54:36 <nimbu> dbaron: i am uncomfortable making an additional property here. as it seems to do same thing as content. 
16:55:08 <nimbu> alexmog: there are couple of considerations, content has a lot of baggage, there is content in css3 content, which is not where the spec is going.
16:55:23 <nimbu> alexmog: the flow-from applies to anything into a region.
16:55:38 <nimbu> alexmog: the content is somewhat different as it cant seem like it changes the nature of what it is applied to
16:56:08 <nimbu> fantasai: does that mean i cant have a table that accepts content from the region
16:56:26 <nimbu> vhardy: that is one of the issues, conceptually region is smthing that redirects content from somewhere else into this element.
16:56:33 <nimbu> s/vhardy/alexmog
16:57:03 <nimbu> fantasai: lets say i ahve a region and I want it to be a table row and I grab the contents of the table row and put it into regions what happens
16:57:09 <nimbu> alexmog: there is nothing in regions that wont work. 
16:57:30 <nimbu> fantasai: so thats not display-inside region you are not overriding display inside just putting contents into it.
16:57:41 <nimbu> vhardy: we have a proposal to limit regions to display-inside block.
16:57:52 <nimbu> vhardy: otherwise it will become too complicated. 
16:58:09 <nimbu> vhardy: we can resume discussion once we reach that. 
16:58:25 <nimbu> alexmog: i dont feel very strongly about flow-from w.r.t content
16:58:38 <nimbu> alexmog: content has a history that does not make it designed for this.
16:58:51 <nimbu> arno: how would flow-from property how would it interact with content
16:59:00 <nimbu> alexmog: content would be overriden
16:59:30 <nimbu> vhardy: content is grabbing content from an element but flow-from is grabbing a segment not whole element. so its different
16:59:48 <nimbu> plinss: thats what you get from from-flow so i dont see why thats a problem, you just need to adapt that notion to the content.
17:00:08 <nimbu> alexmog: from the content property you can figure out what content is, from region that is not the same.
17:00:21 <nimbu> fantasai: having one property that overrides another causes problems with cascade
17:00:38 <nimbu> fantasai: which one wins? we should use the cascade as thats what it is for.
17:00:53 <nimbu> vhardy: other people felt it was good to add a property. 
17:01:34 <nimbu> alexmog: content applies to inline flow-from doesn't. different compatibility. I am not sure it would always be that way. I am not sure if flow-from would always override. 
17:01:46 <nimbu> vhardy: content would only apply to before and after in 2.1
17:01:52 <nimbu> fantasai: in css3 it would apply to all. 
17:02:02 <nimbu> plinss: that has been the plan for 10/11 years at least
17:02:11 <nimbu> vhardy: the draft has the way you [fantasai] like it
17:02:21 <nimbu> vhardy: if majority feel we are good with content, I am okay with that.
17:02:27 <nimbu> alexmog: i dont have really strong feelings. 
17:02:57 <nimbu> alexmog: having seperat property makes writing spec easier. Understanding easier. Not redefine content
17:03:30 <nimbu> RESOLVED: Stick to content property and content: from-flow(<flow-name>)
17:03:57 <nimbu> vhardy: currently to put smthing in flow you use flow: <flow-name>
17:04:02 <ChrisL> does tha mean content can have internal structure, now?
17:04:28 <nimbu> vhardy: alexmog pointed out flow could be short hand, so should we use flow-into and reserve flow for shorthand
17:04:29 <ChrisL> or is it flattened text?
17:04:49 <dbaron> "rename flow into flow-into" needs to be written down to be comprehensible
17:05:07 <nimbu> smfr: flow-into does not work for me, how about flow-name
17:05:44 <nimbu> szilles it is doing two things naming and adding content to flow
17:06:00 <nimbu> smfr: which property is canonical in terms of naming of the flow
17:06:13 <nimbu> vhardy: the flows get their name from the first piece of content that is moved into the flow
17:06:21 <nimbu> smfr: it is a bit too magic for me
17:06:32 <nimbu> vhardy: we iterated over that and we ended ups ettling on this way to do it.
17:06:37 <glazou> CSS _is_ magic anyway :-)
17:06:40 <nimbu> smfr: this is more like it is belonging to a flow.
17:06:45 <nimbu> smfr: make this part of a flow. 
17:07:08 <bradk> I prefer just 'flow:'
17:07:12 <nimbu> alexmog: we tried things like flow-source and flow-target and those were very confusing.
17:07:32 <nimbu> glazou: we need ar esolution to move from flow to smthing
17:07:50 <nimbu> szilleswhat it actually is flow-out-to rather than into as it is taking it out of normal flow
17:08:01 <nimbu> RESOLVED: change flow from flow-smthing
17:08:37 <nimbu> vhardy: alexmog asked for renaming from-flow to flow-from 
17:08:57 <nimbu> jRESOLVED: rename content: from-flow to content: flow-from
17:09:07 <nimbu> RESOLVED: rename content: from-flow to content: flow-from
17:09:22 <nimbu> dbaron: it makes more sense to me the other way
17:09:42 <nimbu> alexmog: we have border-top-right 
17:10:25 <nimbu> vhardy: auto sizing of regions. this has been called as intrinsic size. i am not sure if all the history we have we are using intrinsic as a term in our discussions
17:10:33 <nimbu> vhardy: intrinsic has only been used for replaced content
17:10:48 <nimbu> fantasai: there is terminology for that in writing modes draft.
17:11:02 <fantasai> http://www.w3.org/TR/css3-writing-modes/#intrinsic-sizing
17:11:15 <nimbu> vhardy: i tried to stay clear of intrinsic size coz of possible confusion
17:11:19 <szilles> szilles has joined #css
17:11:27 <nimbu> vhardy: if we have auto-sizing in 1 or more dimensions how does it work
17:11:53 <nimbu> vhardy: we had a discussion with hyatt on mailing list, alexmog brought up more questions. this email is a summary of discussions at tha time
17:12:07 <nimbu> vhardy: the proposal was do we actually need to say anything about auto-sizing
17:12:31 <nimbu> vhardy: the main model i have been using for regions, the results should be identical if you have broken down regions into bits and pieces and moved them into regions
17:12:46 <nimbu> vhardy: so if I follow that model we dont need smthing
17:12:57 <nimbu> dbaron: the problem with that model is that the slicing depends on the size. 
17:13:27 <nimbu> alan: if you have not specified height there wouldnt be any.
17:13:39 <nimbu> alexmog: paginating content in terms of flexible size is really complicated.
17:14:11 <nimbu> szilles: the two dimensions inline and block the rules are slightly different. in inline you would want it to be like a block, in block progression dimension you are going to use breaks to control…
17:14:39 <nimbu> alexmog: even more complicated is when width is undefined we can come up with a width measurement, the final layout is difficult to do if you dont know what the width to be. 
17:15:08 <nimbu> alexmog: e.g. for float: right you need to figure out what the size is if it should be cleared or not. 
17:15:19 <nimbu> dbaron: whats the proposal?
17:16:09 <nimbu> vhardy: start with region 1 and then put all content in region 1. if anything that does not fit, you have a first segment and reminder will flow into next regions. if you have regions with undefined height, it just gets all the content. 
17:16:44 <nimbu> vhardy: at any point it would be like rest of the flow will be in the content. 
17:16:58 <nimbu> smfr: say u have a bunch of ps and a 1000 px wide div.
17:17:15 <nimbu> smfr: the first region is flexible width wise
17:17:25 <nimbu> smfr: sounds like you would make first region 1000px wide
17:17:40 <nimbu> dbaron: what is the proposal for what intrinsic size would be?
17:17:54 <nimbu> dbaron: intrinsic size is not a function of layout
17:18:05 <nimbu> alexmog: intrinsic is not the right term here.
17:18:13 <hober> If the intrinsic width of a region is 0, the designer wins because their layout "fails fast" & they immediately know they need to specify a width
17:18:15 <nimbu> alan: the proposal is intrinsic size does not apply
17:19:03 <nimbu> alexmog: we should not be using the word intrinsic here. 
17:19:28 <nimbu> dbaron: i sounds like you are talking about what the sizes of the regions are going to be. that is still a separate notion from intrinstic size
17:19:40 <nimbu> vhardy: intrinsic is used for replaced content 2.1
17:19:49 <nimbu> dbaron: we used for table, 
17:19:51 <arronei_> arronei_ has joined #css
17:19:57 <nimbu> dbaron: i am talking about preferred width and min width
17:20:10 <nimbu> fantasai: we call it two diff things based on if we are on tables chapter or not
17:20:33 <nimbu> szilles: there are two situations, 1. normal flow 2. out of normal flow. the rules for width and height calc are diff in those. 
17:20:47 <nimbu> szilles: u use intrinsic when you are out of normal flow and simple calc in normal flow
17:20:59 <nimbu> szilles: regions behave in exact same way. 
17:21:38 <nimbu> alexmog: 3 options: 1. if region size is undefined it is zero. that option works very well the standard box model rules apply regardless of where region is. 
17:21:52 <nimbu> the size will be calc using formula for box size. 
17:22:08 <nimbu> problem is when accidentally size is not set on a region it has no visibility and it is difficult to understand where it is.
17:22:13 <hober> that's a feature, not a bug
17:22:40 <nimbu> 2. if it has a specific intrinsic size, 3000 by 850 it would be seful as you might have forgotten to set a size and then you can see it and then make it right size.
17:22:49 <bradk> maybe we need 'position:flow' or 'position:flow(ident)', and then all flows are non-floating blocks.
17:23:06 <dbaron> s/3000 by 850/300 by 150/
17:23:16 <nimbu> normal box models wont apply.
17:23:20 <nimbu> and thats not helpful. 
17:23:28 <szilles> szilles has joined #css
17:24:15 <nimbu> alexmog: 3. size to content. we have to figure out what is going to fit into this region without exceeding max width max height if they are available.
17:24:34 <nimbu> alexmog: this is very complicated to implement, it would require more than 1 layout pass
17:25:05 <nimbu> alexmog: option 4. use normal box model calculations and if that ends up as still undefined with height, then use 300x850 intrinsic size. 
17:25:14 <nimbu> vhardy: it is like replaced content right.
17:25:22 <nimbu> alexmog: it is not like the second option replaced content. 
17:26:07 <nimbu> alexmog: the 4th option would be an implementation of normal box sizing where the box size is not considered at the point where it is on or not but at the end when it is resolved or not. 
17:26:10 <tantek_> tantek_ has joined #css
17:26:25 <hober> s/850/150/
17:26:33 <nimbu> thanks :)
17:27:41 <nimbu> i would expect devs to slice area into bunch of rectangles and use grid or flex box and then add content to the. 
17:28:17 <nimbu> vhardy: the first proposal, the width and height would be set to 0 if you do not set height or width. 
17:28:34 <nimbu> alexmog: this is a strong arg for default size to not be strict width/height
17:28:50 <nimbu> alexmog: if this region is going to have content in there, it wont have a size the flexbox and grid would give it. 
17:29:04 <nimbu> alexmog: for the pruposes of flex or grid it has to have a default size of 0.
17:29:10 <nimbu> alexmog: then grid would give it size
17:31:09 <nimbu> ???: for e.g. auto width should be as wide as containing block so edges touch on normal flow. those rules would be ignored as per proposal 1, and width would be set to 0. 
17:31:59 <nimbu> ???: the containers are typically well respected, we dont set to default size or width 0. so, which one is it that you are trying to achieve here. 
17:32:10 <nimbu> vhardy: the general question is what happens with auto widths and heights on regions
17:32:46 <nimbu> vhardy: the point that smfr made is that if you layout everything then your widths maybe off. 
17:33:10 <nimbu> vhardy: your usecase would naturally work, intrinsic height to default to 0 it is hard to make it work.
17:33:50 <nimbu> florian: in general resolving to 0 is smthing simple but not useful
17:34:11 <nimbu> mollydotcom: it is established and understood in devs, but now we are changing expectation. 
17:34:16 <sylvaing> s/???/rossen
17:34:45 <nimbu> alexmog: 0 is logical, if a region that is part of a chain of regions if it does not have any natural content, it creates 0 new rules for sizing it.
17:35:00 <nimbu> alexmog: it is a good default.
17:35:16 <nimbu> mollydotcom: default to 0 sounds to be very different from what you are saying
17:35:49 <nimbu> vhardy: i propose we actually tab this discussion and go back. the default behaviour is not useful, we need to consider usecases.
17:36:18 <nimbu> phil: I thought it worked with any kind of layout, some proposals sacrifice the notion that how the child layout will make use of available space given by parent layout
17:36:30 <mmielke> mmielke has joined #css
17:37:04 <nimbu> dbaron: vhardy's statement intrinsic size is 0 then size is 0 is incorrect
17:37:12 <nimbu> plenty cases otherwise
17:37:45 <nimbu> dbaron: for intrinsic widths, the obv sol do the intrinsic width computation do over entire contents of the flow.
17:38:13 <nimbu> dbaron: what we have not specified we have not specified intrinsic heights in block progression dimension. flexbox and this (some degree) depends on that concept.
17:38:43 <nimbu> dbaron: problem: they are a function of width not entirely intrinsic. 1 concept that is entirely intrinsic and another that is a function of width
17:39:21 <nimbu> dbaron: i can imagine a situation where you want to build heights in region by starting either from 1st or last. splitting at breaks and using as many regions from beginning or end to build some sort of intrinsics where you need them. It might give you useful behaviour for a bunch of htem
17:39:31 <nimbu> dbaron: there is a bunch of issues being conflated. 
17:39:44 <nimbu> dbaron: we need def for intrinsic sizes and we need to specify what actual resolved sizes for regions are.
17:40:18 <nimbu> szilles i heard you say the cal of size algorithm it does occasionally use intrinsic size but not necessarily use intrinsic size. That is critical to making it work, and we have a def of intrinsic size.
17:40:34 <cjon> cjon has joined #css
17:41:10 <nimbu> alexmog: if whereever in the cal we need the intrinsic size we consider all of the content or remainder of content from this to that. that makes it clear it might be expensive to calculate. it is really a fallback, so not going to be used all the time, so expensive should not be a problem there.
17:41:23 <nimbu> vhardy: that works for me
17:42:31 <nimbu> ACTION: vhardy Rework the issue of resolved sizes for regions and come up with an alt solution for the group along with use cases and examples 
17:42:32 <trackbot> Created ACTION-351 - Rework the issue of resolved sizes for regions and come up with an alt solution for the group along with use cases and examples  [on Vincent Hardy - due 2011-08-01].
17:43:23 <szilles> szilles has joined #css
17:44:07 <fantasai> <br type="coffee">
17:47:56 <tantek> tantek has joined #css
17:48:18 <tantek_> tantek_ has joined #css
17:50:05 <tantek_> tantek_ has joined #css
17:50:52 <nimbupani> nimbupani has joined #css
17:54:53 <miketaylr> miketaylr has joined #css
17:57:26 <JohnJansen1> JohnJansen1 has joined #css
17:57:29 <szilles> szilles has joined #css
17:58:45 <JohnJansen1> JohnJansen1 has left #css
17:59:10 <anne> anne has joined #css
17:59:13 <JohnJansen1> JohnJansen1 has joined #css
18:00:16 <JohnJansen1> JohnJansen1 is JohnJansen
18:00:57 <JohnJansen1> JohnJansen1 has left #css
18:01:48 <JohnJansen> JohnJansen has joined #css
18:04:30 <szilles> szilles has joined #css
18:04:38 <florian> florian has joined #css
18:05:12 <nimbupani> vhardy: region model, so the current spec has taken the approach that region is a general relation of an element relates to content
18:05:47 <plinss_> plinss_ has joined #css
18:06:33 <mmielke> mmielke has joined #css
18:06:38 <nimbupani> vhardy: instead of working with children as source of generated boxes you would layout, you can get set of elements from source which will be used with layout algorithm
18:07:27 <nimbupani> vhardy: looking at use cases, our thinking now is 1. they are like printed pages and lay it out from page box to page box. they are different viewport areas.
18:07:51 <nimbupani> vhardy: mixing regions that have different type, region thats a table, a flex box and put them in a chain does not seem to make sense.
18:08:05 <nimbupani> vhardy: as you would not know which kind of segment you get.
18:08:21 <nimbupani> vhardy: limit regions to apply to things that are display-inside: block
18:08:31 <nimbupani> it could be table-cell or anything that has display-inside: block.
18:08:57 <nimbupani> vhardy: proposal restriction on regions to contain display-inside: block
18:09:15 <nimbupani> fantasai: i can see reasons for display-inside of flexbox.
18:09:27 <nimbupani> dbaron: the current flexbox is different from our implementation. 
18:09:41 <nimbupani> fantasai: i can see wanting to have two flexbox containers and have a flow on them.
18:10:01 <nimbupani> dbaron: the way flexbox spec works is the container is display: flexbox, the items in it is display: block
18:10:03 <mielke> mielke has joined #css
18:11:16 <nimbupani> vhardy: the idea is to simplify the implementation. not limit the future.
18:11:22 <nimbupani> vhardy: there are usecases for tables as well. 
18:11:49 <nimbupani> vhardy: then we have to deal with mixing different float types which are much more complicated.
18:11:58 <nimbupani> fantasai: I am okay as long as we can expand it in that direction
18:12:24 <nimbupani> fantasai: I can see why you would want other display types
18:12:31 <nimbupani> alex: i want to keep the first version of spec simple.
18:12:51 <nimbupani> vhardy: what we are doing is not painting us in a corner. we should have a note saying in future we would extend it.
18:13:08 <nimbupani> RESOLVED: for this version we are limiting regions to be block containers
18:13:22 <nimbupani> ACTION: vhardy add a note to expand this in the future for different types of containers
18:13:22 <trackbot> Created ACTION-352 - Add a note to expand this in the future for different types of containers [on Vincent Hardy - due 2011-08-01].
18:14:03 <szilles> szilles has joined #css
18:14:11 <nimbupani> vhardy: region breaks. CSS 2.1 has page breaks that only work on paged media. css3 column breaks and page breaks.
18:14:32 <nimbupani> vhardy:  page breaks slices a column into two, the next column box moves to next page.
18:14:46 <nimbupani> vhardy: how do you break content when you layout between regions
18:15:29 <nimbu> vhardy: those questions also arise for multicol
18:15:45 <nimbu> vhardy: if u have breaks in ur content and nesting what does it mean for heirarchy
18:16:18 <nimbu> vhardy: current spec: we will add a new type of break and thats what content will honor when it lays out content. alex objected to it so we came up with alt proposals
18:16:39 <nimbu> vhardy: instead of saying i need to have a new break, state which breaks you will honour
18:16:53 <nimbu> vhardy: as a region you state which breaks you honor
18:17:05 <nimbu> vhardy: what that means is content is break aware and container aware.
18:17:36 <nimbu> vhardy: the content can annotate myself, you can then have container types and associated break types. 
18:18:10 <nimbu> alex: is this clear, or do we need a picture
18:18:20 <bradk> picture
18:18:43 <ChrisL> picture and photo
18:19:17 <nimbu> alex: using either column breaks or page breaks producing multicol layout with regions there is no way to define currently contents going from one column like region to another column like region if you have a columnbreak, but if you have a page break then you need to go to a new page with a new container
18:19:29 <nimbu> alex: we need to communicate this region is a column and another region is a page.
18:19:57 <bradk> so, column-break would break to next region if both regions are each one-column blocks?
18:20:14 <nimbu> alex: if we decide we dont need that kind of precise control in regions coz that content would be designed in smaller pieces, with one kind of break. we would gravitate to never need column/page break difference. but only one kind of break.
18:20:30 <bradk> unless a block is identified as a page somehow?
18:20:56 <nimbu> vhardy: one of the extensions is to generalise ideas and do named breaks
18:21:07 <nimbu> vhardy: my content should know what kind of container it is laid out on.
18:21:26 <nimbu> vhardy: another approach is if your content just wants to know where it should break. 
18:21:43 <nimbu> vhardy: second approach content does not know about container types or what kind of breaks are being used.
18:22:03 <nimbu> vhardy: second one is a simplifying assumption and want feedback.
18:22:20 <nimbu> vhardy: 1. breaks are container agnostic 2. breaks are container aware.
18:22:33 <nimbu> smfr: there has to be a precedent here? what does page layout do.
18:22:54 <nimbu> alex: yes, they do different kinds of breaks. page break and section break. 
18:23:01 <nimbu> vhardy: ur q is on existing tools?
18:23:05 <nimbu> smfr: existing tools
18:23:39 <nimbu> alex: columns are onlu possible as full-page columns or full section columns, so page break is always a column break. there is no such thing as breaking multi-col block …
18:23:52 <nimbu> alan: in indesign you have a column break, page break, frame-break
18:24:05 <nimbu> alex: whats the diff between frame/page break
18:24:12 <nimbu> alan: frame break is like a region
18:24:19 <nimbu> florian: can u have nested frames
18:24:25 <bradk> frame breaks can jump across several pages to get to next frame to, right?
18:24:32 <nimbu> alan: I think so, i do not know if it makes a difference in the break scenario.
18:24:40 <tantek> tantek has joined #css
18:24:51 <nimbu> vhardy: frames are more like regions
18:24:56 <nimbu> alan: yes
18:25:38 <nimbu> plinss: dont confuse column breaks with region breaks as column only breaks to another col not a region
18:25:53 <nimbu> plinss: i dont see why you should respect other kinds of break. 
18:26:04 <nimbu> alex: so how do you know the region is in the next page?
18:26:10 <nimbu> plinss: from the pagination model.
18:26:38 <nimbu> alex: what is a page?
18:26:49 <nimbu> fantasai: a page in css is a page box
18:27:22 <nimbu> fantasai: in mozilla those are page boxes. particular kind of css box
18:27:36 <nimbu> alex: in IE they are also kind of a box. 
18:28:18 <nimbu> fantasai: a page break requests a break between page boxes.
18:28:43 <nimbu> alex: i would like to be able to write page view in a standard way not just for print preview but also for page reading (like online magazine)
18:29:04 <nimbu> plinss: if you are doing with divs you are not doing anything with css box model.
18:29:29 <nimbu> alex: you can have multiple regions in every page. if you are going to do page break in content and requires it continue to next page, no way to determine what next page is.
18:30:00 <nimbu> florian: you need something that gets you to next page
18:30:28 <nimbu> florian: if we want to support that we need something like that.
18:31:01 <nimbu> alex: if some content that you place in to region has page-break: avoid, is that smthing regions will not be capable of satisfying, or would we have smthing different.
18:31:08 <fantasai> break-before: region(mycustompaginator)
18:31:10 <nimbupani> nimbupani has joined #css
18:31:28 <nimbupani> smfr: why dont u use normal paged media?
18:31:51 <nimbupani> alex: if nothing more adv is available we would consider every region is a page from point of view of breaking
18:32:02 <nimbu> szilles: all the things u have said requires a content change.
18:32:40 <nimbu> szilles: the author wants to present this content if it were a page in the display he is presenting to the user
18:32:57 <nimbu> vhardy: if you want something foo, then you say break for 'foo'
18:33:15 <karl> karl has joined #CSS
18:33:25 <hyatt> hyatt has joined #css
18:33:38 <nimbu> alex: i dont get why you are objecting. moz has internally a special element to represent …
18:33:48 <nimbu> fantasai: we have a page box we have smthing in the rendering tree that represents a page box
18:33:58 <nimbu> alex: as an author how do you make an element a page box
18:34:00 <nimbu> fantasai: we cant
18:34:30 <nimbu> alex: with regions we are creating an opportunity for author to use page navigating algorithm. 
18:34:45 <nimbu> plinss: do u want headers and footers to appear on random elements?
18:35:19 <nimbu> dbaron: there is an assumption that you should be able to do what you described without changing the content. i dont think thats true
18:35:57 <nimbu> florian: u might want to break sometimes on certain page breaks and not on some others.
18:36:21 <nimbu> vhardy: thats the intended functionality is to have more than 1 kind of breaks.
18:36:48 <bradk> What about regions inside regions inside regions inside regions? You need to be able to indicate level
18:36:48 <nimbu> plinss: you really are talking about a region break to a higher level (in nested regions).
18:37:14 <nimbu> fantasai: e.g. break-before: region('named flow');
18:38:16 <bradk> You might not know the region you are in, but know that you want to break 2 levels up. break-before:region(-2)
18:38:18 <nimbu> vhardy: take an action to add the usecase alex is talking about and measure up the actions
18:38:36 <nimbu> alex: only region break is also generally okay.
18:40:10 <mollydotcom> mollydotcom has left #css
18:40:16 <nimbu> alan: before we got to pagination, it sounded like plinss was saying if we have col breaks and region breaks and i have flow going to regions that are not going to multicol elements you would prefer col break to not break to next region.
18:41:19 <nimbu> vhardy: if you got page break and not in paged media it does nothing
18:41:42 <nimbu> alan: if you have a region situation and u have a column break i prefer my text to go to next region from auth perspective each region is a single column
18:41:57 <nimbu> alan: we have usecases where regions to use multicol layout 
18:42:19 <nimbu> alex: in multicol spec does it say in paged media each page should be considered a column?
18:42:38 <nimbu> ACTION: howcome to answer if paged media each page should be considered a column?
18:42:38 <trackbot> Created ACTION-353 - Answer if paged media each page should be considered a column? [on Håkon Wium Lie - due 2011-08-01].
18:43:03 <mollydotcom> mollydotcom has joined #css
18:43:12 <alexmog> alexmog has joined #css
18:43:30 <nimbu> vhardy: option1 seems to be off the table.
18:43:59 <nimbu> vhardy: we agree we need breaks that are typed. 
18:44:14 <szilles> szilles has joined #css
18:44:24 <nimbu> plinss: if we have nested region flows we need ability to break a level.
18:46:12 <nimbu> plinss: the types of usecases that alex is taking about i think we should have to work on getting browsers to render a page in paginated mode.
18:46:48 <fantasai> There was a suggestion to add 'overflow-style: paged' a while ago.
18:46:51 <hober> Yes, some kind of explicit "I want paginated mode" switch is much cleaner
18:46:57 <bradk> or a section of a page in paginated mode
18:48:13 <nimbu> alex: we are making it possible to create a webpage that gives you the same experience as looking at a magazine. give it same kind of control including control of column breaks and page breaks. we would need to create new break types 
18:48:25 <dsinger> dsinger has joined #css
18:49:00 <Martijnc> Martijnc has joined #css
18:49:07 <nimbu> alex: if we switch browser to switch to page mode, the ui browser provides to navigate pages is light years away from what designers would want in page navigation experience
18:49:51 <nimbu> RESOLVED: we need breaks that are specific to containers they are part of. 
18:50:25 <nimbu> ACTION: vhardy come up with a proposal for breaks either a page-break or a general type of break or both and related use cases
18:50:25 <trackbot> Created ACTION-354 - Come up with a proposal for breaks either a page-break or a general type of break or both and related use cases [on Vincent Hardy - due 2011-08-01].
18:50:44 <nimbu> smfr: we are not happy with behavior for iframe objects in spec
18:50:54 <lhnz> lhnz has joined #css
18:51:06 <nimbu> smfr: issue 5
18:51:08 <hober> http://dev.w3.org/csswg/css3-regions/#the-flow-property
18:51:26 <nimbu> alex: it is not an issue any more. I added it in.
18:51:32 <hober> "For an <iframe>, an <object> or a <embed> element, the ‘flow’ property has a different behavior. The effect is similar to turning the ‘display’ property on the element to ‘none’ while moving the root element of the referenced document to the named flow."
18:52:34 <nimbu> alex: if we remove it, then it would be a non-standard thing like font-size-adjust. if it stays there, it is okay to have it optional. Another option there is to have an explicit way of saying for an element if the element that is added to flow or content added to flow.
18:52:45 <nimbu> alex: i like the second option as it is much more explicit. 
18:53:05 <nimbu> smfr: you start introducing cross origin problems also q of what to do with script style elements and stuff
18:53:36 <nimbu> alex: the cross frame security does apply. We are not going to take content from iframe if its not in the same origin. 
18:53:40 <nimbu> smfr: the spec should stay that.
18:53:52 <nimbu> dbaron: sounds a lot like seamless iframe stuff html5 
18:54:04 <nimbu> dbaron: should we do that instead of redefining it
18:54:21 <nimbu> TabAtkins: seamless iframe becomes like an included 
18:54:44 <nimbu> anne: the iframe height becomes height / width of the document. selectors bleed through.
18:54:50 <nimbu> alex: no default padding
18:55:18 <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
18:55:23 <hober> So in a region <iframe> would behave like replaced but <iframe seamless> would behave like alex has specced
18:55:24 <nimbu> ACTION: alexmog to look at seamless iframes and reconcile it with what we have in the spec. We should add the security consideration into iframe paragraph. 
18:55:24 <trackbot> Created ACTION-355 - Look at seamless iframes and reconcile it with what we have in the spec. We should add the security consideration into iframe paragraph.  [on Alex Mogilevsky - due 2011-08-01].
18:56:19 <bradk> link?
18:56:22 <nimbu> vhardy: we hve had diff proposals for floats and exclusions
18:56:28 <nimbu> vhardy: worked on a bunch of use cases.
18:56:43 <stearns> http://wiki.csswg.org/ideas/css3-floats-use-cases
18:56:50 <nimbu> vhardy: we have a model we would like to propose to the group
18:56:59 <bradk> thanks
18:57:27 <nimbu> vhardy: present this to be ready for editors draft that is a convergence of these two proposals.
18:58:17 <nimbu> ???: 2, 3,4 are essence of how we build the model and 1 is how we use it
18:58:28 <smfr> http://wiki.csswg.org/ideas/css3-floats
18:58:30 <arronei> s/???/rossen
18:58:54 <nimbu> rossen: how to create container model.
18:59:07 <nimbu> rossen: #3 how the shape gets affected by exclusion
18:59:28 <konaya> konaya has joined #css
18:59:50 <nimbu> rossen: in our case, we looked at a diff point of view, already have exclusions in css2 which are floats
19:00:39 <nimbu> rossen: overloading the float property was redundant. we still had to use wrap-mode in ms proposal to trigger an exclusion
19:01:04 <nimbu> rossen: in our case the wrap-type was defaulting to around. so it was enough to say float: position to create an exclusion but in reality it needs both
19:01:20 <karl> RRSAgent, minutes?
19:01:20 <RRSAgent> I'm logging.  Sorry, nothing found for 'minutes'
19:01:34 <karl> RRSAgent, pointer?
19:01:34 <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T19-01-34
19:01:34 <nimbu> rossen: agreement is wrap-mode should be enough to create an exclusion as reg floats are already exclusions, we dont need another.
19:02:04 <nimbu> rossen: it would be interesting to combine what wrap mode really means outside or inside of shape
19:02:25 <nimbu> rossen: if you want table cell circular, you can apply shape on the inside of an element without affecting the outside default shape/box model
19:02:53 <nimbu> rossen: the last version of proposal we had, wrap-mode: default as if wrapping was not involved. 
19:03:22 <nimbu> vhardy: this is a stub, i need more work on that.
19:03:29 <nimbu> alex: so initial is around?
19:03:32 <nimbu> rossen: initial is none
19:03:48 <nimbu> szilles: if its auto floats can behave the way they do today
19:04:04 <nimbu> vhardy: i propose we dont get into this. we need to work out the details. we have not discussed it.
19:04:08 <nimbu> rossen: thats fine by me
19:04:50 <nimbu> dbaron: i am uncomfortable about making resolutions about details when I do not understand the models yet
19:05:14 <nimbu> vhardy: wrap-mode: inside it will wrap inside (shows slides)
19:05:35 <nimbu> vhardy: wrap-mode: all-left would control the wrapping internally for the left side.
19:06:18 <nimbu> vhardy: we resolved having 1 property trigger an exclusion rather than 2 proposed by ms
19:06:29 <nimbu> alex: maybe we dont need resolutions on these fine grained issues. 
19:06:41 <nimbu> vhardy: i think the resolution is to have a single trigger than 2.
19:06:49 <nimbu> vhardy: not on the specific properties
19:07:40 <nimbu> dbaron: it seems like you are proposing the model where anything wraps around anything. i have not seen a lot to explain how thats supposed to work. i saw the spec which says this syntax is supposed to do this thing but it is no where close to doing that thing.
19:07:43 <stearns> stearns has joined #css
19:07:49 <nimbu> vhardy: we will get to that. 
19:09:05 <nimbu> ACTION: vhardy make the default value for wrap-mode be auto. 
19:09:05 <trackbot> Created ACTION-356 - Make the default value for wrap-mode be auto.  [on Vincent Hardy - due 2011-08-01].
19:09:23 <nimbu> rossen: next point is containing model for exclusions
19:09:52 <nimbu> rossen: we didnt make any change to css to containing model. based on position property containing block is computed just like css2 block.
19:10:04 <nimbu> rossen: there is one exception, that is the new position: page-value that we are adding
19:10:21 <nimbu> arronei: we can talk about that later when we get to css position
19:10:26 <arno1> arno1 has joined #css
19:10:51 <nimbu> alex: what it is saying is that the scope of what an exclusion affects its containing block.
19:11:28 <nimbu> alex: the important difference this makes compared to other containing model is that it could be defined an element affects anything that it visually overlaps.
19:11:49 <nimbu> alex: it could be defined an element with exclusion affects an element further down in the content flow and nothing before it.
19:12:07 <nimbu> alex: that would be very limiting in positioning exclusions backwards and forward which is a very common use case
19:12:30 <szilles> szilles has joined #css
19:12:45 <nimbu> dbaron: so you are proposing that things that create exclusions are still positioned according to normal css rules
19:13:14 <nimbu> dbaron: 2 divs both contain text, the second div has margin-top: −5em wrap shape smthing to make a circle that is 5em radius and they both have text.
19:13:23 <nimbu> dbaron: where do you position the second text?
19:13:46 <nimbu> alex: we are getting there to describe the processing model which is where we resolve contradictory layout situation.
19:14:03 <nimbu> alex: can we go over issue 5 then issue 1 as issue 1 is most difficult issue
19:14:26 <nimbu> rossen: so, issue 5 was ordering of exclusions. both the container models is same as css2.
19:14:41 <nimbu> rossen: everything in the scope of the container will be affected by exclusion
19:14:42 <nmccully> nmccully has joined #css
19:16:23 <nimbu> rossen: overlapping exclusions: 1. first draft mentioned taking doc order which was not intuitive 2. we are staying with z-index ordering. that appeared as double dependency from exclusions from within the content that would influence the outer exclusions or content outside. but we are scoping the effect of exclusions to containing block then ordering per z-index becomes much more easier.
19:16:46 <nimbu> szilles: show the example.
19:17:05 <nimbu> rossen: it is visual vs. content order by default. 
19:17:46 <nimbu> alex: based on z-index, if its not set, elements that over lap prev elements then later elements create exclusions over prev elements. we should try to avoid relayout. 
19:18:13 <nimbu> dbaron: so when you say exclusions affect only other things in containing block I presume you mean everything descendant from containing block. It includes siblings and so on
19:18:27 <nimbu> dbaron: this idea of using z-index you are potentially crossing stacking context
19:19:30 <nimbu> dbaron: with subtree model, you can be in situations where excl a should affect b but not vice versa as a is a descendant of b's containing block but b is not a descendant of a's containing block. 
19:20:20 <nimbu> rossen: if u are on some level of the tree, and u have containing block which have exclusions on each side. and a set of eclusions coming from its container.
19:21:02 <nimbu> rossen: u can order the exclusions in the containing block. you can only take exclusions that are higher than your z-index. once you take those exclusions in your container then you need to resolve with exclusions inside.
19:21:29 <nimbu> rossen: even if you resolve the exclusions inside, it does not affect exclusions that are coming above the containing block.
19:23:02 <mollydotcom> mollydotcom has joined #css
19:23:08 <dbaron> just trying to figure out if this z-order model makes sense given that
19:23:39 <nimbu> phil: you have a positioned element, and it has some -ve z-index so its going to be behind rest of the content.
19:26:43 <smfr> ChrisL: mollydotcom is taking some
19:26:57 <ChrisL> ty
19:27:01 <nimbu> rossen: it may or may not wrap around D depending on z-index
19:27:07 <nimbu> rossen: we know D can never wrap around C
19:27:12 <nimbu> vhardy: is D a containing block?
19:27:16 <nimbu> alex: all are abs pos
19:27:39 <nimbu> rossen: the answer here is we apply priority based on z-order at container levels
19:27:53 <nimbu> rossen: if smthing affects B based on z then everything in B would be affected by that. 
19:28:11 <nimbu> rossen: there should be no way D would wrap around C, so ther eis no way C would wrap around D.
19:28:25 <nimbu> phil: what if there is opacity on D?
19:28:50 <nimbu> alex: D does not have to use wrap-mode it does not have to create an exclusion.
19:29:12 <nimbu> rossen: exclsion is only when you want to "exclude"
19:29:41 <nimbu> alex: discussion on using -index or other kind of index is a separate discussion.
19:30:08 <nimbu> alex: issue is to determine order on exclusions and we have come up with z-index.
19:30:25 <nimbu> rossen: the prev containing model was different that was exposing a number of complexities
19:30:39 <nimbu> alex: we should consider all hte complicated z-index combination and see if it works
19:30:39 <Zakim> Zakim has left #css
19:30:52 <nimbu> szilles: what you saying is that the drawing order is the model of exclusions
19:31:01 <nimbu> szilles: z-index affects the drawing order.
19:31:55 <nimbu> glazou: we will continue after lunch
19:33:11 <mollydotcom> ChrisL: here's a drawing http://twitpic.com/5vs3ra
19:33:22 <ChrisL> molly, thanks!
20:12:10 <sylvaing> sylvaing has joined #css
20:28:53 <arronei> arronei has joined #css
20:30:36 <cjon> cjon has joined #css
20:32:21 <TabAtkins_> TabAtkins_ has joined #css
20:34:05 <sylvaing> yeah, sorry. seems you dropped
20:34:39 <arno> arno has joined #css
20:37:56 <smfr> smfr has joined #css
20:38:33 <szilles> szilles has joined #css
20:38:36 <mollydotcom> mollydotcom has joined #css
20:40:05 <dbaron> dbaron has joined #css
20:40:21 <glazou> glazou has joined #css
20:41:10 <kojiishi> kojiishi has joined #css
20:41:16 <TabAtkins_> ScribeNick: TabAtkins_ 
20:42:16 <alexmog> alexmog has joined #css
20:42:18 <sylvaing> rossen
20:42:47 <TabAtkins_> rossen: [something about z-order] Did that make sense to everybody?
20:42:47 <nimbupani> nimbupani has joined #css
20:42:52 <nmccully> nmccully has joined #css
20:43:05 <anne> anne has joined #css
20:43:19 <TabAtkins_> vhardy: We'll just take all the feedback and integrate it into the next draft.
20:43:41 <TabAtkins_> rossen: Back to issue 1, processing model.
20:43:42 <florian> florian has joined #css
20:43:47 <TabAtkins_> rossen: Currently we take the easy way out.
20:44:21 <TabAtkins_> rossen: We treat exclusions as out-of-flow, so you lay out once to pick up any "auto" positions that exlusions may anchor to, then you position exclusions, then you fill in the rest.
20:44:26 <tantek> tantek has joined #css
20:44:42 <TabAtkins_> rossen: The obvious problem with this is the accumulation of error; exclusions will push around their own or other's auto positions.
20:45:08 <TabAtkins_> rossen: There are discussions about a better processing model that would keep the auto positions closer to the right place in the flow, but so far there's been nothing solid enough for us to write down.
20:45:08 <florian> florian has left #css
20:45:11 <florian> florian has joined #css
20:45:30 <TabAtkins_> rossen: That is the processing model we have for oof with position:absolute|fixed|page.
20:46:14 <TabAtkins_> alexmog: The model rossen is describing, I'm proposing to have it as non-normative atm; it describes something specific enough that simple cases can be interop, but it leaves room for a more advanced processing model later.
20:46:17 <jdaggett> jdaggett has joined #css
20:46:23 <TabAtkins_> alexmog: We'll tighten it up as we get impl experience.
20:46:39 <TabAtkins_> arronei_: If you make it non-normative, you can't test it or depend on it.
20:47:04 <TabAtkins_> alexmog: We can make it normative to the extent of the simple bits, but I don't think we can fully fill it in yet.
20:48:32 <TabAtkins_> rossen: position:static has only one difference - you actually lay out with the flow.
20:49:27 <TabAtkins_> rossen: For position:static exclusions, they're laid out with the normal flow pass.
20:49:39 <TabAtkins_> rossen: If all you hae is static exclusions, you don't need a second pass, as they're laid out as part of the content.
20:49:49 <TabAtkins_> alexmog: What happens if they have a negative margin?
20:49:58 <TabAtkins_> rossen: Same as today - they'll overlap the previous content.
20:50:14 <TabAtkins_> alexmog: Doesn't that contradict what exclusions should be doing?
20:50:42 <bradk> It would be like a float, more or less, if static? Only affecting the leading edges?
20:50:45 <TabAtkins_> rossen: They only push around other stuff in the abspos case.
20:51:22 <TabAtkins_> rossen: [draws a diagram]
20:51:40 <bradk> Can someone post a photo once there is something to look at on the whiteboard?
20:52:37 <TabAtkins_> rossen: While laying out text, you lay out line by line.  When you encounter a static exclusion, you're in the middle of layout out one line (previous lines are already done).
20:53:11 <TabAtkins_> rossen: If this was a regular div, the block would consume all the space to its sides, pushing following text below it.  Exclusion just lets following text fill in space around it.
20:54:15 <arno1> arno1 has joined #css
20:54:16 <TabAtkins_> rossen: Moving on to further issues.
20:54:30 <TabAtkins_> rossen: issue 7, what does "shrink-to-fit" mean for floats with shapes?
20:54:33 <szilles> szilles has joined #css
20:55:33 <TabAtkins_> rossen: We defined an easy way out here - use the bounding box of the exclusion shape as the "shrink-to-fit" for the floater.
20:56:00 <TabAtkins_> alexmog: Nobody really liked the idea that they have to calculate the closest intersection of arbitrary shapes - too hard of a problem.
20:56:13 <TabAtkins_> alexmog: So it should be acceptable to treat exclusions as rectangles for the purpose of shrink-to-fit.
20:57:27 <TabAtkins_> alexmog: [something explaining the above point that I missed]
20:57:46 <TabAtkins_> rossen: I think the shape doesn't correspond to the border box - it could maybe define its own bounding rect.
20:58:24 <TabAtkins_> alexmog: It shouldn't get bigger than what's calculated with bounding boxes.
20:58:29 <TabAtkins_> alexmog: You can always make it smaller.
20:58:42 <TabAtkins_> szilles: I'm slightly confused.  If I have a wrap-shape, it has a size.  Why do I need shrinkwrap at all?
20:59:10 <vhardy> vhardy has joined #css
20:59:14 <TabAtkins_> rossen: We're talking about floats that are themselves shaped.
20:59:27 <TabAtkins_> dbaron: The shapes can have percenetages, so the shape is based on the size itself.
20:59:48 <TabAtkins_> dbaron: If the shape is a circle centered on the box with a radius of 50%, the shape is a function of the size.
21:00:06 <TabAtkins_> rossen: If that was a div with width:50% inside of the float, the same effect would occur.
21:01:16 <TabAtkins_> rossen: One more difference from the original exclusions spec was a property named "flow-wrap" that allowed elements to not pay attention to exclusions. 
21:01:22 <TabAtkins_> rossen: We should maybe rename it.
21:01:46 <miketaylr> miketaylr has joined #css
21:01:54 <TabAtkins_> rossen: A lot of people thought it was related to a "wrap-mode" property.
21:03:00 <TabAtkins_> rossen: We also have Daniel's proposal that proposed a fairly different way to introduce exclusions.
21:03:10 <TabAtkins_> vhardy: I think your presentation is a convergence of the two proposals.
21:03:16 <TabAtkins_> rossen: Yeah, it got assimilated.
21:03:30 <TabAtkins_> vhardy: So I think the next thing is to work on a new ED.
21:03:36 <TabAtkins_> arno: And that's a wrap.
21:03:41 <stearns> perhaps the name for "ignore wrap" should follow whatever we end up with for "cancel-underline"
21:03:44 <TabAtkins_>  /groan
21:04:18 <TabAtkins_> alexmog: I think we came to the conclusion that the name of the module should be "CSS3 Floats".
21:04:32 <TabAtkins_> alexmog: It eventually needs to be a bigger doc that describes much mor eof th eprocessing model,
21:04:47 <TabAtkins_> ... describing floats that don't overlap too.
21:07:17 <TabAtkins_> alexmog: [something about how extending 'float' might work]
21:07:26 <TabAtkins_> arno1: Would that be in CSS3 Floats or something else?
21:07:42 <TabAtkins_> vhardy: I think we should produce a first draft that covers what we know we want and have.
21:07:54 <TabAtkins_> vhardy: Then later figure out how we want to slice it with gcpm and other float-related things.
21:08:27 <TabAtkins_> arno1: My concern is that if this is float-related, we'd have to close on everything float-related to make this work.
21:08:38 <TabAtkins_> alexmog: I had the same concern.  I think we can do Exclusions separately from Floats.
21:09:08 <TabAtkins_> alexmog: there is an issue with making Exclusions a Rec without having anything with floats.
21:09:28 <TabAtkins_> alexmog: But I think vincent has the right idea that we should write the draft now, and when we see it, it should be easy to tell what the right name is.
21:09:57 <TabAtkins_> dbaron: My general feeling about this draft is that it's very complicated to implement, and it's possible to write something much simpler to implement with most of the functionality.
21:10:08 <TabAtkins_> dbaron: I may want to look into going that way, but I haven't had a chance to do that yet.
21:10:29 <TabAtkins_> vhardy: If we produced a new draft that you could comment on, would that be ok?
21:10:42 <TabAtkins_> dbaron: I think at this point the best way forward for me is to produce a new proposal.
21:11:21 <TabAtkins_> florian: If we have proposals that look close enough, it's worth merging them.  But we're early enough on right now that if there's something significantly different, it's worth exploring that separately.
21:12:08 <TabAtkins_> alexmog: I would be really glad if we could remove things from the draft and still meet the goals.
21:12:27 <TabAtkins_> florian: David, is what you have in mind the current draft with some things removed, or something totally different?
21:12:59 <TabAtkins_> dbaron: Similar things, but with a significantly different processing model.
21:13:51 <TabAtkins_> dbaron: I'm thinking that I want to separate the reordering aspects, and then not have the reordering implications within layout.
21:14:03 <TabAtkins_> dbaron: So if you need reordering, that's a separate process, and then layout is still one pass.
21:14:46 <TabAtkins_> dbaron: The part of this draft that scares me is the part that's not yet written.
21:15:12 <TabAtkins_> dbaron: It's hard to know I have comments on it before I read it.  There may be a big gap somewhere that implies a big complicated chunk of processing model.
21:15:18 <TabAtkins_> dbaron: I've only thought about it for the last few days.
21:15:47 <TabAtkins_> vhardy: The processing model we've described is a bit different than what's currently in the ED.
21:15:54 <TabAtkins_> dbaron: I couldn't find much of a processing model.
21:16:12 <smfr> http://wiki.csswg.org/ideas/css3-floats-use-cases
21:16:18 <TabAtkins_> florian: Do you think that what you want fits within the shape of the existing proposal?
21:16:25 <arronei> http://wiki.csswg.org/ideas/css3-floats
21:16:34 <TabAtkins_> dbaron: There are some examples that I know don't fit, but they're incomplete examples right now.
21:16:43 <TabAtkins_> rossen: Have you checked out the wiki examples yet?
21:16:46 <TabAtkins_> dbaron: Not yet.
21:17:18 <TabAtkins_> rossen: If you could look, it would be great to have a review and see what's missing or whats overcomplicated.
21:17:32 <TabAtkins_> rossen: If you have an alternate proposal, I'd like to see if it solves these use-cases.
21:17:54 <TabAtkins_> vhardy: We should take an action item to review this page.
21:18:34 <glazou> jdaggett: can you call in?
21:18:50 <szilles> szilles has joined #css
21:19:13 <TabAtkins_> Topic: Writing Modes
21:19:17 <glazou> jdaggett: can you hear us?
21:19:55 <TabAtkins_> fantasai: I think there are several issues open right now.
21:19:59 <TabAtkins_> fantasai: One is the name of the property.
21:20:07 <TabAtkins_> fantasai: Second is the defualt orientation at a codepoint level.
21:20:17 <TabAtkins_> fantasai: The third is whether we're doing context-based resolution of punctuation, and if so, how?
21:20:34 <TabAtkins_> fantasai: The fourth is if we're giving additional controls at level 3 (beyond what you can currently do with text-orientation).
21:20:45 <TabAtkins_> jdaggett: Let's start iwth sylvain's issue.
21:21:00 <TabAtkins_> jdaggett: I think #3 and #4 are dependent on a concrete proposal for #2.
21:21:21 <TabAtkins_> szilles: Two more issues are Nat's comments on TCY
21:22:40 <TabAtkins_> szilles: I think you suggested separating the text-combine prop into one that did manual TCY and one that set up automatic TCY.
21:22:47 <TabAtkins_> szilles: They may want to be over different ranges.
21:22:57 <glazou> jdaggett: (we're in a big room, 30 people in the room, some of us are pretty far from the microphone… tell us if you don't hear us)
21:23:03 <TabAtkins_> jdaggett: Why do you need that distinction, Nat?
21:23:13 <dbaron> (TCY == Tate-chu-yoku)
21:23:22 <TabAtkins_> nat: Right now we have text-combine:horizontal, then a bunch of values for controlling the auto case, i guess.
21:23:41 <TabAtkins_> nat: Is that what we want?  Just specify it on, and then specify the details (do letters, do digits, combine X many)
21:23:55 <TabAtkins_> nat: And then, if the lettes in the span meet that criteria, combine them?
21:24:18 <TabAtkins_> florian: One case was that, or a date, you don't wnat to have to add extra spans around the day and month and year, but rather just one aroudn th eyear.
21:24:31 <TabAtkins_> nat: The other issue I had was the defualt implied value.
21:24:59 <TabAtkins_> fantasai: The values are "none", "all" (tcy the whole span), and then various options that control what things are combined.
21:25:32 <jdaggett> nat's post: http://lists.w3.org/Archives/Public/www-style/2011Jul/0405.html
21:25:47 <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#text-combine
21:26:00 <TabAtkins_> nat: I thought if I tried to implement this, it would be easier if I didin' thave to worry about having a state machine go through the text.
21:26:26 <TabAtkins_> fantasai: You can't combine, say "all" and "latin 4" - it's not syntactically valid.
21:26:30 <fantasai> ACTION fantasai: Add syntax examples
21:26:30 <trackbot> Created ACTION-357 - Add syntax examples [on Elika Etemad - due 2011-08-01].
21:26:37 <TabAtkins_> nat: i think some examples would help here.
21:26:58 <TabAtkins_> nat: So when it's not all, you can do auto TCY in any span.
21:27:25 <TabAtkins_> nat: A second point, why do you have, in the alphanumeric tolerance section, a "1.1em" figure.  That seems arbitrary.
21:27:50 <TabAtkins_> fantasai: koji was talking with hyatt about that issue.  hiragina apparently, if you ask for half-width glyphs, won't fit within 1em if you put them side-by-side.
21:28:04 <TabAtkins_> szilles: if that's true, why not just do it when they ask for it?
21:28:29 <TabAtkins_> fantasai: This is for whether you scale or not.  This number is close enough that you usually won't have to scale.
21:28:34 <stearns> s/hiragina/hiragana
21:29:10 <TabAtkins_> kojiishi: The idea of scale is to compress glyphs so that they fit into 1em.
21:29:28 <TabAtkins_> kojiishi: But there are some fonts that get slightly gretaer than 1em when you set two half-width next to each other.
21:30:09 <TabAtkins_> kojiishi: So if two chars are much larger than 1em, authors would likely want to compress them.  But if they're just a tiny bit over (maybe accidentally, like described here), you'd want to just leave them alone.
21:30:25 <TabAtkins_> nat: Okay.  I think having the built-in tolerance is orthogonal to the scaling issue.
21:30:26 <dbaron> (not Hiragino?  I think they were talking about the font)
21:31:14 <TabAtkins_> nat: If you're tolerant of the idea that you're using glyphs that odn't fit into 1em, you're probably okay with not scaling, so you should just say no scaling.
21:31:44 <TabAtkins_> kojiishi: Even if you do scale, though, you probably still don't want to scale if you're just very slightly over 1em.
21:31:52 <ChrisL> ChrisL has joined #css
21:31:56 <karl> karl has joined #CSS
21:32:32 <TabAtkins_> nat: But you're saying to scale it to 1.1em, not 1em.
21:32:43 <TabAtkins_> nat: You can have an "auto-scale" that has some tolerance in there.
21:32:57 <TabAtkins_> florian: Can we just have a scale with no tolerance, and let you add the tolerance in specifically?
21:33:33 <arronei_> arronei_ has joined #css
21:34:01 <ChrisL> rrsagent, here
21:34:01 <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T21-34-01
21:34:06 <TabAtkins_> szilles: If they're images, you really notice the artifacts.  If they're outlines you won't notice as much.
21:34:28 <TabAtkins_> szilles: Can we say something other than "scale"?
21:34:38 <TabAtkins_> fantasai: squish/compress/scale-x?
21:34:40 <bradk> condense, horizontal scaling
21:34:43 <TabAtkins_> fantasai: compress
21:35:30 <TabAtkins_> jdaggett: If someone wants this tolerance, they should be involved in the discussion.
21:35:49 <TabAtkins_> florian: I don't think it's useless, but it seems to be going a bit too far right now.  Push it to level 4.
21:35:53 <dbaron> (above) Nat: condensed is bad because it implies a different font selection
21:36:26 <TabAtkins_> fantasai: The tolerance is used in the scaling (removed now), and also in the "used glyphs" section.
21:36:42 <TabAtkins_> fantasai: Which says to use half/third-width glyphs if available; if not available, scale.
21:37:04 <bradk> Adobe calls it "horizontal scaling" in their programs, IIRC, FWIW
21:37:12 <TabAtkins_> fantasai: What might happen is that you say you want to use third-width glyphs, but it ends up being rendered with a font without third-width glyphs.
21:37:30 <TabAtkins_> fantasai: The default action, then, should be to go ahead and scale, as that's minimally invasive to the rest of the page design.
21:37:51 <TabAtkins_> nat: Is that how it's supposed to work?  I didn't get the idea that things had fallback.
21:37:58 <TabAtkins_> fantasai: You can combine "scale" and "use-glyphs".
21:38:27 <TabAtkins_> szilles: Why wouldn't you scale to 1em?
21:38:42 <TabAtkins_> florian: You'd scale to 1em, but you wouldn't scal ei fyou're "close enough" to 1em.
21:39:47 <szilles> szilles has joined #css
21:39:49 <TabAtkins_> szilles: [an example with "1.3" and TCY]
21:39:50 <bradk> Is it tragic to allow the glyphs tooverflow if they are slightly too wide?
21:40:06 <TabAtkins_> jdaggett: In the original document this was based, there's an example for that.
21:40:35 <TabAtkins_> szilles: I know that stuff like TCY'd "1.357" is actually done.
21:40:49 <jdaggett> original document == jis 4051 spec
21:40:53 <TabAtkins_> nat: I think we should just have a "use glyphs" option, and if glyphs don't exist, just do fallback.
21:41:40 <TabAtkins_> fantasai: We can say that if you find the right glyphs, just don't worry about compressing.  Assume that the glyphs are the right width.
21:42:49 <TabAtkins_> kojiishi: If the first font has the glyphs (slightly off the right width) but the second font doesn't, the first font would grab the glyphs and be slightly off-width, while the second would synthesize and be exactly right.
21:42:58 <TabAtkins_> nat: I think you're far off in edge-cases here.
21:43:24 <TabAtkins_> szilles: I think it's pretty simple.  If it has half-width glyphs, it has half-width glyphs.  Just use them.
21:43:58 <TabAtkins_> nat: Why are we doing anything if the half-width glyphs dont' exist?
21:44:19 <TabAtkins_> szilles: CSS generally tries to best capture the authors' intent.
21:45:20 <TabAtkins_> kojiishi: If the author says "digits 3", and the half-widths are slightly more than half an em, you'll get slightly more than 1em-width TCY.
21:45:43 <TabAtkins_> fantasai: Is it possible to know if the font has third-width glyphs?
21:45:50 <TabAtkins_> nat: There's a feature in OT that the UA can query.
21:46:21 <TabAtkins_> jdaggett: The problem with these features is that for different features, different sets of glyphs are available.
21:46:32 <TabAtkins_> jdaggett: For third/fourth-width, often only digits are available.
21:46:46 <TabAtkins_> szilles: What about numeric punctuation (periods and commas)?
21:46:59 <TabAtkins_> nat: Generally not.  Most only have half-width punctuation.
21:47:19 <TabAtkins_> szilles: So you could do years and integers, but not decimal numbers.
21:47:21 <TabAtkins_> nat: Right.
21:47:38 <TabAtkins_> szilles: I think we just need a clear processing model of whe nthings are decided.
21:48:05 <TabAtkins_> szilles: I don't think we want to say "let's make as tring, and then try to compress it".  I think you want to first check for half-width glyphs or whatever, and then build out of what exists.
21:48:58 <TabAtkins_> szilles: So I want a clear statement of what you're looking for from the font, and underwhat conditions.
21:49:13 <TabAtkins_> fantasai: So what I'm hearing is that we should use the correct glyphs if the font has them, otherwise synthesize.
21:49:47 <TabAtkins_> fantasai: So if I'm doing "122", if the font has third-width glyphs, I use them.  If it doesn't, I scale the "1" and "2" glyphs and then combine them, rather than making "122" and then scaling.
21:50:25 <TabAtkins_> florian: Also, the current spec specifies just that they should fit into 1em, whihc allows cherry-picking half and quarter-width glyphs and combining them, which is not what you want.
21:50:29 <bradk> Doesn't kerning and tracking affect if two 1/2-width glyphs fit into one em?
21:52:42 <TabAtkins_> fantasai: We can tell if the font has a "third-width" feature, but we don't know if individual characters have third-width glyphs.  So if I wanted "IBM" in third-width glyphs, I'd request those glyphs from the font as third-width glyphs, but I may or may not actually get third-width glyphs back.
21:53:12 <TabAtkins_> fantasai: So once I get them back, if they're wider than 1/3em, I need to scaled them to 1/3 em.
21:53:59 <TabAtkins_> fantasai: I think we can make an exception that, for half-width glyphs, don't measure and just use what you get.  You may get proportional, which may be close enough.
21:54:05 <TabAtkins_> bradk: Can kerning affect this?
21:54:14 <TabAtkins_> nat: You don't kern monospace CJK fonts.
21:54:31 <TabAtkins_> jdaggett: In theory, it's an issue; in practice, you don't ever kern these types of fonts.  I don't think we need to worry about it.
21:54:58 <jdaggett> ... you don't generally kern these *glyphs*
21:55:16 <jdaggett> i.e. third-width glyphs
21:55:35 <TabAtkins_> kojiishi: I think it may still be useful to have an option to not scale glyphs, as it may be ugly sometimes.
21:56:19 <TabAtkins_> florian: Perhaps if you say "use-glyph no-scale", you just use exactly what's given back by the font, no measurement.  It may be too big, but shrug.  Then "use-glyph" will scale if they're too big, and "compress" will just always scale the full-size.
21:56:24 <TabAtkins_> fantasai: Makes sense.
21:57:19 <fantasai> ACTION fantasai: edit as above
21:57:19 <trackbot> Created ACTION-358 - Edit as above [on Elika Etemad - due 2011-08-01].
21:57:52 <TabAtkins_> RESOLVED: Remove the concept of glyph-size tolerance from this level of the spec.
21:58:11 <jdaggett> whatever you spec out, you need to try it on some simple examples and include them in the description
21:58:19 <TabAtkins_> fantasai: So for fonts with propotional, but not half-width glyphs, if you say "use-glyphs", should we just use the glyphs directly?
21:58:28 <jdaggett> the markup should be easy and the implementation should be fairly easy
21:58:47 <jdaggett> nat: yeah, you don't want multiple passes to support TCY
21:59:16 <TabAtkins_> szilles: I think, since the user can say "no-scale" if they really don't want it, you should have a single default that works decently enough for everyone.
21:59:52 <szilles> szilles has joined #css
22:00:46 <TabAtkins_> kojiishi: The tolerance came in to address the common case where the TCY want to use two digits without scaling.
22:03:45 <TabAtkins_> nat: If we have different scaling values (depending on number of digits), it's too complicated for the value you get.
22:03:59 <TabAtkins_> nat: I agree that it may be useful in some cases, as Koji says, but I don't think its' worthwhile to address.
22:04:24 <TabAtkins_> nat: Koji brings up the possibility that some people may want to scale only when it looks terrible, and let it not scale if it's "almost there".
22:04:39 <TabAtkins_> nat: But I don't think it's worth dealing with that explicitly.  That should be something a UA could decide.
22:05:00 <TabAtkins_> florian: Or we could go with steve's idea of adding a tolerance to scale.
22:05:11 <TabAtkins_> szilles: I mainly just think we're spending too much time on this.
22:05:33 <TabAtkins_> fantasai: And the default is the UA tries to do whatever it can to make things fit.  No limitations.
22:06:56 <TabAtkins_> nat: Moving on, it looks like you can omit the integer in "digits" etc. and it defaults to 2.  I think it would be better to be explicit.
22:06:59 <TabAtkins_> fantasai: Okay.
22:08:17 <szilles> szilles has joined #css
22:08:19 <TabAtkins_> kojiishi: You're not requiring an integer for "all", right?
22:08:30 <bradk> cute
22:08:48 <hober> bradk: i think you mean 'kawaii'
22:08:49 <TabAtkins_> fantasai: Right.
22:09:21 <TabAtkins_> nat: We should just make "all" be very simple.  It does *all*.
22:09:40 <szilles>   Add Usecases for 2 or 3 digits in auto t-c-y and have an example with mix of digits and non-digits; e.g., "1.2"
22:09:46 <florian> s/steve's idea of adding a tolerance to scale/steve's idea of adding a parameter to no-compress, rather than using tolerances/
22:11:39 <TabAtkins_> fantasai: If you say "use-glyphs" and there's only a single char, the current spec says to use a full-width glyph if one is availab.e
22:11:45 <TabAtkins_> nat: And I think you shouldn't do that.
22:12:12 <TabAtkins_> nat: glyphs substituation may cause problems (undefined?)
22:12:40 <TabAtkins_> nat: Are you supposed to scale up the glyphs to 1em, or what?
22:13:06 <TabAtkins_> florian: i think we've said that TCY and text-transform interacts.
22:13:48 <TabAtkins_> fantasai: Spec says that any text-transform features are turned off for combined text of more than 1 char.
22:14:20 <TabAtkins_> florian: Then that's fine.  You can use text-transform to get single large chars, but have smaller chars for more TCY.
22:14:38 <TabAtkins_> fantasai: jdaggett you were saying that for text-transform we should write up proposals first and then discuss?
22:15:04 <TabAtkins_> jdaggett: Yeah, I did some experiments.  Spec says currently that you have to use the VR2 feature of the font, but in practice that doesn't really work.
22:15:05 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0401.html
22:15:07 <nmccully> nmccully has joined #css
22:15:09 <TabAtkins_> s/text-transform/text-orientation/
22:15:45 <TabAtkins_> jdaggett: In the post I summed up the key points:
22:16:03 <TabAtkins_> jdaggett: Latin will rotate, greek and cyrillic won't, and there are many other cases where it's not clear that what exists is what you want.
22:16:08 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0402.html
22:16:35 <TabAtkins_> jdaggett: In discussion with Erik Mueller, we thought it mad emore sense to specify a property (possibly going into unicode) that says whether a character is upright or rotated.
22:16:46 <TabAtkins_> jdaggett: Then we can use that property to define the gray areas here.
22:16:53 <stearns_> stearns_ has joined #css
22:16:54 <TabAtkins_> jdaggett: symbols, punctuation, currency, etc.
22:16:58 <TabAtkins_> fantasai: That sounds reasonable.
22:17:36 <TabAtkins_> jdaggett: I just don't think this can be a derived property from the existing values.
22:17:53 <TabAtkins_> fantasai: Agreed - until it's a unicode property, we'll have to have it be derived with a large list of exceptions.
22:18:33 <TabAtkins_> jdaggett: And then the logic of text-orientation will be to use that property, then apply the "vert" opentype feature to the upright runs.
22:18:59 <TabAtkins_> nat: And you do that so fonts which disagree with the feature can achieve that?
22:19:01 <TabAtkins_> jdaggett: Yes.
22:19:21 <TabAtkins_> nat: I'm comfortable with that.
22:19:35 <TabAtkins_> jdaggett: This property effectively already exists, but it's just custom right now in different tables.
22:19:59 <TabAtkins_> jdaggett: IE already has it (though clearly out of date; it doesn't do non-BMP). Webkit has a similar table, similarly wrong.
22:20:07 <ChrisL> has Unicode consortium been asked to add this property?
22:20:21 <TabAtkins_> jdaggett: It would be great to pull together our individual dbs and help make a proposal to unicode.
22:20:45 <TabAtkins_> nat: InDesign has something similar too.
22:21:22 <ChrisL> (I take what jdagett said to mean "not yet but we will")
22:22:00 <TabAtkins_> jdaggett: I don't think we need to get into the individual heuristics yet.
22:22:21 <TabAtkins_> nat: When unicode didn't provide two codepoints for something that was two codepoints in shift_jis, we have to be able to differentiate.
22:22:35 <TabAtkins_> nat: Some fonts have different designs for the two.  In some fonts you want to rotate, and in others you don't.
22:23:12 <TabAtkins_> fantasai: We can get info for Japanese fairly easily, but I'm concerned about other languages like Chinese where we don't have much if any information.
22:23:26 <TabAtkins_> nat: It's different, and unfortuantely the standards are even more loose.
22:24:15 <TabAtkins_> nat: We don't use font metrics, but it's very complicated to deal with this.
22:24:44 <TabAtkins_> jdaggett: to handle that sort of thing, we could call out those specific codepoints and deal with those in a separate category.
22:24:59 <TabAtkins_> jdaggett: So CSS3 can deal with japanese well, but the separation lets us make better rules for Chinese and such later.
22:25:25 <TabAtkins_> szilles: You and I, jdaggett, have proposed being able to provide a delta on the unicode table.
22:25:49 <TabAtkins_> jdaggett: I think it would be better to wait and propose the rpoeprty first, then went through and discussed how you might want to modify it.
22:26:19 <TabAtkins_> szilles: Right; I brought it up as a reminder of the concept.
22:26:54 <TabAtkins_> jdaggett: Right.  it would be nice to eventually let authors say exactly what defaults they want ("never rotate english text"), so they didn't need to put a bunch of markup around specific areas.
22:27:07 <TabAtkins_> szilles: It would also allow all the default tables out there to be incorporated.
22:28:17 <TabAtkins_> fantasai: I have a concern that the rest of the draft (the layout parts) really ought to be stabilized somehow.
22:28:42 <TabAtkins_> fantasai: We have a lot of work left to do on text-orientation, but I think the layout bits should be locked down and not held back by this work.
22:29:34 <TabAtkins_> fantasai: Another month or two i can handle, but if this'll take us until next year, I'm concerned.
22:29:38 <TabAtkins_> jdaggett: I don't think it'll take that long.
22:29:49 <TabAtkins_> fantasai: One more item now.
22:29:59 <TabAtkins_> fantasai: Sylvain was talking about the name of 'writing-mode' property.
22:30:08 <szilles> szilles has joined #css
22:30:20 <TabAtkins_> sylvaing: The writing-mode property says it defines block-progression (then why isn't in named "block-progression").
22:30:38 <TabAtkins_> sylvaing: then it says that the writing mode is deifned by three properties, one of which is called "writing-mode", which is confusing.
22:30:56 <TabAtkins_> fantasai: I think we shouldn't change the name, but if you have a better term...
22:31:06 <TabAtkins_> sylvaing: There used to be a block-progression property.
22:31:27 <TabAtkins_> fantasai: Yes, because at the time writing-mode was a shorthand that overrides "direction", which was a very bad thing.  We've had this discussion a few times.
22:31:34 <TabAtkins_> fantasai: And it's incompatible with SVG and IE6.
22:31:37 <TabAtkins_> sylvaing: What is?
22:32:06 <TabAtkins_> fantasai: We could call it block-progression, but then writing-mode would be an alias.
22:32:59 <TabAtkins_> dbaron: Is this a naming discussion, or a substantive one?
22:33:31 <TabAtkins_> fantasai: Kinda both.  Given legacy and other reasons, I think the name should stay, but I'm willing to change the terminology.
22:34:08 <TabAtkins_> szilles: I agree that this would be better called "block-progression".  But history/SVG means that it should stay consistent and be "writing-mode".
22:34:35 <ChrisL> svg also uses the term 'block progression direction' (from xsl) btw
22:34:44 <TabAtkins_> fantasai: I'd just like to avoid property aliases.
22:34:47 <ChrisL> but it does use the writing-mode property, yes
22:34:54 <TabAtkins_> dbaron: value aliases are much eaiser than property aliases.
22:39:04 <bradk> meeting is over for today?
22:39:15 <stearns_> no - just on break
22:39:21 <ChrisL> i believe another 2.5 hours
22:39:44 <bradk> OK, thanks
22:40:15 <bradk> It sounded like everyone was heading out to go boating, but I guess that is later
22:46:57 <JohnJansen> correct, Brad. That's at 7 tonight.
22:56:23 <fantasai> ScribeNick: fantasai
22:56:31 <fantasai> Topic: Gradients
22:56:38 <fantasai> Tab: 3 issues to resolve
22:57:04 <fantasai> Tab: First one is repeating gradients when the distance between the first and last stop approaches zero
22:57:12 <vhardy> vhardy has joined #css
22:57:29 <fantasai> TabAtkins: zw gradients are not a problem without repeating, but is a problem for repeating because you can't repeat them on the same point infinitely
22:57:45 <fantasai> TabAtkins: Right now I punt on the issue by making repeating gradients requreid to have minimum 1px width
22:57:53 <fantasai> TabAtkins: That guarantees we can tile the space like we should
22:58:02 <fantasai> TabAtkins: Don't know if it's ideal, but it stops the problem of infinity
22:58:27 <fantasai> TabAtkins: Other possibility that preserves continuity is that when we hit zero width, we pick the average color you'd get
22:58:43 <fantasai> TabAtkins: Seems kinda complicated for an edge case, but I don't realy care, just want a decision
22:58:52 <fantasai> TabAtkins: And to be consistent with svg
22:59:00 <fantasai> Florian: Pixels aren't px
22:59:12 <fantasai> TabAtkins: I'm fine with saying it's a hairline wide
22:59:21 <fantasai> Florian: So you do fallback at device pixel
22:59:30 <fantasai> Brian: WD says to use first oclor stop
22:59:39 <fantasai> TabAtkins: Yeah, but that's not continuous behavior
22:59:53 <ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
23:00:06 <fantasai> [fast talking]
23:00:22 <fantasai> Brian: Non-repeating radial gradients folow last color stop rule
23:00:30 <fantasai> dbaron: Butwith those you always fill the area outside with that color
23:00:40 <fantasai> TabAtkins: As you approach the limit, you get that result
23:00:44 <fantasai> Brian: So it's continuity issue.
23:00:57 <fantasai> TabAtkins: I'm ok with either way, whatever way implementers would like to do, let's do
23:01:05 <fantasai> shepazu: SVG, when it hits zero, says that nothing is rendered
23:01:12 <fantasai> shepazu: That kinda punts on that
23:01:24 <fantasai> shepazu: I don't know that SVG says anything about approaching zero
23:01:43 <ChrisL> it does not, no. its either a zero bounding box or it isn't
23:01:47 <fantasai> shepazu: The averaging thing doesn't seem like what ppl want to do
23:02:09 <fantasai> fantasai: I think that makes the most sense; asyou zoom out that's what you'd get
23:02:24 <fantasai> shepazu: It'd be mixed with other color.. start color end color harmonious with page
23:03:03 <fantasai> TabAtkins: If you do 1px red blue and repeat it, it looks purple. If you make it smaller, can assume it'll look purple
23:03:31 <fantasai> Brian: 1px seems too large to me. But making the spec normative at 1px, but allow better resolution
23:03:33 <smfr> smfr has joined #css
23:03:44 <fantasai> TabAtkins: So the clamp is at 1px or below.
23:03:55 <nmccully> nmccully has joined #css
23:03:55 <anne> anne has joined #css
23:03:58 <ChrisL> px or device pixel?
23:04:05 <fantasai> Florian: So this would allow them to go to device pixel, but not force it
23:04:06 <fantasai> CSSpx
23:04:10 <ChrisL> eww
23:04:19 <ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
23:04:41 <fantasai> Brian: Do you want inconsistent rendering across zoom
23:05:02 <fantasai> Brian: If you'll get purple pixels sooner at one zoom level than another zoom level
23:05:23 <fantasai> ...
23:05:35 <fantasai> TabAtkins: Gradients are a vector format in any case
23:05:49 <fantasai> shepazu: If you zoom in until 1px is the whole screen, then what?
23:06:21 <fantasai> TabAtkins: You're allowed to clamp at a smaller size
23:06:40 <fantasai> Brad: Makes sense. Like with text you get better resolution as you zoom in.
23:06:48 <ChrisL> <g transform="scale(1000,1000)"><rect width="1px" height="1px"fill="url(#gradient"/></g>
23:06:52 <fantasai> TabAtkins: It ends up being a quality-of-implementation issue.
23:07:16 <fantasai> dbaron: As the length of the repeating gradient approaches zero, you should average the color.
23:07:24 <fantasai> Florian: Need to make sure it's not going to do that at 20px
23:07:42 <dbaron> s/As the/You could just specify that as the/
23:07:43 <ChrisL> I don't want the 1000 by 1000 device pixels rect above to be a solid colour
23:08:09 <fantasai> plinss talks about billionths of a CSSpx
23:08:56 <ChrisL> @shepazu could you read out my example please and make sure people understand it
23:08:58 <fantasai> dbaron: I think it should be device pixels, because if you zoom out ...
23:09:24 <fantasai> plinss: Say that the UA can substitute an average color if the gradient length is small [...]
23:09:49 <florian> florian has joined #css
23:09:56 <mmielke> mmielke has joined #css
23:11:01 <fantasai> fantasai: Just define what happens at zero. Everything above zero is handled by pixel-rounding, which we don't speicfy
23:11:10 <fantasai> TabAtkins: So should I specify averaging color?
23:11:29 <fantasai> dbaron: Need to specify color space to average in
23:11:51 <fantasai> shepazu: So what happens when you zoom in?
23:11:57 <fantasai> TabAtkins: That depends on implementation
23:12:02 <ChrisL> @dbaron yes, you do
23:12:04 <fantasai> TabAtkins: If you zoom enough you hit rounding issues
23:12:41 <ChrisL> @tab that is always the case. welcome to the world of non-financial computing which uses fixed precision arithmetic
23:12:43 <fantasai> TabAtkins: I want to make sure ChrisL's case is handled
23:13:00 <fantasai> TabAtkins: is allowed to handle, don't know if I can require it
23:13:13 <fantasai> ..
23:13:19 <fantasai> TabAtkins: I can't must without being precise
23:14:21 <fantasai> shepazu: It's not as important to specify the behavior at 1px when ti's been defined as 1px, it's what the rendering is.
23:14:22 <dbaron> I think Peter's suggestion was good.
23:14:38 <fantasai> shepazu: Important part was ... as you zoom in that 1px width is now 50 pixels it should have the whole gradient
23:14:48 <fantasai> shepazu: You can test that -- chris just wrote a test for that.
23:15:03 <fantasai> shepazu: You haven't been dealing much with things like scale, but you're going to be, so you're going to run into this problem
23:15:21 <ChrisL> css transforms
23:15:33 <fantasai> Dean: We all know the implementers are going to do the best they can.
23:16:52 <fantasai> plinss: This is very simply specified.
23:16:58 <fantasai> plinss: You try to not overspecify it.
23:17:02 <ChrisL> s/gradient"/gradient)"
23:17:38 <fantasai> plinss: When the UA has knowledge of the output resolution, it's allowed to substitute an average color for the repeating color when the device does not have the resolution to capture the resolution correctly.
23:17:50 <fantasai> plinss: It lets everybody do the right thing to the best of their ability.
23:18:22 <plinss_> s/the resolution correctly/the gradient correctly/
23:18:34 <fantasai> RESOLVED: Accept plinss's proposal.
23:19:06 <fantasai> TabAtkins: Image values is becoming divergent in implementation stability. Some features like gradients widely implemented, others have no impls or are just beginning implementation.
23:19:35 <fantasai> TabAtkins: In the interest of getting gradients unprefixed as soon as they're sufficiently stable, I'd like to either pull gradients out into a Gradients spec, or go through and kick a bunch of stuff into css4-images
23:19:52 <fantasai> TabAtkins: pecifically, the image() function, the cross-fade() function, and image-* properties
23:20:29 <ChrisL> which is larger, the bits you cut out or the bits you leave in?
23:20:32 <fantasai> JohnJansen: I think pulling out Gradients would make it easier.
23:20:42 <fantasai> sylvaing: If you move the others, you're still splitting the document.
23:20:52 <fantasai> ChrisL, about equal
23:21:45 <fantasai> fantasai: There's some things that should move just as fast as gradients. Also you need to define <image> type.
23:22:04 <fantasai> TabAtkins: CR can reference WD, so it wouldn't delay CR, just REC
23:22:18 <fantasai> TabAtkins: I just want to get Gradients to a point where we can kill prefixes
23:22:32 <fantasai> TabAtkins: I don't care either way; WG decide for me.
23:23:04 <sylvaing> http://dev.w3.org/csswg/css3-images/
23:23:40 <fantasai> TabAtkins: So, we would keep 4.1. 4.3 is implemented in Mozilla, so keep that there. We can test it for now.
23:23:45 <fantasai> TabAtkins: 4.2 and 4.4 would go
23:23:49 <fantasai> TabAtkins: Gradients stay
23:24:02 <fantasai> TabAtkins: 6 stays; object-* implemented already, rest is image sizing algorithm
23:24:14 <fantasai> TabAtkins: Rest can be punted to level 4
23:24:28 <ChrisL> I suggest splitting into css3 graidients and css3 images. because css4 images sounds like its years away, just from the name
23:24:55 <fantasai> dbaron: Things without 2 impls should be at-risk
23:25:09 <fantasai> ChrisL, we'll publishing Selectors 4 next month ;)
23:25:31 <fantasai> TabAtkins: 9 is a separate issue we need to discuss
23:26:01 <fantasai> smfr: Seems we need cross-fade() to interpolate gradients
23:26:28 <fantasai> Florian: We could pull back into 3 if it stabilizes before CR
23:26:37 <ChrisL> @smfr you mean to interpolate as in a transition, not to draw the gradient?
23:27:04 <fantasai> plinss: Any objections to splitting along the lines described?
23:27:18 <smfr> ChrisL: my point is that interpolation of gradients and images should be in the same spec
23:27:22 <fantasai> RESOLVED: Split css3-images as described
23:27:58 <fantasai> TabAtkins: 3rd issue is about gradients directly
23:28:14 <bradk> I am
23:28:18 <fantasai> TabAtkins: I've been messing with keyword definitions for gradients
23:28:30 <fantasai> TabAtkins: Right now you can specify linear gradients by keyword or angle
23:28:50 <fantasai> TabAtkins: Some very informal polls on twitter, if you ask someone what a gradient with top should do, they agree with the spec
23:28:59 <fantasai> TabAtkins: If you ask them about angles, they agree with the spec
23:29:17 <fantasai> TabAtkins: If you ask them both at the same time, they say they should be the same, despite that being inconsistent.
23:29:25 <fantasai> TabAtkins gives numbers
23:29:51 <fantasai> TabAtkins: Given this, I think the angles are very easy to see, but the way keywords work right now is confusing
23:30:02 <fantasai> TabAtkins: So I'm thinking we should drop keywords and work them out better for level 4
23:30:12 <TabAtkins_> data:text/html,<div id=one></div><div id=two></div><style>div {margin: 50px; border: thick solid black;width: 520px;height: 300px;}#one {background: -webkit-linear-gradient(top left, red, white, blue);}#two {background: -webkit-linear-gradient(-60deg, red, white, blue);}</style>
23:30:17 <fantasai> TabAtkins: We have an issue that corner-to-corner gradients, for example, are not sufficiently pretty.
23:30:25 <bradk> he're's mine: http://www.bradclicks.com/cssplay/linear-gradient/corner-to-corner-gradient.png
23:30:55 <fantasai> TabAtkins: The top one is what corner-to-corner gradients currently do
23:31:08 <fantasai> TabAtkins: The gradient bands are perpendicular to the diagonal gradient line
23:31:23 <fantasai> TabAtkins: But the lower picture is what people actually expect/want
23:31:57 <fantasai> TabAtkins: The two are different by the angle being reflected over the line y=x
23:32:07 <dbaron> data:text/html,<div class=one></div><div class=two></div><style>div {margin: 50px; border: thick solid black;width: 520px;height: 300px;}.one {background: -moz-linear-gradient(top left, red, white, blue);}.two {background: -moz-linear-gradient(-60deg, red, white, blue);}</style>
23:32:10 <fantasai> TabAtkins: one is 30deg other is 60deg
23:32:13 <ChrisL2> ChrisL2 has joined #css
23:32:16 <dbaron> (for those who don't want to use WebKit to look at it :-)
23:32:26 <fantasai> Brad: Another way to say is that for corner to corner, the hypothetical midpoint connects the other two corners
23:32:58 <fantasai> TabAtkins: With the current spec, the further the rectangle is from a square, the more it looks like a sideways gradient rather than a corner-to-corner one
23:33:19 <fantasai> TabAtkins: Given this issue, I want to drop keywords for now and address them in level 4
23:33:42 <fantasai> bradk: Keywords are the most popular way of doing this right now, mostly vertical or horizontal gradients.
23:34:15 <fantasai> Brian: Instead of up top and bottom, use upwards and downwards and instead of left and right use leftward rightward
23:34:24 <fantasai> Brian: And remove the paired keyword corner options
23:35:23 <fantasai> plinss: If we do partial keyword option, then we're locking in our syntax and it'll be incompatible with our future syntax.
23:35:54 <fantasai> plinss: We'll get into a situation where we dislike our legacy keywords and can't change them.
23:36:03 <fantasai> TabAtkins: Could use a different function
23:36:16 <fantasai> dbaron: Authors really want gradients. At some point we need to stop fiddling with it and declare it ready.
23:36:18 <arno1> We could just have "horizontal" and "vertical" as keywords
23:36:29 <fantasai> Florian: We're not throwing out all of it, just part of it
23:36:35 <fantasai> Florian: just the part we don't agree on it.
23:37:13 <dbaron> anne: We did that with border-radius, and by the time we got it sorted out they weren't popular anymore. :-)
23:37:14 <fantasai> TabAtkins: We solve the cases we know we need now, get them unprefixed, then see if the remaining cases are useful enough to care
23:38:06 <fantasai> Brad: the only gradient generators online use the keyword types right now, and because we changed the angle definition, you can't get something that works
23:38:15 <fantasai> Brad: People use prefixed versions for years.
23:38:22 <fantasai> TabAtkins: We're not going to use prefixed versions
23:38:37 <fantasai> Brad: Because we changed meaning of degress, you can't make a backwards compat version
23:38:54 <fantasai> TabAtkins: You write the prefixed versions with the old syntax, do unprefixed version with spec version
23:39:45 <fantasai> various try to explain that prefixed versions aren't going to change; they'll change when they drop the prefix
23:40:26 <smfr> Zakim: gavel
23:40:37 <fantasai> smfr, you forgot to use a comma
23:40:44 <fantasai> :P
23:41:16 <fantasai> plinss: How vendors deal with them and their customers is up to them.
23:41:44 <fantasai> Brad: I don't think we can pretend what we decide here is not going to have ramifications. If we don't have a committment that they won't do that... otherwise we wind up with something unusable
23:41:48 <fantasai> TabAtkins: That's why nobody will do that.
23:42:12 <fantasai> dbaron: We've done it plenty of times, but we probably wouldn't do it with this one
23:42:22 <fantasai> Anne: It worked fine for border-radius, -moz-opacity, etc.
23:42:42 <fantasai> Brad: I'd like to keep the keyword going and figure it out before we publish it.
23:43:03 <fantasai> Arron: Do you have a problem with upwards/downwards/etc
23:43:39 <fantasai> Brad: As plinss pointed out, it'll make it harder for us to get a consistent syntax later when we add corner-to-corner gradients
23:44:00 <fantasai> TabAtkins: The future has potential. I'm confident I'm not blocking my ability to expand in the future.
23:44:11 <fantasai> Brad: I don't see the syntax as being problematic.
23:45:11 <fantasai> Brad: I don't think it needs to change.
23:46:15 <fantasai> Brad: It's intuitive for a lot of people, and they've learned it, and do we really want to hold up the spec for this.
23:46:53 <fantasai> ...
23:47:08 <fantasai> smfr: I'm concerned about having multiple gradient functions. Do I need linear-gradient or corner-gradient?
23:47:12 <fantasai> smfr: confusing
23:48:16 <fantasai> TabAtkins: I think we can have a syntax that's different enough there won't be a parsing ambiguity
23:48:42 <fantasai> Brad: "from top" would be close to current syntax and resolve ambiguity
23:49:14 <fantasai> Brad: "left" -> "rightwards" is more different
23:49:35 <fantasai> plinss: The question was about whether to drop the keywords, not about what they should be
23:49:55 <fantasai> plinss: So do we drop the keywords, or go offline and figure it out
23:50:10 <fantasai> TabAtkins: I want to drop the corner keywords
23:50:24 <fantasai> plinss: Sounds like we're don't have consensus
23:50:47 <fantasai> plinss: Take it to email/telecon
23:50:54 <fantasai> plinss: Any other gradient issues?
23:51:02 <fantasai> Brian: Premultiplied? Keep it don't keep it have options?
23:51:26 <fantasai> TabAtkins: I think premultiplied produces most attractive gradients in common cases blending with transparent.
23:52:02 <fantasai> TabAtkins: I can go either way, depending on implementers
23:52:21 <fantasai> fantasai: If you go other way, then make 'transparent' magic.
23:52:40 <fantasai> TabAtkins: I don't want to make transparent magic.
23:54:00 <fantasai> ?: Drop 'transparent' keyword, make everybody use rgba()
23:54:14 <dbaron> Tab: If we're going to go non-premultiplied, then disallow use of 'transparent' and make everybody use rgba()
23:54:17 <fantasai> fantasai: That's horrible. You're making the author do the work.
23:54:30 <fantasai> ??: You have the same problem with transitions.
23:54:47 <fantasai> fantasai: gradient from color to tranparent is very common use case
23:55:12 <fantasai> smfr: Reality is that if we go with premultiplied we won't have it working correctly on Mac for another year or so
23:55:15 <ChrisL> ChrisL has joined #css
23:55:29 <fantasai> anne: If it's just a year, I say head for the future.
23:55:57 <fantasai> Vincent: Example of where premultiplied looks better?
23:56:16 <fantasai> TabAtkins: yellow to transparent, in premultiplied goes from yellow, fading to transparent
23:56:31 <nimbupani> http://jsfiddle.net/rK9Pd/11/show/
23:56:34 <fantasai> TabAtkins: in non-premultilied, goes through an ugly grayish greeny color
23:56:36 <nimbupani> (check in webkit vs opera)
23:57:17 <fantasai> TabAtkins: If you go red - transparent - blue, if you want to make it work correct in non-premultiplied, you have to write red, transparent-red, transparent-blue, blue, placing transparent-blue and transparent-red at the same spot in the gradient
23:57:51 <fantasai> plinss: Why don't we want to do premultiplied?
23:58:03 <fantasai> TabAtkins: It's not natively available on some platforms
23:58:10 <fantasai> smfr: We'd have to get libraries to add it
23:58:29 <glazou> glazou has joined #css
23:59:28 <fantasai> Brian: Alan Gresley was asking about non-premultiplied gradients because there are some cases that you'd want that result
23:59:53 <fantasai> TabAtkins: You could simulate it by manually arc it through the color space, it's tricky, but doable, and a very uncommon case in comparison
00:00:13 <fantasai> Brian: I had good results with Opera
00:00:35 <fantasai> TabAtkins: With Opera and IE we'll have 2 impls, so let's stick with that.
00:00:45 <fantasai> RESOLVED: Use premultiplied colors for gradients and transitions
00:01:20 <fantasai> shepazu: At the outset of this effort, there was discussion about remaining compatible with SVG  gradients.. was that abandoned?
00:01:26 <fantasai> TabAtkins: No. SVG doesn't have alpha colors.
00:01:40 <fantasai> shepazu: Talking about geometry
00:02:03 <fantasai> TabAtkins: Yeah, I don't think that's useful. But I was going to talk tomorrow about using SVG paint servers in CSS or CSS gradients in SVG.
00:02:18 <fantasai> shepazu: So an engine supporting both will have to support two different things.
00:02:20 <fantasai> TabAtkins: Yes.
00:02:33 <fantasai> plinss: Ok, let's discuss that tomorrow. Grids.
00:02:36 <fantasai> Topic: Grids
00:04:04 <fantasai> Phil: My name is Phil and I'm from MS.
00:04:59 <fantasai> Phil: We recently published new editor's draft. Hoping none of it's controversial so we can go through it quickly.
00:05:11 <fantasai> Phil: With one possible reduction in functionality in grid template property
00:05:38 <fantasai> Phil: specifically, assinging display types to grid pseudos
00:06:30 <fantasai> ACTION Phil: Post notes to www-style or www-archive so they can be put in the minutes
00:06:30 <trackbot> Sorry, couldn't find user - Phil
00:06:39 <smfr> http://dev.w3.org/csswg/css3-grid-align/
00:06:48 <fantasai> Phil: 7.2 covered explicitly defined grid cells, creating named grid cells
00:06:59 <fantasai> Phil: You could place children of the grid into them. We're removing that
00:07:15 <fantasai> Phil: Removing grid-stacking property, which said which layout this explicitly-defined grid cell would be using
00:07:33 <fantasai> Phil: The other mode it had was layer, which was the default layout type for a grid cell so items would layer on top of others
00:07:52 <fantasai> Phil: When we presented that at MV ...
00:08:11 <fantasai> Phil: Talked about creating flows inside a grid cell
00:08:30 <fantasai> Phil: And assigning display types to the grid cell
00:08:30 <glazou> glazou has joined #css
00:08:51 <fantasai> Phil: This was about creating presentation-specific structure through declaration of these grid cells, trying to remove concept form the grid layout spec
00:09:25 <fantasai> Phil: We also added new paragraph about grid cell concept. We still have logicla notion of a grid cell, but it's just an alias syntax for referring to a region of the grid.
00:09:32 <fantasai> Phil: But we're saying it's not stylable
00:09:39 <fantasai> Phil: It's just a way to name a spot on the grid
00:10:01 <fantasai> Phil: In section 6.4 , repeating columns and rows. e got some ffeedback that the name dlines syntax we had didn't make sense inside repeating syntax
00:10:21 <fantasai> Phil: Since it defined that only the firs toccurance of the name would be honore, and purpose of repeat syntax is to replay the grid  lines over
00:10:34 <fantasai> Phil: Added issue as te whether to remove that ability from there
00:10:44 <fantasai> Phil: Any feedback, send it, otherwise we'll remove
00:10:54 <fantasai> Phil: We also had another isuse on the grammar, for grid columns and grid rows
00:11:02 <fantasai> Phil: So we changed from ... to ...
00:11:15 <fantasai> Phil: I'll let you figure it out; trust me the new one is better.
00:11:29 <fantasai> Phil: Section 7.1 anonymous grid cells, we just added some language about relation between grid cells
00:11:38 <fantasai> Phil: Now it's just logical container, what does it do to grid items inside.
00:11:44 <fantasai> Phil: Define them as containing block
00:11:57 <fantasai> Phil: And we said how they came ito being, added language defining dminesions of the grid cell etc.
00:12:35 <fantasai> Phil: Next is explicitly defined grid cells, 7.2  is gone
00:12:43 <fantasai> Phil: Defining grid cells with a template is still there
00:12:48 <fantasai> Phil: Still use the ascii-art syntax
00:12:59 <fantasai> Phil: Keeping around grid-cell proeprty, just don't have pseudo-element selector
00:13:05 <fantasai> Phil: Can still define grid, and put things in it
00:13:08 <fantasai> Phil: witht hat
00:13:18 <fantasai> Phil: Section 7.5 automatic placement of grid items.
00:13:27 <fantasai> Phil: It's no longer what we're thinking, so removed note
00:13:34 <fantasai> Phil: ...
00:13:51 <fantasai> Phil: Importance of automatic placement, some language about fixup of grid; it matches language in flexbox
00:14:07 <fantasai> Phil: And we noted that if we don't have this fature, the fixup isn't useful
00:14:21 <fantasai> Phil: Everything just gets dumped into first grid row. We're planning to leave in, so this is just an observation
00:14:31 <fantasai> Phil: I just renamed section 8.1 .. size of grid items.
00:14:39 <fantasai> Phil: Needs more work; need to specify box model calculations
00:14:53 <fantasai> Phil: So if going to be stretched, questions like whta if you have a replaced element with intrinsic ratio ...........
00:15:25 <fantasai> Phil: 10 calculating isze of grid tracks. Don't know if anyone is implementing, or thinking of implementing, but if so, we've published osme pseudo-code about sizing these bits of the grid.
00:15:31 <fantasai> Phil: Some bugs in it still
00:15:42 <fantasai> Phil: We'll update a few more times before pushing to WD
00:15:48 <fantasai> Phil: Lastly all these changes captured in Appendix A
00:16:21 <fantasai> Phil: That is everything we have changed. The biggest piece is obviously the inability now to create these grid cells that you can give a display inside to control how they layout their contents, does anybody have objections to removing concept from the spec?
00:16:31 <fantasai> TabAtkins: Ok with it, majority of my use cases don't need it.
00:16:48 <fantasai> TabAtkins: But if I ant to use this with regions, I need to nwo insert dummy elements to position them with grid ...
00:16:58 <fantasai> TabAtkins: I greatly disagree that I should put dummy divs in my doc
00:17:15 <fantasai> Markus: We think that should be defined somewhere other than grid
00:17:42 <fantasai> TabAtkins: I hate junk put into your page for the sole purpose of styling.
00:18:29 <fantasai> Tab tries to explain the difference between semantic markup and stylistic presentation to the MS folks
00:18:54 <fantasai> Steve: Aren't templates a little bit of both?
00:19:55 <fantasai> TabAtkins: As long as we keep in mind that we might want to do this more generalized in the future, then I'm cool.
00:20:00 <bradk> If the CSS is creating the pseudo-elements, then conceivably more regions can be created to accomodate more content.
00:20:03 <fantasai> Vincent: We have a resolution on this from the morning.
00:20:14 <fantasai> ...
00:21:02 <fantasai> Alex: One issue that we discovered ... which was that alignment in grid is currently different from alignment in flexbox
00:21:25 <fantasai> Alex: What we discussed yesterday flexbox alignment, we kinda liked the idea of what grid is doing now. We're going to come up with a proposal that will make something consistent between the two.
00:21:37 <fantasai> TabAtkins: Don't think they need to be different when both flexing and aligning stuff
00:22:00 <fantasai> Markus: Q for Peter, we experiment with named lines, and ended up with very long strings. 
00:22:31 <fantasai> Markus: Is ther ea way to shortcut this somehow? Authoring becomes awkward.
00:22:45 <fantasai> Phil: This example uses template
00:23:08 <fantasai> Phil: It only takes one letter to name a position
00:23:22 <fantasai> Phil: with named grid lines
00:23:35 <fantasai> Phil: You end up putting 4 strings for each item that you had
00:23:55 <fantasai> Phil: It gets a little verbose
00:24:04 <fantasai> Phil: I think in practice if you have a grid, and have a large number of grid items
00:24:24 <fantasai> Phil: And don't want to renumber them, you probably won't use named lines anyway
00:24:33 <fantasai> TabAtkins: What wins if you use grid-rows, grid-columns
00:24:41 <fantasai> Phil: If the grid cell exists, then it wins
00:24:53 <fantasai> TabAtkins: What properties apply to grid templae ??
00:25:41 <fantasai> ...
00:25:50 <fantasai> Phil: You can only use ascii letters in grid template
00:26:04 <fantasai> Florian: Disallowing punctuation doesn't disallow Chinese characters or accented characters...
00:26:22 <fantasai> TabAtkins: Most reasonable layouts won't use 26, but last year I was looking at some very complicated layouts that were pushing it
00:26:29 <fantasai> Arron: I had 180 in a layout I did
00:27:12 <fantasai> TabAtkins: I think you should say any single character
00:27:21 <fantasai> fantasai: grapheme cluster
00:27:36 <fantasai> ...
00:27:37 <dbaron> I wouldn't allow more than characters that are allowed to start identifiers.
00:28:02 <fantasai> Phil: Would you use numbers ... ?
00:29:52 <fantasai> dbaron: That includes most of Unicode except some ascii punctuation and stuff
00:30:30 <fantasai> plinss: Where it gets unweildy with grid names, it's not so much where they're defined as where they're used
00:31:18 <dbaron> template: "北北北北" "西中中东" "西中中东" "西中中东" "西南南东";
00:31:19 <fantasai> ...
00:31:28 <fantasai> plinss: I'm not concerned about the verbosity of the grid columns declaration
00:31:35 <fantasai> plinss: I fyou line it up like that, I think it's readable
00:31:41 <fantasai> plinss: Later when you do the grid-column ...
00:31:59 <fantasai> Phil: You have up to for lines for positioning, so that's not too bad.
00:32:10 <fantasai> Phil: But if you have a lot of grid items, that gets quite large
00:32:17 <fantasai> plinss: Depends on how large your grid is
00:32:48 <fantasai> Phil: No issues open on it, these are just some comments we got back
00:32:58 <fantasai> plinss: Maybe you can have something that maps grid cells back into named grid lines
00:33:09 <fantasai> plinss: Right now you can only do that with template.
00:33:21 <fantasai> plinss: What if you could define a grid-cell "foo" defiend by these named lines
00:33:36 <fantasai> plinss: You're not defining the grid template, so not single-letter names; use multi-character names
00:33:47 <fantasai> Phil: We had ::grid-cell() pseudo that could do that
00:33:55 <fantasai> Phil: It was tyleable enough that you coudl specify the  ...
00:34:07 <fantasai> Phil: Ultimately we pulled that out
00:34:24 <fantasai> Phil: Anything else?
00:34:37 <fantasai> TabAtkins: Alex and I were talking about dropping the 'fr' unit and just using the flex() function
00:35:07 <fantasai> for flexbox
00:35:27 <fantasai> Alex: Flex function can do everything fr unit can do in flex, but fr unit is just a shortcut for one of the use of flex function
00:35:40 <dbaron> Isn't 'fr' a shortcut for one of the uses of the flex() function that requires all three arguments?
00:35:47 <fantasai> Alex: In a grid fr is a basic of how it is calculated
00:36:10 <fantasai> Alex: it would be .. also allow flex function in grid, in which case you could replace fr unit with it or have both
00:36:27 <fantasai> Phil: right now we have minmax function, and cna mix that with min-content, max-content keywords
00:36:39 <fantasai> Phil: Would we introduce flex() function there?
00:36:51 <fantasai> Alex: flex function has flexibility and preferred size
00:36:54 <fantasai> Alex: ...
00:37:21 <fantasai> Alex: Auto and flexibility at once.. produces the same calculation .. maximum, however preferred size of column based on content
00:37:29 <fantasai> Phil: There's just an issue we haven't resolved in the spec now
00:37:59 <fantasai> Alex: For flexbox you don't specify 50 values for an items, so flex() being longer than a unit is not a big deal, but on a grid probably woudln't want to replace fr unitl with flex
00:38:03 <fantasai> Alex: Make it even longer
00:38:19 <fantasai> Alex: So if in grid definition fr is shortcut for flex(), we could kepe it for flex
00:38:37 <fantasai> TabAtkins: I'm uncomfortable with two of us using different notions of flex
00:39:02 <fantasai> dbaron: fr right now is equivalent to flex() on a basis of 0, and 0 is not the defautl for that third argument
00:39:12 <fantasai> TabAtkins: I changed flex() ...
00:39:24 <fantasai> TabAtkins: If you say flex(1), you start from zero
00:39:35 <fantasai> TabAtkins: That's not what my spec says right now
00:39:44 <fantasai> Alex: ...
00:39:50 <fantasai> TabAtkins: Ok, we need to discuss this
00:40:00 <fantasai> dbaron: I agree with Alex, but I think that's another reason to keep fr.
00:40:21 <dbaron> s/.../the omitted preferred width should default to initial value/
00:40:38 <fantasai> Arron: We submitted our proposal for floats and positioning, and we decided to split those. Alex volunteered me to do the editing
00:40:41 <arronei> http://www.interoperabilitybridges.com/css3-positioning/
00:40:57 <glazou> glazou has joined #css
00:41:05 <fantasai> Arron: So you can take a look at it.Not too many differences from 2.1
00:41:24 <fantasai> Arron: Most of it's what 2.1 says, with some little clarifications of handling our new value. So you won't see a lot of differences.
00:41:30 <fantasai> Arron: Will jump straight to some changes.
00:41:38 <fantasai> Arron: So our first change that we have here is page positioning.
00:41:52 <fantasai> Arron: What this defines is a way to go straight for the initial containing block, much like fixed positioning does but without fixing on the page
00:42:00 <fantasai> Arron: So size and positioning based on initial containing block
00:42:15 <fantasai> Arron: It'll go all the way to the initial containing block, and positioning off of that box.
00:42:27 <fantasai> Arron: That's the first part.
00:42:39 <fantasai> smfr: How is it different from position: fixed
00:42:54 <glazou> http://www.interoperabilitybridges.com/css3-positioning/ (trailing slash DOES matter)
00:43:06 <fantasai> Rossen: If we create a region each the size of containing block, you want to have one positioned to the current region
00:43:19 <fantasai> Rossen: Don't want to rely on how many relative and abspos elements in your ancestor chain
00:43:32 <tantek> lol: http://twitter.com/getify/status/95648509319069696 <center> vs CSS
00:43:48 <fantasai> Rossen: Different from position: fixed because in scrolling media, it's fixed to initial contianing block. So element scrolls along with the rest of the content
00:44:03 <fantasai> Rossen: Similar to abspos content that has no positioned ancestor
00:44:13 <fantasai> Rossen: Whereas fixed replicates
00:44:52 <fantasai> Rosse: Position page was specific to design so you can target only the current page, and unlike position: fixed; position: paged; elements ... you can position negatively, and you can overflow, and that's just fine, whereas fixed position that just clips
00:45:03 <fantasai> dbaron: So it's positioned on the current page relative to its placeholder.
00:47:05 <fantasai> fantasai: My concern is that you'll get a layout that makes sense on paged media, but breaks in scrolled. Opposite problem of fixed positioning.
00:47:32 <jdaggett> jdaggett has joined #css
00:47:46 <fantasai> fantasai: e.g. if you use this on a 15-page document, positioning 15-20 things throughout the document across the 15 pages, looks fine
00:48:11 <fantasai> fantasai: Load that into a scrolled view, and everything piles on top of each other in the first screenful, and then scrolls away with the rest of the document empty
00:48:39 <fantasai> ...
00:48:51 <fantasai> Alex: We should have discusison of what are different aspects of paged media
00:49:02 <fantasai> Alex: Some means it's non-interactive, you're on paper
00:49:07 <fantasai> Alex: Some of it means you're paginated
00:49:21 <fantasai> Alex: From pov of layout, it's tempting to apply paged media to regions. But it's not paged media
00:49:58 <fantasai> Alex: Should we have a new media type?
00:50:03 <fantasai> fantasai: I think so.
00:50:20 <fantasai> Arron: What I"m trying to ge there is, we have this defintion right now, it may need more work as fantasai points out.
00:50:47 <fantasai> Arron: What I'd like to do is put it up on W3C as an actual editor's draft, so we can start to shape something that works
00:51:02 <fantasai> plinss: Anybody objecting?
00:51:12 <fantasai> RESOLVED: Put CSS3 Positioning draft on dev.w3.org
00:51:21 <fantasai> Arron: That's pretty much it. Please review once it's up
00:51:33 <fantasai> plinss: Some flexbox issues to get back to?
00:51:37 <fantasai> TabAtkins: Haven't had time.
00:51:44 <fantasai> Alex: Directions and alignment; need to ... 
00:52:01 <fantasai> plinss: Meeting closed.
00:52:05 <smfr> smfr has left #css
01:07:31 <karl> karl has joined #CSS
01:19:36 <dino> dino has joined #css
02:21:49 <smfr> smfr has joined #css
02:23:23 <smfr> smfr has left #css
03:11:30 <miketaylr> miketaylr has joined #css
03:53:38 <jdaggett_> jdaggett_ has joined #css
05:27:51 <arronei> arronei has joined #css
05:44:56 <plinss_> plinss_ has joined #css
05:52:10 <glazou> glazou has joined #css
05:54:27 <tantek> tantek has joined #css
06:19:22 <dino_> dino_ has joined #css
06:24:44 <dino_> dino_ has joined #css
06:38:43 <konaya> konaya has joined #css
06:44:34 <kojiishi> kojiishi has joined #css
07:33:22 <kojiishi> kojiishi has joined #css
07:37:54 <Jorrit> Jorrit has joined #css
07:38:09 <Jorrit> Jorrit has left #css
10:03:22 <Ms2ger> Ms2ger has joined #css
11:29:01 <karl> karl has joined #CSS
11:29:25 <karl> karl has joined #CSS
11:47:49 <Martijnc> Martijnc has joined #css
13:09:22 <miketaylr> miketaylr has joined #css
13:37:53 <anne> anne has joined #css
13:52:19 <nimbupani> nimbupani has joined #css
15:05:59 <oyvind> oyvind has joined #css
15:06:04 <oyvind> oyvind has left #css
15:09:04 <dino> dino has joined #css
15:39:02 <cjon> cjon has joined #css
15:40:11 <JohnJansen> JohnJansen has joined #css
15:44:52 <Martijnc> Martijnc has joined #css
15:46:28 <nimbupani> nimbupani has joined #css
15:49:11 <anne> anne has joined #css
15:49:21 <plinss_> plinss_ has joined #css
15:56:59 <JohnJansen> JohnJansen has left #css
15:58:20 <dino> dino has joined #css
15:59:38 <tantek> tantek has joined #css
15:59:55 <tantek> heading over - ETA 10min
16:01:11 <tpod> tpod has joined #css
16:03:57 <arronei_> arronei_ has joined #css
16:04:20 <arno> arno has joined #css
16:04:59 <bradk> bradk has joined #css
16:06:18 <bradk> hello?
16:06:53 <Ms2ger> Good evening
16:07:24 <bradk> Is the meeting starting?
16:08:03 <ed> in a moment
16:08:06 <Ms2ger> tantek said he'd be there in a couple of minutes
16:08:08 <sylvaing> sylvaing has joined #css
16:08:24 <plinss_> we'll be using the #fx channel for today's meeting
16:09:12 <bradk> Please let me know when there is a skype call ready to connect.
16:09:52 <tpod> tpod has joined #css
16:10:36 <hober> me too :0
16:10:40 <hober> err, :)
16:11:53 <dbaron> dbaron has joined #css
16:11:57 <tpod> How was the boat?
16:11:57 <smfr> smfr has joined #css
16:12:05 <anne> meeting is in #fx
16:12:20 <sylvaing> Anne sank one Microsoft employee in the lake: success
16:12:40 <sylvaing> Brad, i'm on Skype
16:13:00 <TabAtkins_> TabAtkins_ has joined #css
16:13:08 <tpod> anne: Pls set topic to say #fx
16:16:59 <szilles> szilles has joined #css
16:17:17 <florian> florian has joined #css
16:17:54 <shans> shans has joined #css
16:20:49 <tantek> tantek has joined #css
16:24:08 <alexmog> alexmog has joined #css
16:27:02 <dsinger> dsinger has joined #css
16:38:17 <szilles> szilles has joined #css
16:38:41 <ChrisL> ChrisL has joined #css
16:56:26 <szilles> szilles has joined #css
17:01:13 <shepazu> shepazu has joined #css
17:02:54 <stearns__> stearns__ has joined #css
17:11:39 <szilles> szilles has joined #css
17:49:21 <szilles> szilles has joined #css
17:57:55 <alexmog> alexmog has joined #css
18:02:02 <szilles> szilles has joined #css
18:02:59 <fantasai> dbaron: Is there a way to make it obvious when font-fallback happens? I considered adding Ahem to the fallback list, but it doesn't cover all of Unicode.
18:03:21 <dbaron> fantasai, we have a new api for determining the fonts that actually got used for a range of text
18:03:39 <dbaron> fantasai, beyond that, not sure
18:15:37 <hyatt> when you don't even know the height of your block yet
18:22:59 <konaya> konaya has joined #css
18:26:46 <szilles> szilles has joined #css
18:43:25 <szilles> szilles has joined #css
18:58:58 <arno> arno has joined #css
19:06:28 <dbaron> hyatt, well, yesterday I was the only one against it...
19:06:54 <hyatt> seems like a different layout model to me
19:07:08 <hyatt> like using left/top seems fine etc.
19:07:20 <hyatt> but it's not really laying out at the same time a normal positioned object would
19:07:43 <szilles> szilles has joined #css
19:07:45 <hyatt> just trying to understand
19:07:47 <hyatt> if it's 2-pass
19:07:48 <hyatt> or
19:07:51 <hyatt> i dunno
19:08:11 <dbaron> it's either 2-pass and suboptimal or abitrary-N-pass and correct
19:08:56 <dbaron> the draft hasn't specified which yet
19:13:00 <fantasai> :)
19:14:32 <szilles> szilles has joined #css
19:20:31 <hyatt> dbaron: is the expectation that positioned floats affect positioned descendants as well or only the normal flow
19:20:52 <hyatt> there's some confusing sentence in there about block formatting contexts
19:21:13 <hyatt> "A positioned-float box intersects with other elements in the same or other block formatting contexts. "
19:21:14 <dbaron> positioned descendants of what?
19:21:19 <hyatt> i have no idea what that sentence means
19:21:25 <dbaron> (That said, my response should probably be:  you're asking *me*?)
19:21:29 <hyatt> "or other block formatting contexts"
19:21:44 <hyatt> sounds like they expect it to actually affect things other than just your normal flow descendants
19:22:02 <arron> arron has joined #css
19:22:12 <hyatt> but maybe they just mean normal flow objects that establish bfcs
19:22:13 <hyatt> like overflow 
19:22:15 <hyatt> or columns
19:34:55 <tpod> tpod has joined #css
19:41:38 <tpod_> tpod_ has joined #css
20:03:44 <nimbupani> nimbupani has joined #css
20:10:40 <stearns> stearns has joined #css
20:35:03 <anne> anne has joined #css
20:35:04 <szilles> szilles has joined #css
20:35:20 <tantek> tantek has joined #css
20:37:30 <smfr> smfr has joined #css
20:38:12 <TabAtkins_> TabAtkins_ has joined #css
20:41:19 <ChrisL> ChrisL has joined #css
20:43:17 <alexmog> alexmog has joined #css
20:58:06 <szilles> szilles has joined #css
21:33:43 <tantek_> tantek_ has joined #css
21:45:11 <szilles> szilles has joined #css
22:25:46 <szilles> szilles has joined #css
22:30:07 <kimberlyblessing> kimberlyblessing has joined #css
22:43:29 <szilles> szilles has joined #css
22:54:34 <szilles> szilles has joined #css
23:07:15 <tpod> tpod has joined #css
23:09:38 <tpod_> tpod_ has joined #css
23:34:59 <szilles> szilles has joined #css
23:41:24 <tpod> tpod has joined #css
00:06:16 <tpod_> tpod_ has joined #css
00:25:46 <alexmog> alexmog has joined #css
00:25:53 <tantek> tantek has joined #css
00:43:20 <miketaylr> miketaylr has joined #css
00:55:03 <stearns> stearns has joined #css
00:55:10 <stearns> stearns has left #css
01:11:13 <dino> dino has joined #css
03:21:59 <arron> arron has joined #css
03:31:22 <dbaron> dbaron has joined #css
03:35:21 <nimbupani> nimbupani has joined #css
04:20:45 <anne> anne has joined #css
04:51:03 <tantek> tantek has joined #css
05:11:20 <alexmog> alexmog has joined #css
05:13:43 <TabAtkins_> TabAtkins_ has joined #css
05:14:21 <florian> florian has joined #css
05:14:50 <florian> florian has left #css
05:15:19 <plinss_> plinss_ has joined #css
05:21:31 <anne> anne has joined #css
05:30:58 <arronei_> arronei_ has joined #css
05:38:56 <arron> arron has joined #css
06:24:46 <homata> homata has joined #CSS