00:08:17 rhauck1 has joined #css 00:24:00 dauwhe has joined #css 00:43:45 we have a washroom attendant for the meeting room. not sure I'm really comfortable with that 00:45:03 is he a spy for WHATWG? 00:45:17 rhauck has joined #css 00:54:06 dauwhe_ has joined #css 01:03:38 cabanier has joined #css 01:03:55 cabanier1 has joined #css 01:09:07 dbaron has joined #css 01:13:15 jeff has joined #css 01:18:02 leif has joined #css 01:18:22 plh has joined #css 01:20:03 yamamoto has joined #CSS 01:20:35 Zakim has joined #css 01:20:43 zakim, this is style 01:20:43 sorry, plinss, I do not see a conference named 'style' in progress or scheduled at this time 01:21:03 rrsagent, this meeting spans midnight 01:21:37 zakim, remind us to go home in 10 hours 01:21:37 I don't understand 'remind us to go home in 10 hours', plinss 01:22:41 zakim, remind us in 10 hours to go home 01:22:41 ok, plinss 01:26:32 sgalineau has joined #css 01:26:48 ChrisL has joined #css 01:27:08 scribenick~; ChrisL 01:27:16 scribenick: ChrisL 01:27:23 topic: agenda 01:27:30 koji has joined #css 01:27:43 israelh has joined #CSS 01:27:50 plinss: see wiki. we have some joint meetings also 01:27:52 http://wiki.csswg.org/planning/tpac-2013 01:27:59 Rossen_ has joined #css 01:28:12 rrsagent, this meeting spans midnight 01:28:33 (some requests for slot movement due to people not here on Sunday) 01:28:55 krit: when is SVG joint meeting? 01:29:08 (tuesday) 01:29:41 plinss: tab should be calling in 01:30:08 krit: can we discuss css image 01:30:15 fantasai: yes, I'm here 01:31:10 dwim: digital publishing related not Monday 01:31:54 dino has joined #css 01:32:36 s/dwim/dauwhe 01:32:47 fantasai: wait for shapes until simon and leah get here, but today ok 01:33:16 plinss: text and writing modes tuesday morning 01:34:05 http://wiki.csswg.org/planning/tpac-2013 01:34:22 topic: gcpm 01:35:08 dwim: seemed unresolved on conference call, been writing tet cases, would like to co-edit 01:35:46 plinss: hakon has decised to work outside the group, we need to work inside the group for patent policy 01:35:54 ... david is willing to edit 01:36:14 Bert: hakon wants the group to not do anything for some months 01:36:36 ... think this is a good idea 01:36:56 s/david/dauwhe/ (just to disambiguate) 01:36:57 Rossen_: which one, the one we decided to split? 01:37:44 dino: there is a very easy solution to 'avoiding confusion' 01:38:23 heycam: as long as its different names for different proposals, no problem 01:39:12 dauwhe_: so wait a few months or not? it should stay in the css fold 01:39:19 krit: your preference? 01:39:41 dauwhe_: press on. I'm interacting with him if he wants to continue contributing ideas 01:40:07 plinss: any objections 01:40:51 resolved: david is the editor of GCPM 01:41:06 (discussion on spec naming and disambiguation) 01:41:51 ChrisL: good decision, start with last (split) editors draft 01:42:19 dauwhe_: would like some cleanup time before publication. noticed some holes while writing testst 01:42:56 ChrisL: looking for reviewers for tests? 01:43:06 plinss: familiar with the test format? 01:43:11 dauwhe_: learning 01:44:12 dauwhe_: noticing lots of small differences even in property naming between implementations 01:44:51 plinss: implementations are not done by members of wg so be aware of patent policy. lean towards what can be implemented by others 01:45:17 dauwhe_: larger question of how much we build on that spec and how much we build on regions 01:45:32 plinss: : the more we can leverage from existing work, the better 01:46:15 kawabata2 has joined #css 01:46:44 topic: camvas, video, css image 01:47:14 krit: (learns airplay) 01:47:41 krit: (demo) 01:48:06 ... would like to add a canvas function for a canvas2d graphics context 01:48:15 to 01:48:16 ... draw into and use directly as a css image 01:49:02 ... many authors like this 01:49:14 ChrisL: downsides? 01:49:49 krit: need to reference a dom elememnt directly to be selectable, canvas is created directly 01:51:05 dino: on the document element you ask for the context directly 01:51:23 ChrisL: can it be treated as a seperate single element dom tree? 01:51:55 fantasai: similar issue with a css element map that was in an earlier draft 01:52:12 ... could put things into the map that were not in the document tree 01:52:49 dino: element function has security issues with access to pixels, spell dict, etc. cancvas is clearer, page author drew into it 01:53:08 ???: can be a webgl context? 01:53:22 s/???/israelh/ 01:53:51 dbaron: want to see a writen proposal 01:54:07 q? 01:54:08 krit: fine, wanted to get reactions from group before writing it down 01:54:41 dbaron: ... so I can get reactions from others at Mozilla. 01:54:56 heycam: where does canvas size come from? what if you call the function multiole times with different sizes 01:55:38 dino: these are completely independent, can be displayed at any size 01:56:03 plinss: intrinsic size? 01:56:17 dino: dont know, maybe 300x150? 01:56:27 q+ 01:56:53 Rossen_: should be the same as what canvas does 01:57:20 plh: can you query the size? normally you quertry the canvas element not the context 01:57:29 dino: that would be real handy 01:57:41 plh; needs to be added to context and to webgl as well 01:57:42 s/quertry/query/ 01:58:25 http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/ 01:58:41 plh: can take a video element and draw that into the canvas 01:58:43 dino: yes 01:59:28 dino: proposed webgl extension with live update from video into canvas 02:00:14 ... its very complex, keeping audio and video in sync, loose audio sync is messing with video frames, need to resync 02:00:31 ... so for v1 make it a static snapshot from the video 02:01:03 sgalinea_ has joined #css 02:01:06 cabanier1: canvas has no memory 02:01:09 http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/src/#page/view-cover 02:02:21 cabanier1: does the canvvas have a lifetime? 02:02:27 dino: reference count 02:03:03 ChrisL: display: none vs visibility: hidden which keeps the canvas context 02:03:20 krit: next step is a spec proposal since there is interest 02:03:38 resolved: would like to see work on canvas for css image 02:03:54 action: krit to write up canvas for css4 images 02:03:54 Created ACTION-588 - Write up canvas for css4 images [on Dirk Schulze - due 2013-11-17]. 02:04:01 fantasai: ok 02:04:46 krit: video function 02:05:37 ... we could think about a video background, adding an element mixes markup and style 02:05:57 dbaron: video as a background image, what about the audio, is there a mute button 02:06:05 heycam: pause etc? 02:06:13 krit: no audio, just the video 02:06:27 because pause/play/etc. is on the DOM element itself 02:07:12 topic: device pixel ratio 02:07:37 (tab not here. we look at our shoes) 02:08:11 dino: apple seems to be in the minority here. its not window.devicepixelratio 02:08:20 ... hixie wants to add it to html 02:08:31 ... mozilla changes it based on full zooming 02:09:21 dbaron: on desktop we have two types of xzoonm, one changes only font size and the default one zooms all measurements and thus chjanges the device pixel ratio. so the width in css pixesl is shrinking 02:09:42 Rossen_: we have the exact same behaviour 02:10:00 dbaron: so this should be reflected in the media query 02:10:35 dbaron: pinch zoom means having two viewports, logical viewport scrolls intoa real viewport 02:10:46 dino: authors want to know those values too 02:11:03 dbaron: for compat the media queries need to be lkogical viewport 02:11:32 dino: intended a fixed value of device pixels:css pixcels so it is always 1 or 2 on apple devices 02:11:45 ... live ratio is a different thinhg 02:11:57 SimonSapin: is this acessible from javascript or mq? 02:12:06 dino: both, with same value 02:12:36 Rossen_: so you account for dpi into dpr? 02:12:46 ChrisL has joined #css 02:12:50 dino: : no, always 2 or 1 regardless of zoom# 02:13:36 Rossen_: we persist high dpi, same as user zoom, (user can change dpi) 02:13:54 ... anything to do with device adapatation 02:14:10 .. like text size adjust 02:14:18 israelh: static vs dynamic 02:15:13 dino: hixie on whatwg list said he would like toexpose these persistent properties as a new property but robert said it should just be dpr 02:15:35 israelh: also a proposal to add a second api 02:15:54 dino: difficult to change now, would break content 02:16:55 (missed) 02:17:06 Bert: what is the value for print 02:17:16 dino: 1. hmm. not sure 02:17:26 ChrisL: so its a retina y/n value 02:17:29 dino: yes 02:17:46 plinss: gecko and ie show the actual ratio 02:17:56 dbaron: yes its a float 02:19:26 dino: would like to see something new that gives you all this info: actiual display pixels, page (user) zoom, viewport within that 02:19:49 ChrisL has joined #css 02:20:12 dino: can't replace a lores with a hires image for example 02:21:01 ChrisL: relayout and replacement of assests are different 02:21:25 Rossen_: currently for us its just a transform, no impact on layout 02:22:04 plinss: if you have an image source that has multiople respolutions it should respond 02:22:38 heycam: what about mapping where you want new layers to come in diring a gesture 02:22:53 dbaron: a mapping app is not using the browser zoom 02:23:11 dino: people add event listeners to detect pinch zoom 02:23:28 dino: want ui to be fixed size 02:23:42 sgalinea_: can zoom a sub frame 02:24:25 dbaron: we cant do different levels of detailautomatically as they zoom in 02:24:25 IE10+ allows the author to say a sub-frame can be pinch-zoomed independently from the host page 02:25:59 heycam: proposed a way to do this in tokyo, response to kddi tiling but using media queries 02:26:18 ... hard if pinch to zoom not exposed to media queries 02:26:51 Rossen_: we have two different types of zoom to address, one is static and persists actoss sessions and the other is dynamic 02:27:15 dbaron (above): Would like to expose API for pinch zoom to the Web platform 02:27:16 ... original discussion was around th static one. so can we settle that one first? 02:27:49 dino: prefer what we come up with is a new solution wth new names so old content does not break. better to design together 02:28:03 Rossen_: so deprecate dpr and make up two new things 02:28:26 israelh: suppose you have a device that is 1.5 but user setting is 1.25 02:28:43 jeff has joined #css 02:29:30 ChrisL: deprecating in favour of a richer solution is the only clear way to interop 02:29:46 dino: and the new api has more fiunctionality so iy will get used 02:29:58 dbaron: write a specdefining these terms 02:30:42 dino ted will do it 02:31:06 Rossen: I'll volunteer Matt Rakow. 02:31:15 ted == hober == Edward O'Connor 02:31:31 krit: is it part of MQ? 02:31:42 Rossen_: sounds like a new proposal 02:31:48 sylvain: or the device adaptation document? 02:32:44 SimonSapin: are these all media queries? 02:32:59 dino: also properties on window 02:33:22 ... and if media query values change its good 02:34:28 plinss: device adaptation module covers similar ground, coordinate 02:35:35 action: hober and matt to write a proposed resolution to resolve the proposal about device resolution (using unambiguous terms) 02:35:35 Created ACTION-589 - And matt to write a proposed resolution to resolve the proposal about device resolution (using unambiguous terms) [on Edward O'Connor - due 2013-11-17]. 02:36:38 plinss: we have this spead over several documents 02:36:49 Rossen_: could consolidate them all 02:36:50 s/spead/spread/ 02:37:24 israelh: will this define the final overall zoom? 02:37:27 Rossen_: yes 02:37:48 plinss: define which is exposed to mq, when they update and so on 02:38:47 Rossen_: and we need a backwards compat way to map old stuff to new properties 02:40:31 dbaron: willing to make changes 02:40:45 (more likely to be willing to not-change-with-zoom than to use only 1.0 and 2.0) 02:41:33 koji has joined #css 02:52:47 zcorpan has joined #css 02:53:50 zcorpan has joined #css 03:03:05 zcorpan has joined #css 03:05:01 xiaoqian has joined #css 03:05:11 ChrisL has joined #css 03:07:22 zcorpan_ has joined #css 03:07:31 ChrisL has joined #css 03:09:43 ScribeNick: fantasai 03:10:05 Topic: Shapes Syntax 03:10:12 http://lists.w3.org/Archives/Public/www-style/2013Oct/0695.html 03:10:49 israelh has joined #CSS 03:10:50 Rossen_ has joined #css 03:12:08 Alan: Issue is shapes draft has set of shapes functions that are derived from how shapes are defined in SVG 03:12:29 astearns: They have arguments of position and extent 03:12:47 astearns: fantasai pointed out that we have similar aruments in CSS, e.g. in gradients 03:12:58 astearns: In such syntax extent is before positioning, and all arguments are optional 03:13:10 Present: Chris Lilley, fantasai, Simon Peters, Leif Arne Storset, Dave Cramer, Bert Bos, Simon Sapin, David Baron, Lea Verou, Rossen Atanassov, Alan Stearns, Dean Jackson, Dirk Schultze, Sylvain Galineau, Israel Hilerio, Peter Linss, Rik Cabanier, Cameron McCormack, Kazutaka Yamamoto, Taichi Kawabata, ???, ???, Philippe Le Hegaret 03:13:23 astearns: The main difference is that SVG shapes and CSS shapes is that percentages in the position are handled differently 03:13:31 ChrisL has joined #css 03:13:41 astearns: My proposal is to keep the shapes syntax in the draft now, and in L2 create CSSy shape function 03:13:49 astearns: that would use radial-gradient syntax 03:13:53 q+ 03:14:27 astearns: fantasai points out that this will result in an SVG circle and ellipse function and a CSS circle and ellipse function that pretty much do exactly the same thing 03:14:36 astearns: and she's objecting to that duplication 03:14:48 yamamoto has joined #CSS 03:15:09 astearns: We're at a standstill: understand each others positions, but disagree on conclusions 03:15:47 rectangle (x y w h) 03:16:09 shape (rectangle w h ) 03:16:21 was it this email: http://lists.w3.org/Archives/Public/www-style/2013Oct/0734.html ? 03:16:43 chrisl: We changed a lot of syntax in CSS gradients 03:16:49 chrisl: SVG has been around a lot longer 03:16:56 ack ChrisL 03:17:08 ChrisL: Better to have that 03:17:22 ChrisL: because it's consistent with expectations 03:17:36 sylvaing: Shape functions also used in clip-path in SVG 03:17:40 or this email: http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html ? 03:17:45 sylvaing: so consistency with SVG might make sense 03:17:51 sylvaing: But working with HTML+CSS ... 03:18:13 Rossen: Initial motivation for adding shapes was so that we could have syntax close to SVG as possible 03:18:30 Rossen: even an ask of why even have CSS inline function, instead of referencing SVG 03:18:37 rossen: Plan to have this in L2, actually 03:18:45 Rossen: But having basic shapes close to SVG is the right way to go 03:19:05 shepazu: Canvas differed from SVG in subtle ways, and ppl didn't like that 03:19:32 fantasai: We already have conventions in CSS; you're proposing that instead of being consistent with the rest of CSS we be consistent with SVG. 03:19:51 fantasai: We've had shapes in CSS in gradients, and positioning syntax in CSS since CSs1 03:19:59 plh has joined #css 03:20:13 s/CSs1/CSS1/ 03:20:24 http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html was the email fantasai meant 03:20:42 fantasai: my point in that email was that we have this desire for consistency 03:20:45 fantasai: we have desire for consistency, you can argue for consistency in either in either direction 03:21:25 Alan: I'd propose adding the CSS-consistent forms in level 2; I want both. 03:21:35 fantasai: I'd object to the duplication. 03:22:11 fantasai: But for level 1 you'd have the inconsistency with CSS. 03:22:41 Alan: But we have circles and ellipses in gradients, but we don't have rectangles 03:22:48 Alan: We'd still need to define the extrapolation from background-position syntax to rectangles. 03:23:28 fantasai: My point in this email is that we're arguing over consistency, and you can argue in various directions 03:23:39 [interrupted by ChrisL] 03:23:49 chrisL: SVG has been aroun longer 03:23:55 chrisl: So we should be consistent with it 03:23:59 s/aroun/around/ 03:24:03 dbaron: I think there are still a lot more people hand-writing CSS than handl-writing SVG. 03:24:49 s/handl-writing/hand-writing/ 03:25:16 fantasai: There are lots of ways to argue about consistency. Why don't we discuss use-cases instead? 03:25:41 Alan: Percentage handling is different, so I want to have both syntaxes so that we can have both ways of handling percentages. 03:26:04 fantasai: I think this syntax is not an obvious way to express that the only functional difference is how % are handled. 03:26:20 krit: not the only difference 03:26:53 fantasai: But you wanted examples, lets put up examples 03:27:04 fantasai: We should look at what people actually want to do with these functions 03:27:43 fantasai: [goes to whiteboard] 03:27:59 fantasai: We're trying to do positioning, that's what the main difference. 03:28:06 yamamoto has joined #css 03:28:06 fantasai: so where do people want to position things? 03:28:21 fantasai: Common things are: align to the center or one of corners, or one of edges. 03:28:37 ChrisL: [inaudible] 03:28:47 ChrisL: I disagree those are the most likely 03:28:59 Alan: also might want to position top-left corner at a particular % width and height 03:29:09 fantasai: Isn't bottom-right equally likely? 03:29:14 Alan: no, top left is positioned most often 03:29:24 Bert: can we take one more step back about use cases -- talking about rectangles only? 03:29:40 fantasai: we have circle ellipse rectangle. Gradients and SVG are both consistent that circles are positioned by center and radius. 03:29:59 Bert: So I can understand why you'd want a circle or some other shape, what are the cases for a rectangle shape when you already have a rectangle 03:30:08 krit: can have rounded corners 03:30:17 fantasai: shouldn't there be an easier way 03:30:18 ? 03:30:23 peterl: follow rounded corners of border? 03:30:54 alan: might have something that gets displayed with gradient and the gradient has some portion on the content side that ok to display content over. So you'd reduce flow ??? using a rectangle. 03:31:10 Alan: if wrapping around drop cap with upright ascender at trailing edge, might want a rect that approximates glyph 03:31:15 doug: can I ask a followup? 03:31:30 doug: Let's grant that these are the most likely positions -- then what's your conclusion based on that? 03:31:40 fantasai: Common things should be simple and easy, and other things should be possible 03:31:49 fantasai: Common cases should be really easy. 03:31:59 doug: where does it differ from SVG? 03:32:22 Chris: SVG positions by top left. This does percentage matching like background position so you can easily get to all 4 corners. 03:32:38 doug: so the percentages is the difference? 03:32:58 fantasai: for these things you can just use a keyword. In SVG you need a calc() to get to the bottom right, calc(100% - w) 03:33:06 fantasai: This is duplication. 03:33:35 fantasai: rectangle(n, m, calc(100% - n), calc(100% ' m) 03:33:52 fantasai: great for people who like coordinate systems, but not great for a lot of designerns 03:34:08 doug: as somebody who's written SVG, inability to position something at bottom or right has hampered 03:34:24 Present+ Doug Schepers 03:34:36 fantasai: alternative is rectangle(n, m at bottom right) 03:34:45 doug: only difference is what % means 03:34:50 fantasai: that's where they're incompatible 03:35:10 fantasai: could put positioning syntax in svg style function too, but that would mean % interpreted differently in rectangle() and backgorurdn-position 03:35:34 fantasai: we have x,y,w,h,o so function in draft right nowwould look like rectangle(calc(100%-n), calc(100%-m), n, m) 03:35:52 fantasai: instead of having 2 lengths we could have it be a position that takes 2 or 4 values 03:36:01 fantasai: so it would be rectangle(bottom right n m) 03:36:07 Alan: we'd have to switch it around so that ... 03:36:15 krit, fantasai: don't have to 03:36:20 fantasai: we could restrict it so ... 03:36:30 Alan: then you're introducing an inconsistency with background-positioning 03:36:44 krit: how would rounded corners fit in 03:36:48 fantasai: just as now 03:36:49 in draft 03:37:11 doug: so you suggest putting css syntax of finto another draft 03:37:51 doug: I see some risks there in terms of -- if only thing impl is doing is parsing and interpreting syntax as opposed to implementing new feature -- doesn't seem a stretch to put both new syntaxes in the first draft. 03:37:59 doug: matter of when somebody learns something and when in browser 03:38:09 doug: I think having both in 1st draft would be not big impl burden and help developers 03:38:23 alan: I've been trying to reduce level 1 draft to improve chance of additional implementations 03:38:32 doug: I think the extra syntax isn't a big deal. 03:38:41 krit: fantasai, you wanted to limit position to what again? 03:38:57 fantasai: ... ... can't do 3 arguments, 2 or 4 would be possible 03:39:06 fantasai: but then # of arguments inconsistent with background-position 03:39:23 Alan: I think ... defaults ... is a valuable thing to maintain. 03:39:32 ChrisL has joined #css 03:39:36 fantasai^: in addition to percentage difference 03:39:57 Alan^: ability to drop things and have defaults is nice 03:40:15 peterl: matching shape to background gradient -- I don't want to see designer to specify gradient in one format and have to do a lot of math to figure out matching shape 03:40:19 peterl: should be almost copy-paste 03:40:39 Alan: I think it is b/c we allow shapes from image, and image value can be gradient, so can use gradient in both and extract shape from gradient 03:40:47 peterl: Does it get you ability to override part? 03:40:54 Alan: Can choose opacity threshold. 03:41:02 doug: any way to leverage variables for this? 03:41:16 sylvain: depending on variables maybe not great for quick impl 03:41:32 fantasai: you said use case of matching border even if curved -- I think that should be a keyword and should be in level 1 03:41:42 alan: I think the value in that case should be some self-referentiial element function 03:41:57 doug: also use clipping? 03:41:59 alan: no (?) 03:42:09 fantasai: Bert had a proposal for floats(?) to use contour keyword 03:42:15 fantasai: wouldn't it make sense to add that kw right here? 03:42:42 alan: perhaps, but we discussed in tokyo that following contours of arbitrary something can be security risk b/c you can determine contours of thing being displayed 03:42:59 alan: my reasoning for using element() is that element() has same security implications so solution for addressing those implication gets reused 03:43:10 krit: element() can't reference itself 03:43:24 jeff has joined #css 03:43:31 alan: can't reference itself or things that will affect layout of element, but can use data you get out for defining a shape-outside 03:43:43 alan: there are other uses of self-referential element function such as mirror images that have been discussed 03:44:05 fantasai: even if we have self-referential elements, for the use cases of just wanting wrapping to follow border, should be dead simple and available immediately 03:44:18 ... one of most common things along with following image threshold 03:44:29 ... don't think it should be hard to duplicate arguments already given to border-radius 03:44:47 alan: I agree common case we should solve, but question of what we can get done now vs what we need to work on w/o solving security issue 03:45:03 alan: I think images are more common use case than rendered content wrapping 03:45:24 fantasai: let's just solve that right now, and make shape-outside:contour than shape of border-radius gets projected out to margins and followed for wrapping 03:45:33 s/than/then/ 03:45:42 doug: I didn't see inherent conflict between SVG and CSS syntax 03:45:46 doug: I think we should have both 03:45:51 ChrisL has joined #css 03:46:03 krit: rectangle() can easily have one or other but not both? 03:46:08 alan: no, proposal is for it to have both 03:46:16 fantasai: proposal is: 03:46:41 shape(circle at ) 03:46:49 shape(rectangle at ) 03:47:02 circle(x y ) 03:47:08 rectangle(x y ) 03:47:34 fantasai: Alan's propsoal is to have all of these 03:47:44 fantasai: author would have to know that #2 and #4 have slightly different behavior 03:47:54 (and #1 and #3) 03:48:08 er, strike last line 03:48:17 fantasai: #1 and #3 are just different syntax 03:48:37 Rossen: ... we wanted to have shape keyword reserved so you can express outside shape and inside shape 03:48:46 Alan: never used shape shorthand, just wanted ... 03:48:56 Rossen: we had a version with shape shorthand that captured both outside and inside 03:49:10 Rossen: then you'd have nested functions: shape( outside(shape), inside(shape)) 03:49:50 Alan: you'd end up with shape: where one is outside and one is inside 03:49:55 (my syntax on rossen line was wrong) 03:50:08 Rossen: ... 03:50:14 Alan: that doesn't follow shorthand conventions 03:50:22 fantasai: shorthand should just be shape: {1,2} 03:50:31 fantasai: order controls outside vs. inside 03:50:55 peterl: I think that's a red herring; this is the issue on the table. 03:51:15 fantasai: bothers me: (1) inconsistency and duplication (2) switching shapes from circle to ellipse to rectangle is totally different 03:51:33 fantasai: (3) there's only one functional difference between the 2 which is percentages, which is not clear from difference in syntax 03:51:45 fantasai: so as an author you have to know there's a weird difference between them 03:52:07 doug: nothing about CSS is intuitive 03:52:11 fantasai: but we have to try to have conventions 03:52:23 fantasai: this difference is not evident at all 03:52:48 krit: back to interpretation: with rect having w/h of 50% and position 50%, would it now be centered? 03:52:53 http://xkcd.com/927/ 03:52:54 fantasai: yes 03:53:01