/irc-logs / w3c / #css / 2013-11-10 / end

Options:

# Session Start: Sun Nov 10 00:00:00 2013
# Session Ident: #css
# [00:03] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [00:07] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [00:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [00:47] * Joins: dbaron (~dbaron@public.cloak)
# [01:08] * Joins: rhauck1 (~Adium@public.cloak)
# [01:13] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [01:20] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [01:23] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:27] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [01:43] <astearns> we have a washroom attendant for the meeting room. not sure I'm really comfortable with that
# [01:44] <dauwhe> is he a spy for WHATWG?
# [01:45] * Joins: rhauck (~Adium@public.cloak)
# [01:45] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [01:54] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [01:59] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [02:03] * Joins: cabanier (~cabanier@public.cloak)
# [02:03] * Joins: cabanier1 (~cabanier@public.cloak)
# [02:09] * Joins: dbaron (~dbaron@public.cloak)
# [02:10] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 180 seconds)
# [02:14] * Joins: jeff (jeff@public.cloak)
# [02:15] * heycam|away is now known as heycam
# [02:17] * Joins: leif (~lastorset@public.cloak)
# [02:18] * Joins: plh (plehegar@public.cloak)
# [02:19] * Joins: yamamoto (~yamamoto@public.cloak)
# [02:20] * Joins: Zakim (zakim@public.cloak)
# [02:20] <plinss> zakim, this is style
# [02:20] <Zakim> sorry, plinss, I do not see a conference named 'style' in progress or scheduled at this time
# [02:20] <plinss> rrsagent, this meeting spans midnight
# [02:20] <RRSAgent> ok, plinss; I will not start a new log at midnight
# [02:21] <plinss> zakim, remind us to go home in 10 hours
# [02:21] <Zakim> I don't understand 'remind us to go home in 10 hours', plinss
# [02:22] <plinss> zakim, remind us in 10 hours to go home
# [02:22] <Zakim> ok, plinss
# [02:26] * Joins: sgalineau (~sgalineau@public.cloak)
# [02:26] * Joins: ChrisL (clilley@public.cloak)
# [02:26] * dbaron tries to remember whether the "spans midnight" is for UTC or Boston time
# [02:26] * dbaron notes we'd need it if it's Boston time but not if it's UTC
# [02:27] * plh thinks the group needs to start by refining the focus property
# [02:27] <ChrisL> scribenick~; ChrisL
# [02:27] <ChrisL> scribenick: ChrisL
# [02:27] * plh it seems unspecified at the moment
# [02:27] <ChrisL> topic: agenda
# [02:27] * Joins: koji (~koji@public.cloak)
# [02:27] * Joins: israelh (~israelh@public.cloak)
# [02:27] <ChrisL> plinss: see wiki. we have some joint meetings also
# [02:27] <dbaron> http://wiki.csswg.org/planning/tpac-2013
# [02:27] * Joins: Rossen_ (~Rossen@public.cloak)
# [02:28] <ChrisL> rrsagent, this meeting spans midnight
# [02:28] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
# [02:28] <ChrisL> (some requests for slot movement due to people not here on Sunday)
# [02:28] <ChrisL> krit: when is SVG joint meeting?
# [02:29] <ChrisL> (tuesday)
# [02:29] <ChrisL> plinss: tab should be calling in
# [02:30] <ChrisL> krit: can we discuss css image
# [02:30] <ChrisL> fantasai: yes, I'm here
# [02:31] <ChrisL> dwim: digital publishing related not Monday
# [02:31] * Joins: dino (~dino@public.cloak)
# [02:32] <dauwhe_> s/dwim/dauwhe
# [02:32] <ChrisL> fantasai: wait for shapes until simon and leah get here, but today ok
# [02:33] <ChrisL> plinss: text and writing modes tuesday morning
# [02:33] <ChrisL> http://wiki.csswg.org/planning/tpac-2013
# [02:34] <ChrisL> topic: gcpm
# [02:35] <ChrisL> dwim: seemed unresolved on conference call, been writing tet cases, would like to co-edit
# [02:35] <ChrisL> plinss: hakon has decised to work outside the group, we need to work inside the group for patent policy
# [02:35] <ChrisL> ... david is willing to edit
# [02:36] <ChrisL> Bert: hakon wants the group to not do anything for some months
# [02:36] <ChrisL> ... think this is a good idea
# [02:36] <astearns> s/david/dauwhe/ (just to disambiguate)
# [02:36] <ChrisL> Rossen_: which one, the one we decided to split?
# [02:37] * ChrisL oops sorry
# [02:37] <ChrisL> dino: there is a very easy solution to 'avoiding confusion'
# [02:38] <ChrisL> heycam: as long as its different names for different proposals, no problem
# [02:39] <ChrisL> dauwhe_: so wait a few months or not? it should stay in the css fold
# [02:39] <ChrisL> krit: your preference?
# [02:39] <ChrisL> dauwhe_: press on. I'm interacting with him if he wants to continue contributing ideas
# [02:40] <ChrisL> plinss: any objections
# [02:40] <ChrisL> resolved: david is the editor of GCPM
# [02:41] <ChrisL> (discussion on spec naming and disambiguation)
# [02:41] * sgalineau it could be GNU: GCPM is Not Unique
# [02:41] <ChrisL> ChrisL: good decision, start with last (split) editors draft
# [02:42] <ChrisL> dauwhe_: would like some cleanup time before publication. noticed some holes while writing testst
# [02:42] <ChrisL> ChrisL: looking for reviewers for tests?
# [02:43] <ChrisL> plinss: familiar with the test format?
# [02:43] <ChrisL> dauwhe_: learning
# [02:44] <ChrisL> dauwhe_: noticing lots of small differences even in property naming between implementations
# [02:44] * leaverou_away is now known as leaverou
# [02:44] <ChrisL> plinss: implementations are not done by members of wg so be aware of patent policy. lean towards what can be implemented by others
# [02:44] * Quits: jeff (jeff@public.cloak) (Ping timeout: 180 seconds)
# [02:45] <ChrisL> dauwhe_: larger question of how much we build on that spec and how much we build on regions
# [02:45] <ChrisL> plinss: : the more we can leverage from existing work, the better
# [02:46] * Joins: kawabata2 (~kawabata@public.cloak)
# [02:46] <ChrisL> topic: camvas, video, css image
# [02:47] <ChrisL> krit: (learns airplay)
# [02:47] <ChrisL> krit: (demo)
# [02:48] <ChrisL> ... would like to add a canvas function for a canvas2d graphics context
# [02:48] <astearns> to <image>
# [02:48] <ChrisL> ... draw into and use directly as a css image
# [02:48] <ChrisL> ... many authors like this
# [02:49] <ChrisL> ChrisL: downsides?
# [02:49] <ChrisL> krit: need to reference a dom elememnt directly to be selectable, canvas is created directly
# [02:51] <ChrisL> dino: on the document element you ask for the context directly
# [02:51] <ChrisL> ChrisL: can it be treated as a seperate single element dom tree?
# [02:51] <ChrisL> fantasai: similar issue with a css element map that was in an earlier draft
# [02:52] <ChrisL> ... could put things into the map that were not in the document tree
# [02:52] <ChrisL> dino: element function has security issues with access to pixels, spell dict, etc. cancvas is clearer, page author drew into it
# [02:53] <ChrisL> ???: can be a webgl context?
# [02:53] <astearns> s/???/israelh/
# [02:53] <ChrisL> dbaron: want to see a writen proposal
# [02:54] <israelh> q?
# [02:54] * Zakim sees no one on the speaker queue
# [02:54] <ChrisL> krit: fine, wanted to get reactions from group before writing it down
# [02:54] <dbaron> dbaron: ... so I can get reactions from others at Mozilla.
# [02:54] <ChrisL> heycam: where does canvas size come from? what if you call the function multiole times with different sizes
# [02:55] <ChrisL> dino: these are completely independent, can be displayed at any size
# [02:55] <ChrisL> plinss: intrinsic size?
# [02:56] <ChrisL> dino: dont know, maybe 300x150?
# [02:56] <plh> q+
# [02:56] * Zakim sees plh on the speaker queue
# [02:56] <ChrisL> Rossen_: should be the same as what canvas does
# [02:57] <ChrisL> plh: can you query the size? normally you quertry the canvas element not the context
# [02:57] <ChrisL> dino: that would be real handy
# [02:57] <ChrisL> plh; needs to be added to context and to webgl as well
# [02:57] <dauwhe_> s/quertry/query/
# [02:57] * ChrisL has poor finger coordination nowadays
# [02:58] <krit> http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/
# [02:58] <ChrisL> plh: can take a video element and draw that into the canvas
# [02:58] <ChrisL> dino: yes
# [02:59] * leaverou URL above doesn't work
# [02:59] <ChrisL> dino: proposed webgl extension with live update from video into canvas
# [03:00] <ChrisL> ... its very complex, keeping audio and video in sync, loose audio sync is messing with video frames, need to resync
# [03:00] <ChrisL> ... so for v1 make it a static snapshot from the video
# [03:00] * Joins: sgalinea_ (~sgalineau@public.cloak)
# [03:01] <ChrisL> cabanier1: canvas has no memory
# [03:01] <astearns> http://adobe-webplatform.github.io/Demo-for-Food-Network-Cupcakes/src/#page/view-cover
# [03:03] <ChrisL> cabanier1: does the canvvas have a lifetime?
# [03:03] <ChrisL> dino: reference count
# [03:03] <ChrisL> ChrisL: display: none vs visibility: hidden which keeps the canvas context
# [03:03] <ChrisL> krit: next step is a spec proposal since there is interest
# [03:03] <ChrisL> resolved: would like to see work on canvas for css image
# [03:03] <ChrisL> action: krit to write up canvas for css4 images
# [03:03] * trackbot is creating a new ACTION.
# [03:03] * RRSAgent records action 3
# [03:03] <trackbot> Created ACTION-588 - Write up canvas for css4 images [on Dirk Schulze - due 2013-11-17].
# [03:03] <ChrisL> fantasai: ok
# [03:04] <ChrisL> krit: video function
# [03:04] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
# [03:05] <ChrisL> ... we could think about a video background, adding an element mixes markup and style
# [03:05] <ChrisL> dbaron: video as a background image, what about the audio, is there a mute button
# [03:06] <ChrisL> heycam: pause etc?
# [03:06] <dbaron> krit: no audio, just the video
# [03:06] <heycam> because pause/play/etc. is on the DOM element itself
# [03:07] <ChrisL> topic: device pixel ratio
# [03:07] * dbaron Zakim, ack plh
# [03:07] * Zakim sees no one on the speaker queue
# [03:07] <ChrisL> (tab not here. we look at our shoes)
# [03:08] <ChrisL> dino: apple seems to be in the minority here. its not window.devicepixelratio
# [03:08] <ChrisL> ... hixie wants to add it to html
# [03:08] <ChrisL> ... mozilla changes it based on full zooming
# [03:09] <ChrisL> 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
# [03:09] <ChrisL> Rossen_: we have the exact same behaviour
# [03:09] <ChrisL> dbaron: so this should be reflected in the media query
# [03:10] <ChrisL> dbaron: pinch zoom means having two viewports, logical viewport scrolls intoa real viewport
# [03:10] <ChrisL> dino: authors want to know those values too
# [03:10] <ChrisL> dbaron: for compat the media queries need to be lkogical viewport
# [03:11] <ChrisL> dino: intended a fixed value of device pixels:css pixcels so it is always 1 or 2 on apple devices
# [03:11] <ChrisL> ... live ratio is a different thinhg
# [03:11] <ChrisL> SimonSapin: is this acessible from javascript or mq?
# [03:12] <ChrisL> dino: both, with same value
# [03:12] <ChrisL> Rossen_: so you account for dpi into dpr?
# [03:12] * dbaron wonders when we'll bikeshed it into bicycle-gear-ratio
# [03:12] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:12] * Joins: ChrisL (clilley@public.cloak)
# [03:12] <ChrisL> dino: : no, always 2 or 1 regardless of zoom#
# [03:13] <ChrisL> Rossen_: we persist high dpi, same as user zoom, (user can change dpi)
# [03:13] <ChrisL> ... anything to do with device adapatation
# [03:14] <ChrisL> .. like text size adjust
# [03:14] <ChrisL> israelh: static vs dynamic
# [03:15] <ChrisL> 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
# [03:15] <ChrisL> israelh: also a proposal to add a second api
# [03:15] <ChrisL> dino: difficult to change now, would break content
# [03:16] <ChrisL> (missed)
# [03:17] <ChrisL> Bert: what is the value for print
# [03:17] <ChrisL> dino: 1. hmm. not sure
# [03:17] <ChrisL> ChrisL: so its a retina y/n value
# [03:17] <ChrisL> dino: yes
# [03:17] <ChrisL> plinss: gecko and ie show the actual ratio
# [03:17] <ChrisL> dbaron: yes its a float
# [03:19] <ChrisL> dino: would like to see something new that gives you all this info: actiual display pixels, page (user) zoom, viewport within that
# [03:19] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [03:19] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:19] * Joins: ChrisL (clilley@public.cloak)
# [03:20] <ChrisL> dino: can't replace a lores with a hires image for example
# [03:20] <ChrisL> ChrisL: relayout and replacement of assests are different
# [03:21] <ChrisL> Rossen_: currently for us its just a transform, no impact on layout
# [03:21] <ChrisL> plinss: if you have an image source that has multiople respolutions it should respond
# [03:22] <ChrisL> heycam: what about mapping where you want new layers to come in diring a gesture
# [03:22] <ChrisL> dbaron: a mapping app is not using the browser zoom
# [03:23] <ChrisL> dino: people add event listeners to detect pinch zoom
# [03:23] <ChrisL> dino: want ui to be fixed size
# [03:23] <ChrisL> sgalinea_: can zoom a sub frame
# [03:24] <ChrisL> dbaron: we cant do different levels of detailautomatically as they zoom in
# [03:24] <sgalinea_> IE10+ allows the author to say a sub-frame can be pinch-zoomed independently from the host page
# [03:25] <ChrisL> heycam: proposed a way to do this in tokyo, response to kddi tiling but using media queries
# [03:26] <ChrisL> ... hard if pinch to zoom not exposed to media queries
# [03:26] <ChrisL> Rossen_: we have two different types of zoom to address, one is static and persists actoss sessions and the other is dynamic
# [03:27] <dbaron> dbaron (above): Would like to expose API for pinch zoom to the Web platform
# [03:27] <ChrisL> ... original discussion was around th static one. so can we settle that one first?
# [03:27] <ChrisL> dino: prefer what we come up with is a new solution wth new names so old content does not break. better to design together
# [03:27] <ChrisL> Rossen_: so deprecate dpr and make up two new things
# [03:28] <ChrisL> israelh: suppose you have a device that is 1.5 but user setting is 1.25
# [03:28] * Joins: jeff (jeff@public.cloak)
# [03:29] <ChrisL> ChrisL: deprecating in favour of a richer solution is the only clear way to interop
# [03:29] <ChrisL> dino: and the new api has more fiunctionality so iy will get used
# [03:29] <ChrisL> dbaron: write a specdefining these terms
# [03:30] <ChrisL> dino ted will do it
# [03:31] <dbaron> Rossen: I'll volunteer Matt Rakow.
# [03:31] <dino> ted == hober == Edward O'Connor
# [03:31] <dbaron> krit: is it part of MQ?
# [03:31] <ChrisL> Rossen_: sounds like a new proposal
# [03:31] <dbaron> sylvain: or the device adaptation document?
# [03:32] <ChrisL> SimonSapin: are these all media queries?
# [03:32] <ChrisL> dino: also properties on window
# [03:33] <ChrisL> ... and if media query values change its good
# [03:34] <ChrisL> plinss: device adaptation module covers similar ground, coordinate
# [03:35] <ChrisL> action: hober and matt to write a proposed resolution to resolve the proposal about device resolution (using unambiguous terms)
# [03:35] * trackbot is creating a new ACTION.
# [03:35] * RRSAgent records action 4
# [03:35] <trackbot> 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].
# [03:36] <ChrisL> plinss: we have this spead over several documents
# [03:36] <ChrisL> Rossen_: could consolidate them all
# [03:36] <dauwhe_> s/spead/spread/
# [03:37] <ChrisL> israelh: will this define the final overall zoom?
# [03:37] <ChrisL> Rossen_: yes
# [03:37] <ChrisL> plinss: define which is exposed to mq, when they update and so on
# [03:38] <ChrisL> Rossen_: and we need a backwards compat way to map old stuff to new properties
# [03:41] <ChrisL> dbaron: willing to make changes
# [03:41] <dbaron> (more likely to be willing to not-change-with-zoom than to use only 1.0 and 2.0)
# [03:41] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [03:41] * Joins: koji (~koji@public.cloak)
# [03:42] * heycam is now known as heycam|away
# [03:45] * Quits: israelh (~israelh@public.cloak) (Ping timeout: 180 seconds)
# [03:47] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [03:48] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:52] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:52] * leaverou is now known as leaverou_away
# [03:53] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [03:53] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:59] * Quits: jeff (jeff@public.cloak) (Ping timeout: 180 seconds)
# [04:00] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [04:02] * Joins: zcorpan (~zcorpan@public.cloak)
# [04:04] * Joins: xiaoqian (xiaoqian@public.cloak)
# [04:04] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:05] * Joins: ChrisL (clilley@public.cloak)
# [04:07] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [04:07] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:07] * Joins: ChrisL (clilley@public.cloak)
# [04:09] <fantasai> ScribeNick: fantasai
# [04:09] <fantasai> Topic: Shapes Syntax
# [04:10] * heycam|away is now known as heycam
# [04:10] <astearns> http://lists.w3.org/Archives/Public/www-style/2013Oct/0695.html
# [04:10] * leaverou_away is now known as leaverou
# [04:10] * Joins: israelh (~israelh@public.cloak)
# [04:10] * Joins: Rossen_ (~Rossen@public.cloak)
# [04:11] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [04:12] <fantasai> Alan: Issue is shapes draft has set of shapes functions that are derived from how shapes are defined in SVG
# [04:12] <fantasai> astearns: They have arguments of position and extent
# [04:12] <fantasai> astearns: fantasai pointed out that we have similar aruments in CSS, e.g. in gradients
# [04:12] <fantasai> astearns: In such syntax extent is before positioning, and all arguments are optional
# [04:13] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [04:13] <dbaron> 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
# [04:13] <fantasai> astearns: The main difference is that SVG shapes and CSS shapes is that percentages in the position are handled differently
# [04:13] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:13] * Joins: ChrisL (clilley@public.cloak)
# [04:13] <fantasai> astearns: My proposal is to keep the shapes syntax in the draft now, and in L2 create CSSy shape function
# [04:13] <fantasai> astearns: that would use radial-gradient syntax
# [04:13] <ChrisL> q+
# [04:13] * Zakim sees ChrisL on the speaker queue
# [04:14] <fantasai> 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
# [04:14] <fantasai> astearns: and she's objecting to that duplication
# [04:14] * Joins: yamamoto (~yamamoto@public.cloak)
# [04:15] <fantasai> astearns: We're at a standstill: understand each others positions, but disagree on conclusions
# [04:15] <astearns> rectangle (x y w h)
# [04:16] <astearns> shape (rectangle w h <new-position>)
# [04:16] <dbaron> was it this email: http://lists.w3.org/Archives/Public/www-style/2013Oct/0734.html ?
# [04:16] <fantasai> chrisl: We changed a lot of syntax in CSS gradients
# [04:16] <fantasai> chrisl: SVG has been around a lot longer
# [04:16] <plinss> ack ChrisL
# [04:16] * Zakim sees no one on the speaker queue
# [04:17] <fantasai> ChrisL: Better to have that
# [04:17] <fantasai> ChrisL: because it's consistent with expectations
# [04:17] <fantasai> sylvaing: Shape functions also used in clip-path in SVG
# [04:17] <dbaron> or this email: http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html ?
# [04:17] <fantasai> sylvaing: so consistency with SVG might make sense
# [04:17] <fantasai> sylvaing: But working with HTML+CSS ...
# [04:18] <fantasai> Rossen: Initial motivation for adding shapes was so that we could have syntax close to SVG as possible
# [04:18] <fantasai> Rossen: even an ask of why even have CSS inline function, instead of referencing SVG
# [04:18] <fantasai> rossen: Plan to have this in L2, actually
# [04:18] <fantasai> Rossen: But having basic shapes close to SVG is the right way to go
# [04:18] <fantasai> shepazu: Canvas differed from SVG in subtle ways, and ppl didn't like that
# [04:19] <dbaron> 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.
# [04:19] <fantasai> fantasai: We've had shapes in CSS in gradients, and positioning syntax in CSS since CSs1
# [04:19] * Joins: plh (plehegar@public.cloak)
# [04:20] <dauwhe_> s/CSs1/CSS1/
# [04:20] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html was the email fantasai meant
# [04:20] <fantasai> fantasai: my point in that email was that we have this desire for consistency
# [04:20] <dbaron> fantasai: we have desire for consistency, you can argue for consistency in either in either direction
# [04:21] <dbaron> Alan: I'd propose adding the CSS-consistent forms in level 2; I want both.
# [04:21] <dbaron> fantasai: I'd object to the duplication.
# [04:21] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [04:22] <dbaron> fantasai: But for level 1 you'd have the inconsistency with CSS.
# [04:22] <fantasai> Alan: But we have circles and ellipses in gradients, but we don't have rectangles
# [04:22] <dbaron> Alan: We'd still need to define the extrapolation from background-position syntax to rectangles.
# [04:23] <fantasai> fantasai: My point in this email is that we're arguing over consistency, and you can argue in various directions
# [04:23] <fantasai> [interrupted by ChrisL]
# [04:23] <fantasai> chrisL: SVG has been aroun longer
# [04:23] <fantasai> chrisl: So we should be consistent with it
# [04:23] <dauwhe_> s/aroun/around/
# [04:23] <dbaron> dbaron: I think there are still a lot more people hand-writing CSS than handl-writing SVG.
# [04:24] <dauwhe_> s/handl-writing/hand-writing/
# [04:25] <dbaron> fantasai: There are lots of ways to argue about consistency. Why don't we discuss use-cases instead?
# [04:25] <fantasai> Alan: Percentage handling is different, so I want to have both syntaxes so that we can have both ways of handling percentages.
# [04:25] <dbaron> fantasai: I think this syntax is not an obvious way to express that the only functional difference is how % are handled.
# [04:26] <dbaron> krit: not the only difference
# [04:26] <fantasai> fantasai: But you wanted examples, lets put up examples
# [04:26] <fantasai> fantasai: We should look at what people actually want to do with these functions
# [04:27] <dbaron> fantasai: [goes to whiteboard]
# [04:27] <dbaron> fantasai: We're trying to do positioning, that's what the main difference.
# [04:28] * Joins: yamamoto (~yamamoto@public.cloak)
# [04:28] <dbaron> fantasai: so where do people want to position things?
# [04:28] <dbaron> fantasai: Common things are: align to the center or one of corners, or one of edges.
# [04:28] <dbaron> ChrisL: [inaudible]
# [04:28] <dbaron> ChrisL: I disagree those are the most likely
# [04:28] <dbaron> Alan: also might want to position top-left corner at a particular % width and height
# [04:29] <dbaron> fantasai: Isn't bottom-right equally likely?
# [04:29] <dbaron> Alan: no, top left is positioned most often
# [04:29] <dbaron> Bert: can we take one more step back about use cases -- talking about rectangles only?
# [04:29] <dbaron> fantasai: we have circle ellipse rectangle. Gradients and SVG are both consistent that circles are positioned by center and radius.
# [04:29] <dbaron> 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
# [04:30] <dbaron> krit: can have rounded corners
# [04:30] <dbaron> fantasai: shouldn't there be an easier way
# [04:30] <dbaron> ?
# [04:30] <dbaron> peterl: follow rounded corners of border?
# [04:30] <dbaron> 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.
# [04:31] <dbaron> Alan: if wrapping around drop cap with upright ascender at trailing edge, might want a rect that approximates glyph
# [04:31] <dbaron> doug: can I ask a followup?
# [04:31] <dbaron> doug: Let's grant that these are the most likely positions -- then what's your conclusion based on that?
# [04:31] <dbaron> fantasai: Common things should be simple and easy, and other things should be possible
# [04:31] <dbaron> fantasai: Common cases should be really easy.
# [04:31] <dbaron> doug: where does it differ from SVG?
# [04:32] <dbaron> Chris: SVG positions by top left. This does percentage matching like background position so you can easily get to all 4 corners.
# [04:32] <dbaron> doug: so the percentages is the difference?
# [04:32] <dbaron> 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)
# [04:33] <dbaron> fantasai: This is duplication.
# [04:33] <dbaron> fantasai: rectangle(n, m, calc(100% - n), calc(100% ' m)
# [04:33] <dbaron> fantasai: great for people who like coordinate systems, but not great for a lot of designerns
# [04:34] <dbaron> doug: as somebody who's written SVG, inability to position something at bottom or right has hampered
# [04:34] <dbaron> Present+ Doug Schepers
# [04:34] <dbaron> fantasai: alternative is rectangle(n, m at bottom right)
# [04:34] <dbaron> doug: only difference is what % means
# [04:34] <dbaron> fantasai: that's where they're incompatible
# [04:35] <dbaron> fantasai: could put positioning syntax in svg style function too, but that would mean % interpreted differently in rectangle() and backgorurdn-position
# [04:35] <dbaron> 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)
# [04:35] <dbaron> fantasai: instead of having 2 lengths we could have it be a position that takes 2 or 4 values
# [04:35] <dbaron> fantasai: so it would be rectangle(bottom right n m)
# [04:36] <dbaron> Alan: we'd have to switch it around so that ...
# [04:36] <dbaron> krit, fantasai: don't have to
# [04:36] <dbaron> fantasai: we could restrict it so ...
# [04:36] <dbaron> Alan: then you're introducing an inconsistency with background-positioning
# [04:36] <dbaron> krit: how would rounded corners fit in
# [04:36] <dbaron> fantasai: just as now
# [04:36] <dbaron> in draft
# [04:37] <dbaron> doug: so you suggest putting css syntax of finto another draft
# [04:37] <dbaron> 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.
# [04:37] <dbaron> doug: matter of when somebody learns something and when in browser
# [04:38] <dbaron> doug: I think having both in 1st draft would be not big impl burden and help developers
# [04:38] <dbaron> alan: I've been trying to reduce level 1 draft to improve chance of additional implementations
# [04:38] <dbaron> doug: I think the extra syntax isn't a big deal.
# [04:38] <dbaron> krit: fantasai, you wanted to limit position to what again?
# [04:38] <dbaron> fantasai: ... ... can't do 3 arguments, 2 or 4 would be possible
# [04:39] <dbaron> fantasai: but then # of arguments inconsistent with background-position
# [04:39] <dbaron> Alan: I think ... defaults ... is a valuable thing to maintain.
# [04:39] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:39] * Joins: ChrisL (clilley@public.cloak)
# [04:39] <fantasai> fantasai^: in addition to percentage difference
# [04:39] <dbaron> Alan^: ability to drop things and have defaults is nice
# [04:40] <dbaron> 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
# [04:40] <dbaron> peterl: should be almost copy-paste
# [04:40] <dbaron> 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
# [04:40] <dbaron> peterl: Does it get you ability to override part?
# [04:40] <dbaron> Alan: Can choose opacity threshold.
# [04:40] <dbaron> doug: any way to leverage variables for this?
# [04:41] <dbaron> sylvain: depending on variables maybe not great for quick impl
# [04:41] <dbaron> fantasai: you said use case of matching border even if curved -- I think that should be a keyword and should be in level 1
# [04:41] <dbaron> alan: I think the value in that case should be some self-referentiial element function
# [04:41] <dbaron> doug: also use clipping?
# [04:41] <dbaron> alan: no (?)
# [04:42] <dbaron> fantasai: Bert had a proposal for floats(?) to use contour keyword
# [04:42] <dbaron> fantasai: wouldn't it make sense to add that kw right here?
# [04:42] <dbaron> 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
# [04:42] <dbaron> alan: my reasoning for using element() is that element() has same security implications so solution for addressing those implication gets reused
# [04:43] <dbaron> krit: element() can't reference itself
# [04:43] * Joins: jeff (jeff@public.cloak)
# [04:43] <dbaron> 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
# [04:43] <dbaron> alan: there are other uses of self-referential element function such as mirror images that have been discussed
# [04:43] <dbaron> 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
# [04:44] <dbaron> ... one of most common things along with following image threshold
# [04:44] <dbaron> ... don't think it should be hard to duplicate arguments already given to border-radius
# [04:44] <dbaron> 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
# [04:44] <dbaron> alan: I think images are more common use case than rendered content wrapping
# [04:45] <dbaron> 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
# [04:45] <dbaron> s/than/then/
# [04:45] <dbaron> doug: I didn't see inherent conflict between SVG and CSS syntax
# [04:45] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:45] <dbaron> doug: I think we should have both
# [04:45] * Joins: ChrisL (clilley@public.cloak)
# [04:45] <dbaron> krit: rectangle() can easily have one or other but not both?
# [04:46] <dbaron> alan: no, proposal is for it to have both
# [04:46] <dbaron> fantasai: proposal is:
# [04:46] <fantasai> shape(circle <size> at <position>)
# [04:46] <fantasai> shape(rectangle <size> at <position>)
# [04:46] <fantasai> circle(x y <size>)
# [04:47] <fantasai> rectangle(x y <size>)
# [04:47] <dbaron> fantasai: Alan's propsoal is to have all of these
# [04:47] <dbaron> fantasai: author would have to know that #2 and #4 have slightly different behavior
# [04:47] <dbaron> (and #1 and #3)
# [04:48] <dbaron> er, strike last line
# [04:48] <dbaron> fantasai: #1 and #3 are just different syntax
# [04:48] <dbaron> Rossen: ... we wanted to have shape keyword reserved so you can express outside shape and inside shape
# [04:48] <dbaron> Alan: never used shape shorthand, just wanted ...
# [04:48] <dbaron> Rossen: we had a version with shape shorthand that captured both outside and inside
# [04:49] <dbaron> Rossen: then you'd have nested functions: shape( outside(shape), inside(shape))
# [04:49] <dbaron> Alan: you'd end up with shape: <function> <function> where one is outside and one is inside
# [04:49] <dbaron> (my syntax on rossen line was wrong)
# [04:50] <dbaron> Rossen: ...
# [04:50] <dbaron> Alan: that doesn't follow shorthand conventions
# [04:50] <dbaron> fantasai: shorthand should just be shape: <shape>{1,2}
# [04:50] <dbaron> fantasai: order controls outside vs. inside
# [04:50] <dbaron> peterl: I think that's a red herring; this is the issue on the table.
# [04:51] <dbaron> fantasai: bothers me: (1) inconsistency and duplication (2) switching shapes from circle to ellipse to rectangle is totally different
# [04:51] <dbaron> fantasai: (3) there's only one functional difference between the 2 which is percentages, which is not clear from difference in syntax
# [04:51] <dbaron> fantasai: so as an author you have to know there's a weird difference between them
# [04:52] <dbaron> doug: nothing about CSS is intuitive
# [04:52] <dbaron> fantasai: but we have to try to have conventions
# [04:52] <dbaron> fantasai: this difference is not evident at all
# [04:52] <dbaron> krit: back to interpretation: with rect having w/h of 50% and position 50%, would it now be centered?
# [04:52] <ChrisL> http://xkcd.com/927/
# [04:52] <dbaron> fantasai: yes
# [04:52] <dbaron> krit: ... would ... ?
# [04:52] * Quits: sgalinea_ (~sgalineau@public.cloak) (Client closed connection)
# [04:53] <dbaron> fantasai: inset(50% 50% 0 0), or use calc()
# [04:53] <dbaron> krit and fantasai argue about what's intuitive
# [04:54] <dbaron> peterl: Is the SVG percentage behavior something that's useful?
# [04:54] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:54] * Joins: ChrisL (clilley@public.cloak)
# [04:54] <dbaron> peterl: Does the SVG behavior make sense for someone writing CSS?
# [04:54] <dbaron> Alan: fantasai ... for ... you said just use calc(), which was your objection
# [04:55] <dbaron> fantasai: my objection was having to use calc() to put something in a corner... why are we so fixated on the top left corner?
# [04:55] <dbaron> Alan: people had differing opinions
# [04:55] <dbaron> Alan: some people like each, so I want to have both
# [04:55] <dbaron> Alan: I don't think people are going to be confused about which they need to use for this purpose or that
# [04:56] <dbaron> Alan: they'll have a preference for x,y,w,h or CSS positioning syntax depending on which they grew up with
# [04:56] <dbaron> Alan: people won't be making a hard decision about ...
# [04:56] <dbaron> Bert: in order to have preference they have to understand both
# [04:56] <dbaron> krit: for radial gradient and circle define center point
# [04:56] <dbaron> krit: so my problem is you can't really compare to radial gradient this way
# [04:57] <dbaron> krit: so ??? I'd even be with you to use position
# [04:57] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [04:57] <dbaron> Lea: I think most author won't have hand-coded SVG... they'll just wonder why we have 2 functions for the same thing, slightly differently.
# [04:57] <dbaron> Rossen: with tiny difference in behavior
# [04:57] <dbaron> Lea: the only people who want this are those who have hand-coded SVG, but I think these people are rare (though I have)
# [04:57] <dbaron> peterl: you said this would be used in SVG also
# [04:58] <dbaron> krit: shape... is the future, currently only clip-path in sVG that uses basic shapes
# [04:58] <dbaron> krit: what about 'middle' or 'center' keyword -- and keywords go to corner, but %ages in SVG way
# [04:58] <dbaron> alan: good reasons for %ages to work CSS way, esp. around animations
# [04:58] <dbaron> alan: I like both; I can't come up with one single syntax that does everything.
# [04:58] <dbaron> peterl: have a keyword in the function to pick percentage behavior and then pick one to default on?
# [04:59] <dbaron> doug: the 2 positions I hear are (a) have both (b) only have one because people would be confused by two
# [04:59] * Quits: jeff (jeff@public.cloak) ("Leaving")
# [04:59] <dbaron> fantasai: I think a lot would be confused
# [04:59] <dbaron> doug: can we have one be default but still allow other?
# [05:00] <dbaron> doug: Can we have no way to have CSS as default and SVG syntax be an option
# [05:00] <fantasai> dbaron: If we're doing something like that, then I prefer Peter's idea of having a specific obvious toggle rather than haveing two totally different syntaes that have a slight difference of interpretation
# [05:00] <dbaron> doug: ...
# [05:00] <dbaron> Simon: should toggle be available for shape, or also background-position?
# [05:01] <dbaron> (I'm not convinced ew should have the toggle, though.)
# [05:01] <dbaron> ...
# [05:01] <dbaron> fantasai: we don't have to pick "svg-like" as the keyword
# [05:02] <dbaron> fantasai: one thing I came up with on list was say which corner you want to position: <corner> at <position>, e.g., top left at 50% 50%
# [05:02] <dbaron> Alan: what would default CSS value of corner thing be?
# [05:02] <dbaron> fantasai: if omitted, then the magic thing
# [05:03] <dbaron> krit: I'd like to get an agreement on the syntax during TPAC... we have 2 specs in/near LC.
# [05:03] <dbaron> ChrisL: with gradient syntax, would have been better to agree on *any* of the proposals a year earlier
# [05:03] <dbaron> krit: we should remove rectangle() and inset-rect() for now
# [05:03] <dbaron> fantasai: I don'tthink we need to remove inset-rect()
# [05:04] <dbaron> krit: I don't think rectangle is that importnt at this point... can easily do it with polygon() or inset-rect()
# [05:04] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [05:04] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [05:04] <dbaron> peterl: We need to wrap up or come back after lunch?
# [05:04] * Joins: ChrisL (clilley@public.cloak)
# [05:05] <dbaron> fantasai: Krit's proposal: L1: circle ellipse inset polygon L2: rectangle
# [05:05] <dbaron> fantasai: I'd also suggest having a way to get the border-box shape.
# [05:05] <dbaron> alan: separate issue
# [05:06] <dbaron> fantasai: haven't decided internal syntax yet -- deciding what goes in these functions is a separate issue
# [05:06] <dbaron> fantasai: "copy border shape" is also separate issue
# [05:06] <dbaron> Alan: so moving rectangle() to level to to avoid incompatibility with percentage
# [05:06] <dbaron> krit: and gives more time to argue
# [05:07] <dbaron> RESOLVED: rectangle() moves to level 2 of shapes
# [05:07] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [05:07] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [05:07] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [05:07] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [05:08] * Joins: zcorpan (~zcorpan@public.cloak)
# [05:08] * heycam is now known as heycam|away
# [05:10] * Quits: cabanier1 (~cabanier@public.cloak) ("Leaving.")
# [05:12] * Quits: xiaoqian (xiaoqian@public.cloak) (Ping timeout: 180 seconds)
# [05:14] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [05:14] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [05:14] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [05:15] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [05:15] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [05:16] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [05:17] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [05:18] * leaverou is now known as leaverou_away
# [06:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:12] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [06:12] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [06:13] * heycam|away is now known as heycam
# [06:15] * Joins: projector (~projector@public.cloak)
# [06:15] * plinss changes topic to 'http://wiki.csswg.org/planning/tpac-2013#agenda'
# [06:16] * Joins: xiaoqian (xiaoqian@public.cloak)
# [06:16] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:17] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [06:17] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [06:21] * Joins: cabanier (~cabanier@public.cloak)
# [06:24] * leaverou_away is now known as leaverou
# [06:25] * Joins: leif (~lastorset@public.cloak)
# [06:27] * Joins: Israelh (~Israelh@public.cloak)
# [06:29] * Joins: Rossen_ (~Rossen@public.cloak)
# [06:30] * Joins: liam (liam@public.cloak)
# [06:30] <liam> scribe: liam
# [06:30] <liam> scribenick: liam
# [06:30] * Joins: yamamoto (~yamamoto@public.cloak)
# [06:30] * Joins: dbaron (~dbaron@public.cloak)
# [06:31] <astearns> summary - keep inset() and polygon() as they are in the editor's draft
# [06:31] <astearns> change circle() and ellipse() to use radial gradient syntax
# [06:32] <astearns> and postpone rectangle() until we can define it in a way that satisfies everyone
# [06:32] * liam thanks
# [06:32] <liam> resolved.
# [06:32] <fantasai> RESOLVED: per astearn's summary
# [06:33] <liam> fantasai: next issue, following contour of the border
# [06:33] <liam> alan: I mean the contour of the rendered element
# [06:33] <liam> rik: couple of things here...
# [06:33] <liam> which box you use for the shape, e.g. the amrgin box works for float but maybe not for exclusions
# [06:34] <liam> so the auto shape is where we can have the border/margin/content box and snap to that shape
# [06:34] <liam> (for wrapping around)
# [06:34] <liam> alan: that's not the border box, e.g. because the border can have rounded corners
# [06:34] <plinss> s/rik/rossen/
# [06:34] * liam tx
# [06:34] <liam> so rendered contents, rendered border, not same as box
# [06:35] <liam> Simon: would this be the border edge?
# [06:35] <liam> alan: yes, but different edge for inside/outside
# [06:35] <liam> rik: is it necessary for level one?
# [06:35] <liam> alan: no :)
# [06:35] <plinss> s/rik:/dirk:/
# [06:36] <liam> dirk: are we fine with pushing this to level 2?
# [06:36] <liam> fantasai: I understand there are security issues, but for the simple case of saying just use rounded corner...
# [06:36] <liam> alan: it's not so simple as yu can turn parts of the border off
# [06:37] <liam> alan: e.g. if you turn off parts of the border to make a triangle, do you wrap around the triangle or around the partly-visible border?
# [06:37] <liam> whats the user expectation?
# [06:37] <liam> fantasai: if you put i nbackground color, you get the whole box, so that's the expectation
# [06:38] <liam> alan: I agree that's defined and that people who understand css backgrounds would have that expectation
# [06:38] <dauwhe_> s/i nbackground/in background/
# [06:38] <liam> rossen: instead of saying border box vs border edge, say border edge and specify as border, edge or padding
# [06:39] <liam> dirk: implementation-wise it's not that easy
# [06:39] <liam> fantasai: if it's considered as one of the most common cases it should be in level 1
# [06:39] <liam> rossen: also for exclusions the default area is the border box, and this is not what we have in shapes, there we take margin
# [06:39] <liam> alan: flr floats it makes sense to use margin box
# [06:40] <liam> rossen: I want to have shapes working with level 1 of exclusions
# [06:40] * Joins: ChrisL (clilley@public.cloak)
# [06:40] <liam> and the one place where there is quiet a bit of inconsistency is the auto behaviour of the shape, specifying it to be the margin box
# [06:40] * Joins: kawabata2 (~kawabata@public.cloak)
# [06:41] <liam> [further discussion of margin vs border box in different cases]
# [06:41] <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2631 is basically the case we're discussing, right?
# [06:41] <liam> lea: a box shadow also affects the border even if the border isn't shown
# [06:42] <liam> fantasai: you're saying, should we account for the visibility of the border, and I'd say no
# [06:42] <liam> liam: if you want a triangular element yuo can use a polygon instead of turning off part of the border
# [06:43] <liam> alan: this is an argument to defer something
# [06:43] * liam didn't catch the something
# [06:43] <liam> fantasai: it'd e good for us to say in level 1, just use the edge as defined in backgrounds & borders
# [06:44] <liam> Lea: I can see use cases for what Alan was saying, but what Ellika is saying will work in most cases
# [06:44] <liam> fantasai: because people expect that to "just work" it should be dead simple
# [06:44] <liam> so we should have a straight-forward way to do that
# [06:44] <liam> [draws on the flip-board a list:]
# [06:45] <liam> * use margin box (square corners)
# [06:45] <liam> * follow margin edge contour
# [06:45] <liam> * follow border edge contour
# [06:45] <liam> * follow content edge contour
# [06:45] <liam> * use border rectangle
# [06:45] <liam> * use content rectangle
# [06:45] <leif> s/defer something/defer following contour/
# [06:45] <liam> e.g. shape-outside: normal|countour|...
# [06:45] * liam thanks!
# [06:46] * liam very jetlagged today, probably lots of others are too :-)
# [06:46] <liam> fantasai: we can also add the various box names, contour||<box>....
# [06:47] <liam> x: one thing people use border radius triangles for is to make speech bubbles
# [06:47] <liam> alan: that's where you have polygons
# [06:47] <leif> s/x/zcorpan/
# [06:47] <liam> rossen: things that should be automatic should be intuitive and easy to understand ...
# [06:47] <liam> if you want to have fancy shapes you can make them with an image or polygon
# [06:47] * leif it always takes a village to write the minutes ;)
# [06:48] <liam> alan: so the proposal is for level one to add one keyword that means follow the edge of the border
# [06:48] <liam> having the shape defined at the border edge would be a better solution
# [06:48] <liam> setting margin and border shape separately is useful for floats
# [06:50] <liam> fantasai: the fallback margin is going to be in many case dramatically different from the actual border, that concerns me a bit
# [06:50] <liam> rossen: if you talk about shape margin being different from margin box, shape is additional to that
# [06:51] <liam> and for the fallback case where yu use the margin box of the box model of the float, it'll almost always be different because you don't have a shape
# [06:51] <liam> alan: in default shape is auto, you wrap around the margin box so fallback is same
# [06:51] <liam> but if you use border keyword yuo can set a separate shape-outside shape
# [06:52] <dauwhe_> s/yuo/you/
# [06:52] <liam> fantasai: what if the values for shape-outside, default was to use the border box
# [06:52] * liam thanks
# [06:52] <liam> so, shape:margin: auto, would use the border box
# [06:53] <liam> alan: we want that for the float case but not the exclusion case
# [06:53] <liam> fantasai: intent of margins is to provide visual space, we're using it here for positioning
# [06:54] <liam> [discussion between Alan and Rossen]
# [06:54] <liam> alan: want to keep shape-margin zero by default
# [06:55] <liam> bert: idea here was a single property would be enough
# [06:55] <liam> alan: only need 2nd property if yuo want to wrap around the rounded box or shape
# [06:56] <liam> [clarification: -ve margins used for positioning when stacking multiple floats]
# [06:56] <liam> rossen: if we leave margin as default, for the auto, and allow the border kw, then the default just work, as it's margin box, same as floats today
# [06:57] <liam> allowing border box will give users what we speculate to be the most useful case
# [06:57] <liam> alan: that's your analysis
# [06:58] * Joins: jet (~junglecode@public.cloak)
# [06:58] <liam> bert: by default i want to wrap around the shapes margin box
# [06:58] <liam> not directly the border
# [06:58] * Joins: leif1 (~lastorset@public.cloak)
# [06:59] <liam> Liam: the case where you want a separate margin shape and border shape is really for complex shapes with concave regions, which is not the case with a box with rounded corners.
# [07:01] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [07:01] <liam> alan: shape-margin is one value, you were talking abut having shape-margin: auto, to take the shape's margin
# [07:01] <dauwhe_> s/abut/about/
# [07:01] <liam> [question about backgrounds & borders spec anwered]
# [07:02] <liam> alan: this is more complex than what we have in shapes
# [07:02] <liam> rossen: if you're supporting polygons yu already do this
# [07:02] <dauwhe_> s/anwered/answered/
# [07:02] <liam> alan: since we only support one shape I would not want this more complex behaviour that you can't define
# [07:03] <liam> for polygons
# [07:03] <liam> alan: would prefer allow border keyword, keep shape margin as it is
# [07:04] * leif1 is now known as leif
# [07:04] <liam> yuo could get a single offset from the border edge
# [07:05] <liam> fantasai: cases where you want more space in horizontal than vertical direction for floats
# [07:05] * Joins: lmclister (~lmclister@public.cloak)
# [07:06] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [07:06] <liam> [bert draws a picture comparing border-shape and margin-top
# [07:07] <liam> [picture was for question of clarification, answered]
# [07:08] <liam> fantasai: related issue, what does 100% mean?
# [07:08] <liam> I think we use box sizing for this
# [07:08] <liam> but box sizing should just be about height and width
# [07:08] <liam> I don't think 100% should be tied to box sizing
# [07:09] <liam> alan: we tie 100% to the height or width, that's why we use box sizing
# [07:09] <liam> fantasai: but percentages aren't referencing height and width, 100% for the shape isn't the same as 100% for the width, they don't need to correspond
# [07:09] <liam> box sizing by default is the content box,
# [07:10] <liam> if I'm defining shapes for the border I'd want 100% to refer to the border box at least
# [07:10] <liam> shape-margin should always be referencing the same box
# [07:10] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:10] <liam> dbaron: ox sizing using one property to control the meaning of another is bad enough already!
# [07:10] <liam> alan: I pressed to have percentages based on different boxes
# [07:11] <liam> dbaron: I think box sizing would be be better e.g. box: 100% of content box
# [07:11] * liam didn't capture that well
# [07:11] <liam> bert: when do you need 100%?
# [07:11] <dbaron> box-sizing would have better been an additional keyword on the value of 'width' and 'height', e.g., 'width: 100% border-box'
# [07:12] <liam> fantasai: e.g. a triangle goes from top to bottom of the triangle, if you know the height, so it goes to 100% of the hright
# [07:12] * liam thanks
# [07:12] <liam> s/hright/height/
# [07:13] <liam> fantasai: i can imagine a property like background-origin to do the switching between the different boxes
# [07:13] <liam> alan: can we go back to the border keyword?
# [07:13] <liam> fantasai: it's related because if we're going to have a way to switch for sizing...
# [07:13] <liam> alan: we're talking about a keyword insetad of the shape functions
# [07:14] <liam> dirk: is it inside or outside?
# [07:14] <liam> rossen: when we get to shape-inside, level 2, we'll probably add more keywords
# [07:14] <liam> bert, fantasai, rossen, dirk: want the content edge for inside
# [07:15] <liam> dirk: why not always use margin and let user specify shape-padding
# [07:15] <liam> fantasai: don't want to duplicate lengths
# [07:16] * Joins: lmclister (~lmclister@public.cloak)
# [07:16] * Quits: jet (~junglecode@public.cloak) (jet)
# [07:16] <liam> alan: should be outer edge of border and then you add whatever margin
# [07:17] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [07:17] * Joins: ChrisL (clilley@public.cloak)
# [07:17] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [07:17] <liam> fantasai: shape-margin takes one value and margin takes 4 values
# [07:17] <liam> bert: on shape inside, you want to have the text fallow the shape corner
# [07:17] <liam> rossen: shape padding
# [07:18] <liam> bert: but the size of the box changes, e.g. a float with a rounded corner, the text inside the float
# [07:18] <liam> alan: that's an issue with any of the shapes with text inside
# [07:18] <liam> autoshaping hard problem but necessary
# [07:19] <liam> bert: I don't think it's useful to have text outside follow shape of border if you can'tdo it on the inside
# [07:20] <liam> I think outside and inside belong together, same level
# [07:20] <liam> rossen: yes
# [07:20] <liam> alan: I agree we should get to them, don't think they both have to be at the same level
# [07:21] <liam> fantasai: we have algorthims for wrapping round outside but not inside, so I think it makes sense to split into two levels
# [07:21] <liam> fantasai: you can reference an image, that gets yuo a lot of what you want
# [07:21] <liam> e.g. oval shaped edges in your facebook
# [07:21] <liam> s/edges/profile pictures/
# [07:21] * Joins: lmcliste_ (~lmclister@public.cloak)
# [07:22] <liam> alanL I need to take a look about sizing based on the border box
# [07:22] <liam> s/alanL/alan:/
# [07:22] <liam> fantasai: I'm still trying to see how to have the default for margins
# [07:23] <liam> rossen: default can still be margin-box
# [07:23] <liam> alan: issue is, when the border is curved, the outside margin edge is also curved
# [07:23] <liam> and because yuo can give 4 different margins for the element
# [07:23] <liam> the outside margin edge cannot beachieved with a singe shape margin value
# [07:23] <liam> so a suggestion is to have this auto shape-margin value to get to that shaped margin edge
# [07:24] <liam> but then how does that work with polygons?
# [07:24] <liam> I'd rather not deal with that case
# [07:25] <dauwhe_> s/beachieved/be achieved/
# [07:25] <liam> alan: want to add border keyword to shape-outside and leave shape-margin as it's currently defined
# [07:25] <fantasai> http://www.w3.org/TR/css3-background/#the-background-clip
# [07:25] <fantasai> border-box
# [07:25] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [07:29] <liam> fantasai writes values for shape-outside:
# [07:29] <liam> <box> || <shape>
# [07:29] <liam> Bert's case: shape-outide bargin-box
# [07:29] <liam> s/bargin/margin/
# [07:29] <liam> or, border-box
# [07:29] <dbaron> auto | <box> || <shape>, I think
# [07:29] <liam> or, circle(100%)
# [07:30] <dbaron> fantasai's drawing:
# [07:30] <liam> (yes, auto | <box> || <shape>, didn't see the correction)
# [07:30] <dbaron> shape-outside: margin-box
# [07:30] <dbaron> shape-outside: border-box
# [07:30] <dbaron> shape-outside: circle(100%) /* border-box */
# [07:30] <dbaron> shape-outside: margin-box circle(100%)
# [07:31] <liam> peter: shape-margin would always be an addition to whatever this produces
# [07:31] <liam> alan: except at the moment shapes are clipped to the margin box
# [07:31] * leaverou is now known as leaverou_away
# [07:31] <liam> bert: what does auto mean?
# [07:31] <dauwhe_> s/shape-outide/shape-outside/
# [07:31] <liam> fantasai: the square margin box ignoring radius, the box model
# [07:31] <liam> but for exclusions auto will be border box
# [07:32] <liam> alan: is border-box the border edge?
# [07:32] <liam> fantasai: yes, cf. clipping
# [07:32] <SimonSapin> +1 for fantasai’s proposal
# [07:34] <liam> alan: should we fix the mistake and use border-edge instead of border-box
# [07:34] <liam> simon: the inside of the border is padding-edge
# [07:34] <liam> resolution: adopt fantasai's proposal for shape-outside
# [07:35] <liam> peter; let's leave edge vs box as name as an issue for later
# [07:35] <liam> s/peter;/peter:/
# [07:35] <liam> fatasai: we should resolve that now
# [07:35] <liam> dirk: need to resolve it before going to last call
# [07:36] <liam> bet: since we have box in backgrounds and borders we should keep the same tem
# [07:36] <liam> s/tem/term/
# [07:36] <liam> resolution: keep box, not edge, in the shape keywords
# [07:37] * leaverou_away is now known as leaverou
# [07:37] <liam> s/resolution/RESOLUTION/g
# [07:37] <Rossen_> s/RESOLUTION/RESOLVED/
# [07:37] * liam ########################################### R E S O L U T I O N #############################################
# [07:38] * astearns s/issue for later/up to the editor's discretion/
# [07:38] * Joins: ChrisL (clilley@public.cloak)
# [07:38] * Joins: sgalineau (~sgalineau@public.cloak)
# [07:39] <liam> peter: done with shapes
# [07:39] <liam> dirk: when do we ask for last call?
# [07:39] <liam> alan, fantasai: after edits
# [07:39] <liam> Topic: masking level 2
# [07:39] <liam> dirk: we have css masking level 1 in last call
# [07:40] * Joins: sgalinea_ (~sgalineau@public.cloak)
# [07:40] <liam> I want to ask officially to create an editor's draft for level 2 masking
# [07:40] <liam> we deferred having different layers for masking, and some other things
# [07:40] <liam> dbaron: does the ED need a cautionary statement?
# [07:40] <liam> dirk: yes
# [07:40] <liam> it's just to collect ideas
# [07:40] <liam> fantasai: how about a wiki page instead?
# [07:40] <liam> dirk: OK
# [07:41] <liam> dirk: we already have spec text but I can make a wiki page if that's preferred
# [07:41] <liam> Chris: is there implementation impetus?
# [07:42] <liam> dirk: multiple layers are shipping in webkit
# [07:42] <liam> (prefixed)
# [07:42] <liam> dbaron: given it's shipping in webkit I'd argue for an ED at least
# [07:42] <liam> fantasai: but we want to change how it works
# [07:42] <liam> dbaron: are we able to change how it works?
# [07:42] <liam> peter: it's prefixed
# [07:43] <liam> dirk: in webkit the unprefixed versions don't have multiple layers
# [07:44] <liam> RESOLVED: dirk can make a wiki page for masking level 2 ideas, but not an ED yet.
# [07:44] <dbaron> fantasai: the issue with multiple mask layers was that there weren't different options for compositing; it was only intersection
# [07:45] <fantasai> fantasai^: Since we aren't sure we actually want the thing that was removed, probably shouldn't have a formal spec drafted up for it; just put the issues and ideas in teh wiki for now
# [07:46] <liam> [discussion of when to discuss filter effects => probably fx time on Tuesday]
# [07:46] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
# [07:46] * Joins: jet (~junglecode@public.cloak)
# [07:46] * Joins: emalasky (~Adium@public.cloak)
# [07:46] <liam> s/ teh / the /
# [07:46] <krit> http://dev.w3.org/fxtf/filters/#issue-92cd9a9b
# [07:47] <liam> dirk: we have bg, border, content, how to filter just some of these things
# [07:47] <liam> chris: ::border, ::padding ?
# [07:47] <liam> dirk: we should find a common way to specify as well as describe this effect; I'd like to remove this issue from the spec
# [07:48] <liam> dirk: there are proposals for how to make multiple layers for just one element
# [07:48] <liam> dbaron: yuo might want things more powerful than just selection
# [07:48] <liam> e.g. I was thinking of a model like SVG filter inputs model
# [07:48] <liam> where you have filter inputs for background, order and content
# [07:49] <liam> the idea of svg filter inputs with stroke & fill etc seems like it could extent to border and background
# [07:49] <liam> dark: that's a backdrop, I'd say, separate term
# [07:50] <liam> I don't think we find a solution for level 1, so I'd like to defer it to level 2 or to combine specifications
# [07:51] <liam> dirk: propsoal: filters apply to everything (except css image filter), and remove issue 3 from filters at this level without addressing the issue
# [07:53] <liam> [discussion of use cases for applying filters to different parts]
# [07:54] <liam> chris: the only thing missing is a wa to say e.g. that I only want to apply this filter to the border-image
# [07:54] <liam> fantasai: people want to do things to individual bg layers, the bg as a whole, the border by itself, the bg and border as a unit, the content and not the bg, etc
# [07:54] <liam> could we just come up with keywords for each of these things?
# [07:55] <liam> dirk: this is something yuo don't want to address just for filters, also with backdrop, and define a general way to specify it, not just add more keywords to every property
# [07:55] <liam> dirk: there is a wiki page in the fx task force about this problem
# [07:55] * Quits: jet (~junglecode@public.cloak) (jet)
# [07:57] <liam> fantasai: concerned we might be filtering ourselves into a corner for the future
# [07:57] <liam> peter: maybe we want to change the name of the filter property so that we don't get stuck, e.g. filter-all
# [08:02] * leaverou is now known as leaverou_away
# [08:03] <liam> [discussion of background-opacity]
# [08:03] <liam> RESOLVED: filters apply to everything (except css image filter), and remove issue 3 from filters at this level without addressing the issue
# [08:04] * Quits: kawabata2 (~kawabata@public.cloak) (Client closed connection)
# [08:04] <liam> Peter: can we leave the issue in place?
# [08:04] * dauwhe_ we're more resigned than resolved
# [08:04] <liam> dirk: I don't think we can find a solution to issue 3 in this spec at this level
# [08:05] * liam :)
# [08:05] <liam> Peter: OK. Anything else on filters?
# [08:05] <liam> (no)
# [08:05] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [08:05] * Joins: ChrisL (clilley@public.cloak)
# [08:05] * Joins: kawabata2 (~kawabata@public.cloak)
# [08:05] <liam> next on agenda is wd of transforms
# [08:05] <liam> dirk: can we do all fx stuff on tuesday?
# [08:05] <liam> (ok)
# [08:05] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [08:06] * Joins: ChrisL (clilley@public.cloak)
# [08:06] * leaverou_away is now known as leaverou
# [08:06] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [08:07] <liam> Topic: prefixing policy
# [08:07] <liam> fantasai: didn't we solve that already and it not get witten up?
# [08:07] <liam> Simon: I added it to the agenda
# [08:07] <liam> my understanding is to recommend prefixes
# [08:08] <dbaron> s/is to/is the working group policy is still official to/
# [08:08] <liam> others: no
# [08:08] <dbaron> fantasai: no, it hasn't been since the meeting in Paris in 2012
# [08:08] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [08:08] * Joins: ChrisL (clilley@public.cloak)
# [08:08] <liam> simon: most recent I could find is the 2010 snapshot
# [08:09] <liam> person: yes, you're right, nothing published since then
# [08:09] <liam> fantasai: it's on my todo list
# [08:09] * liam can't see who is behind me, is that sylvain? sorry, I'll grow more eyes when I can :)
# [08:09] <liam> principle, you don't release prefixed problems until CR
# [08:10] <liam> Chris: process is being changed, CCPR
# [08:10] * dauwhe_ Liam, I think so, but I'm not 100% sure
# [08:10] <liam> s/person/sylvain/
# [08:10] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0894.html
# [08:11] <liam> (Apple/webkit and IE still sticking to prefixes)
# [08:11] <liam> simon: if we had wg consensus last year, we should have tha tpublised somewhere easier to find
# [08:11] <dbaron> (simon being SimonSapin)
# [08:11] <dbaron> Simon: at least on the wiki, if not in the snapshot
# [08:12] <dauwhe_> s/tha tpublised/that published/
# [08:12] <dbaron> https://twitter.com/csswg
# [08:13] <fantasai> http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
# [08:13] <liam> peter: we don't want you to ship something unprefixed before the WG is ready
# [08:13] <liam> chris: should we still spend effort in snapshot?
# [08:14] <liam> fantasai it's a lot less useful than it was
# [08:14] <liam> dbaron: especially since it's not rec-trac
# [08:15] <SimonSapin> http://www.w3.org/blog/CSS/
# [08:16] <liam> fantasai: a large part of snapshots was to work around problems we were having in W3C process, representing features that were in browsers & stable
# [08:16] <liam> problem now is we have tons of untested features so don't know what's snapshot-ready
# [08:16] <liam> chris: either we document we're no longer doing snapshots or we fix the exisitng one
# [08:17] <liam> snapshot is currently dated 2010 and it's nearly 2014
# [08:17] <liam> fantasai: index of properties, glossary, still useful
# [08:17] <liam> so I want to see it updated
# [08:17] <liam> peter: but don't need to call it a snapshot or track [all] the specs
# [08:17] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [08:17] * Joins: ChrisL (clilley@public.cloak)
# [08:18] <liam> fantasai: goal was, this was the stuff "you can rely on as an author" to be stable enough, not rec because no tests or interop tests
# [08:18] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [08:18] * Joins: ChrisL (clilley@public.cloak)
# [08:19] <liam> peter: I'm most of the way to an infrastructure
# [08:20] <liam> shepherd is parsing most of the specs now and keeping track of definitions, properties, @-rules, values, the data is there
# [08:21] <liam> so trivial to produce list of what's in CR
# [08:22] <liam> dbaron: sounds like snapshot has prose in it that doesn't reflect or current thinking
# [08:23] <liam> chris: css snapshot should be republished with explanations updated for prefx policy, and process, and removing the indexes to point to an external index once we have one
# [08:23] <liam> peter: I can do that fairly soon
# [08:23] <fantasai> http://www.w3.org/TR/CSS/
# [08:25] <liam> fantasai: can you make an index of selectors autmatically?
# [08:25] <liam> peter: not currently, tool doesn't yet deal with them, but they could be added if we add markup to the specs
# [08:26] <dauwhe_> s/autmatically/automatically/
# [08:27] * krit first time that I ever looked at this document :P
# [08:28] <liam> ACTION: peter to work on shepherd to make it produce indexes (including selectors) for a "snapshot" or live index
# [08:28] * trackbot is creating a new ACTION.
# [08:28] * RRSAgent records action 5
# [08:28] <trackbot> Created ACTION-590 - Work on shepherd to make it produce indexes (including selectors) for a "snapshot" or live index [on Peter Linss - due 2013-11-17].
# [08:28] <liam> bert: I want a static document so people can refer to it
# [08:28] <liam> dated, e.g. once every two years
# [08:29] <liam> person: you could refer to a dated version
# [08:29] <liam> bert: people will refer to different versions
# [08:30] <liam> bert: we need longer things of stability
# [08:32] * dauwhe_ February 29 is update the spec day!
# [08:33] <liam> dirk: so let's have the shapshot separate from the index
# [08:34] <liam> fantasai: so we need an editor of the 2013 snapshot
# [08:34] <liam> peter: it could take weeks to get the tool ready
# [08:34] * dbaron hopes we don't approach C++0xa
# [08:34] * dbaron er, sorry, C++0xb
# [08:34] * fantasai volunteers SimonSapin :)
# [08:35] <liam> fantasai, prose can be updated with index as-is until later
# [08:35] * sgalinea_ that'll teach him to bring up prefixes
# [08:36] <liam> Simon will edit, with input from Ellika
# [08:36] <liam> s/Simon/RESOLVED: Simon/
# [08:37] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [08:37] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [08:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:38] <liam> [break]
# [08:39] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [08:44] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:48] * leaverou is now known as leaverou_away
# [08:57] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:02] * Joins: plh (plehegar@public.cloak)
# [09:06] * Joins: shepazu (~shepazu@public.cloak)
# [09:08] * shepazu wonders where the css wg is having dinner?
# [09:16] * Quits: shepazu (~shepazu@public.cloak) (Ping timeout: 180 seconds)
# [09:16] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [09:17] * Joins: ChrisLilley (clilley@public.cloak)
# [09:21] * Joins: zcorpan__ (~zcorpan@public.cloak)
# [09:22] * Joins: AndroUser (~androirc@public.cloak)
# [09:22] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [09:23] * AndroUser wonder s when and where the css wg is eating dinner?
# [09:23] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [09:24] * AndroUser is shepazu
# [09:24] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [09:25] * plinss AndroUser: we'll let you know as soon as we know...
# [09:27] * Joins: emalasky (~Adium@public.cloak)
# [09:28] <fantasai> ScribeNick: fantasai
# [09:28] <fantasai> Topic: CSS2.1
# [09:29] <dbaron> peterl: Who put 2.1 on the agenda?
# [09:29] <dbaron> Bert: me
# [09:29] <fantasai> Bert: Do we want to publish the editor's draft as revised edition?
# [09:30] <fantasai> Bert: Or solve more issues or what?
# [09:30] <fantasai> Bert: Heard ppl would like to have an update
# [09:30] <fantasai> Bert: Errata we decided so far, up to date except for a handful of edits
# [09:30] <fantasai> Bert: About 1 hr work
# [09:30] <fantasai> Bert: Can publish or wait?
# [09:31] <fantasai> fantasai: Do we have tests for all the errata?
# [09:31] <fantasai> Bert: Don't know
# [09:31] <fantasai> ChrisLilley: Thinks that's a requirement for PER
# [09:31] * Quits: AndroUser (~androirc@public.cloak) (Ping timeout: 180 seconds)
# [09:31] <fantasai> dbaron: Diffs?
# [09:31] <fantasai> fantasai: Errata include diffs
# [09:31] <dbaron> dbaron: I wouldn't mind a quick look at the diff-marked version.
# [09:32] <ChrisLilley> publication will also need a diff-marked version
# [09:33] <fantasai> dbaron: Think publishing is a good idea
# [09:33] <fantasai> dbaron: In addition to tests, would like week of review to see what we're publishing
# [09:33] <Bert> -> https://www.w3.org/Style/Group/css2-src/diffs-rec/ CSS 2.1 diffs
# [09:33] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [09:33] * Joins: ChrisLilley (clilley@public.cloak)
# [09:34] <ChrisLilley> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=per-tr
# [09:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:35] * Quits: zcorpan__ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [09:35] <ChrisLilley> "The request MUST Include a link to a final implementation report, or, if there is no such report, rationale why the Director should approve the request nonetheless."
# [09:36] <fantasai> ChrisL: New version def better than old one
# [09:36] <fantasai> ChrisL: But we need tests and impl report
# [09:36] <fantasai> plinss: New impl report in total, or just for the diffs?
# [09:36] <fantasai> ChrisL: Just the diffs
# [09:38] <fantasai> [silence on tests]
# [09:38] <Bert> -> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html errata for CSS 2.1
# [09:39] <dbaron> dbaron: do we have a way of gathering tests for the errata?
# [09:40] <dbaron> dbaron: peterl, can you propose a way to do that?
# [09:41] <fantasai> fantasai: Don't think we need anything special, just send a link to the test to Bert, he can add it to the errata document
# [09:41] <fantasai> ChrisL: better to have an automated system
# [09:42] <dbaron> dbaron: we'll need an impl report
# [09:42] <fantasai> dbaron: Can we add rel=help links to the errata document?
# [09:42] <dbaron> (additional rel=help links)
# [09:42] <fantasai> plinss: Yeah, can do that, just build a test suite for that
# [09:42] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [09:42] * Quits: dino (~dino@public.cloak) (dino)
# [09:42] * Joins: ChrisLilley (clilley@public.cloak)
# [09:42] <fantasai> plinss: Need to remove tests for things that have changed
# [09:42] <fantasai> fantasai: Might want to replace those tests with the new ones
# [09:43] <fantasai> dbaron: Hard to find those
# [09:43] <fantasai> Bert: Those will be tests that failed, don't have to look at tests that succeeded
# [09:44] <fantasai> Liam: Can't assume that wil work
# [09:44] <fantasai> s/wil/will/
# [09:45] <fantasai> plinss: So who is going to do this?
# [09:46] <fantasai> plinss proposes putting the errata into a hat and letting people choose one to work on
# [09:46] <fantasai> SimonSapin: I think the last one is not observable
# [09:48] * Joins: emalasky1 (~Adium@public.cloak)
# [09:48] <zcorpan> i volunteer to test this errata item: "In 11.1.1 “Overflow: the 'overflow' property,” change the definition of 'scroll' and 'auto':"
# [09:51] <fantasai> ACTION: Bert to create wiki page to list tests needed for errata, ppl can sign up to work on them
# [09:51] * trackbot is creating a new ACTION.
# [09:51] * RRSAgent records action 6
# [09:51] <trackbot> Created ACTION-591 - Create wiki page to list tests needed for errata, ppl can sign up to work on them [on Bert Bos - due 2013-11-17].
# [09:51] <SimonSapin> SimonSapin: I can do the tests related to tokenization
# [09:53] <SimonSapin> also add http://lists.w3.org/Archives/Public/www-style/2013May/0783.html
# [09:53] <SimonSapin> I can write up errata text for it
# [09:54] <SimonSapin> "Allow at-rules inside declaration blocks"
# [09:55] * Joins: glazou (~glazou@public.cloak)
# [09:55] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [09:56] * leaverou_away is now known as leaverou
# [09:57] <SimonSapin> Topic: 3-value <position> syntax
# [09:58] * glazou waves
# [09:59] <fantasai> fantasai: Idea was to create a <position> syntax that is not ambiguous to parse in cases where its mixed with other types of values
# [09:59] <fantasai> fantasai: Would have to drop 3-value and 1-value variants
# [10:00] <fantasai> fantasai: Question would be, do we want to look into this?
# [10:00] <fantasai> fantasai: And if so, where would we use it / which existing places that take <position> would we want to modify?
# [10:01] <fantasai> ...
# [10:01] <fantasai> fantasai: Hard to imagine using one-value syntax... except 'center' is probably really popular
# [10:02] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:03] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [10:03] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [10:03] <fantasai> ...
# [10:03] * Joins: ChrisLilley (clilley@public.cloak)
# [10:03] <fantasai> fantasai: Maybe not so interesting if 'center' then becomes invalid
# [10:04] <fantasai> Topic: Zero-height fragmentainers
# [10:04] * sgalinea_ is unable to take the 'fragmentainer' term seriously
# [10:04] <fantasai> Rossen: Issue raised by Alan -- what do we do with zero-height fragmentainers?
# [10:04] <fantasai> Rossen: Do we force progress somehow? Or skip zero-area fragments?
# [10:05] <fantasai> ChrisL: What would be the practical difference between skipping vs. not-skipping
# [10:05] <fantasai> Alan: As it stands, make at least 1px progress to prevent infinite loop
# [10:06] <fantasai> dbaron: Underlying principle of fragmentation, in columns and pages certainly, never want to get into situation where you decide first item on the page/column doesn't fit so push to next page... and then make same decision in next column/page
# [10:06] <fantasai> dbaron: So for pages/columns, need to force progress
# [10:06] * glazou sgalinea_ I'm patiently waiting for the meme "absolutize the fragmentainers"
# [10:06] <fantasai> Rossen: Options we came up with are
# [10:06] <fantasai> Rossen: A) Have a 1px minimum progress
# [10:07] <fantasai> Rossen: i.e. fragmentainer is always assumed to b eat least 1px tall, so that progress can always be made
# [10:07] <dbaron> q+ to comment on option A's description
# [10:07] * Zakim sees dbaron on the speaker queue
# [10:07] <fantasai> Rossen: B) Ignore fragmentainers that are zero area
# [10:08] <fantasai> Rossen: Meaning, if all fragments are zero-height, such as columns or pages, then no layout will take place at all
# [10:08] <fantasai> Rossen: Also with this option, if you have a non-homogenous array of fragmentainers, then skip zero-height containers, and layout only occurs in other containers
# [10:08] <fantasai> Rossen: These are only two that we have
# [10:08] <fantasai> Bert: Third option would be that if zero-height, must put at least one thing
# [10:09] * leaverou is now known as leaverou_away
# [10:09] <fantasai> astearns: Sounds like a variation on option 2 where you abort where the first zero-height thing, put everything there
# [10:09] <fantasai> Bert: If your object is too big for the fragmentainer, would push to next one
# [10:10] <fantasai> astearns: Bert' soption, if you have flow of 100px tall things, and all columns are 50px tall, each column gets one of those items (and they overflow)
# [10:10] <fantasai> astearns: Choosing not to slice
# [10:10] <dbaron> ack dbaron
# [10:10] <Zakim> dbaron, you wanted to comment on option A's description
# [10:10] <fantasai> fantasai: For printing though you want to slice, because overflow is not visible
# [10:10] * Zakim sees no one on the speaker queue
# [10:10] <dauwhe_> s/Bert' soption/Bert's option/
# [10:11] <fantasai> dbaron: Thinking about it as 1px of height doesn't seem exaclty right
# [10:11] <dauwhe_> s/exaclty/exactly/
# [10:11] <fantasai> dbaron: If you're at the top of a fragment and you need to place something, might place more than 1px -- might want to put one line of text
# [10:11] <fantasai> dbaron: In gecko, we have boolean of whether we placed anything yet, if not we place the first "thing"
# [10:12] <fantasai> fantasai: We worded it as fragmentainer is 1px tall, not that make 1px of progressm
# [10:12] <fantasai> fantasai: We want the behavior to be continuous between zero-height and 1px or more
# [10:12] <fantasai> fantasai: e.g. one behavior we considered was "if it's zero-height, place at least one thing, but if more than that, place whatever fits" which is not continuous
# [10:13] <fantasai> s/which is/but that is/
# [10:14] <fantasai> Rossen: Another option we considered was to have this as an option, where it was option between 1 and 2, either force progress always regardless of area, or you have the behavior inspecting fragmentaent container chain to see if thereis a better place to put the content
# [10:14] <fantasai> Rossen: That would be more fancy behavior
# [10:14] <fantasai> astearns: Might be able to make distinction between situations where overflow is basically lost, as in pritning, vs. fragmenting in a larger layout where you could overflow but overlap otehr content
# [10:14] * leaverou_away is now known as leaverou
# [10:15] <fantasai> fantasai: Either case risks data loss; in printing, it's guaranteed, but if overlapping might also lose content underneath
# [10:15] <fantasai> fantasai: I think defautl behavior should avoid any overflow
# [10:15] <astearns> I think the distinction I wanted to make was whether the overflow content could be scrolled to or not, not so much whether it overlapped anything
# [10:15] <dauwhe_> s/defautl/default/
# [10:16] <fantasai> fantasai: So if you're in a scrolling fragmentainer...
# [10:17] <fantasai> ...
# [10:17] <fantasai> astearns clarifies that he's talking about e.g. a region that is a fragmentainer placed on a scrollable canvas
# [10:18] <fantasai> fantasai points out that while you can scroll to see the image (or whatever) that didn't quite fit, you can't scrol to see the paragraph of text that might be underneath now
# [10:18] <fantasai> ...
# [10:18] <fantasai> Rossen: What do you do if you have an image into a zero-height page?
# [10:19] <fantasai> dbaron: Gecko doesn't fragment inline images. For block images, let me see ...
# [10:19] * Joins: jeff (jeff@public.cloak)
# [10:19] <fantasai> dbaron: If a block image is given a zero page size, it will consume 1px height on that page
# [10:19] <fantasai> Rossen: Which is the behavior we defined in Option A
# [10:20] <fantasai> dbaron notes that this was probably a fix for a hang bug, where the point was to make it not hang
# [10:20] * Joins: r12a (rishida@public.cloak)
# [10:20] <fantasai> Rossen: Note that this a pathological case, but still have to handle it
# [10:20] <SimonSapin> WeasyPrint definitely had such hangs
# [10:20] <fantasai> Rossen: I think 1px minimum height and guarantee of continuity is great for homogenous case
# [10:21] <dbaron> http://hg.mozilla.org/mozilla-central/file/16949049f03d/layout/generic/nsImageFrame.cpp#l860 is the code I was referring to
# [10:21] <fantasai> Rossen: For non-homogenous case, option B seems better
# [10:21] <fantasai> Option C was "dont' slice things"
# [10:22] <dbaron> (Interestingly, we only split images when we're paginated, and not for multicol in non-paginated displays.)
# [10:22] * Joins: teoli (~teoli@public.cloak)
# [10:22] <fantasai> Bert: So look forward to see if there's a better box
# [10:22] <fantasai> fantasai: So what if fragmentainer is not zero, but 1px tall and you have a 5px thing, do you look forward for that?
# [10:23] <fantasai> Rossen: Yes.
# [10:23] <fantasai> Rossen: But then if you have an image that is 150% tall, it will never fit
# [10:24] <fantasai> Bert: You get what you asked for
# [10:24] <fantasai> fantasai: Might not have asked for it, might have fragmentainers based on viewport height, and have images that happen to be taller than my viewport
# [10:24] <fantasai> ...
# [10:25] <fantasai> astearns: What convinced me to 1px solution last time was having infinite loop in box-generation code
# [10:26] <fantasai> fantasai: So, seems to me that 1px solution is reasonable, simple, predictable, and continuous
# [10:27] <fantasai> fantasai: Should go with that, and do fancy find-the-fragmentainer-that-fits behavior as a different option
# [10:27] <fantasai> fantasai: That's not a zero-height fagemntainer problem, but any-height fragmentainer one
# [10:27] <fantasai> Bert: Seems obvious to me that if the item doesn't fit on the left page, but fits on the second page, then should go to the second page
# [10:28] <fantasai> Liam says something about scope and pathological examples
# [10:28] <dauwhe_> s/fagemntainer/fragment container/
# [10:28] <fantasai> plinss: I think we need a general-purpose solution for dealing with things that don't fit
# [10:28] <fantasai> Liam: Have constriants like having image or footnote on same page as its reference
# [10:28] * Joins: koji (~koji@public.cloak)
# [10:29] <dauwhe_> s//constriants/constraints/
# [10:30] * dauwhe_ s///// :)
# [10:30] <fantasai> ...
# [10:30] <fantasai> ChrisL: Probably don't want to print 1px per page
# [10:31] <fantasai> dbaron: Then get into issue of what is the smallest allowable page, should it be 100px? 2in?
# [10:31] <fantasai> dbaron: What if you want to print fortune cookie slips?
# [10:31] <SimonSapin> Print business cards in CSS. Done that.
# [10:32] <fantasai> RESOLVED: 1px fragmentainer minimum
# [10:32] <fantasai> Content-fitting is separate issue to address in some other spec
# [10:32] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [10:33] <fantasai> asking about other issues?
# [10:34] <fantasai> astearns: Why when you have 100px-tall div with 300px of content, do you get 3 balanced columns of 100px bits of text
# [10:35] <fantasai> fantasai: Oh, you're asking why is overflow content considered content for the purpose of filling oclumns
# [10:35] <fantasai> fantasai: I don't know that we explicitly discussed that for columns, but printt *has* to work that way
# [10:36] <fantasai> fantasai: And shouldn't pages/columns be treated the same in how they handle fragmentation
# [10:36] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [10:37] <fantasai> astearns: I would like that pointed out in the spec
# [10:37] <fantasai> ACTION: Rossen and fantasai to note that in the spec
# [10:37] * RRSAgent records action 7
# [10:37] * trackbot is creating a new ACTION.
# [10:37] <trackbot> Created ACTION-592 - And fantasai to note that in the spec [on Rossen Atanassov - due 2013-11-17].
# [10:37] <fantasai> Meeting closed.
# [10:37] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [10:37] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [10:38] * Quits: Israelh (~Israelh@public.cloak) ("Page closed")
# [10:38] * Quits: emalasky1 (~Adium@public.cloak) ("Leaving.")
# [10:38] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:38] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [10:38] * Quits: jeff (jeff@public.cloak) ("Leaving")
# [10:38] * Quits: glazou (~glazou@public.cloak) (glazou)
# [10:39] * Joins: r12a-limechat (rishida@public.cloak)
# [10:40] * Quits: xiaoqian (xiaoqian@public.cloak) ("")
# [10:40] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [10:41] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:41] * Quits: sgalinea_ (~sgalineau@public.cloak) (Client closed connection)
# [10:41] * Quits: r12a-limechat (rishida@public.cloak) (Client closed connection)
# [10:43] * leaverou is now known as leaverou_away
# [10:43] * heycam is now known as heycam|away
# [10:45] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [10:47] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [10:48] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:49] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:57] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [11:00] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [11:28] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:29] * Joins: koji (~koji@public.cloak)
# [11:36] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [11:47] * Disconnected
# [11:57] * Attempting to rejoin channel #css
# [11:57] * Rejoined channel #css
# [11:57] * Topic is 'http://wiki.csswg.org/planning/tpac-2013#agenda'
# [11:57] * Set by plinss on Sun Nov 10 06:15:58
# [12:22] <Zakim> plinss, you asked to be reminded at this time to go home
# [12:57] * Joins: koji (~koji@public.cloak)
# [13:13] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [13:17] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [13:19] * Joins: teoli (~teoli@public.cloak)
# [13:36] * Joins: lmclister (~lmclister@public.cloak)
#
# Session Start: Sun Nov 10 13:47:45 2013
# Session Ident: #css
# [13:47] * Now talking in #css
# [13:47] * Topic is 'http://wiki.csswg.org/planning/tpac-2013#agenda'
# [13:47] * Set by plinss on Sun Nov 10 06:15:58
# [13:52] * Joins: lmcliste_ (~lmclister@public.cloak)
# [13:53] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [13:56] * Joins: hober (~ted@public.cloak)
# [13:57] * heycam|away is now known as heycam
# [13:59] * Joins: jet (~junglecode@public.cloak)
# [14:03] * Quits: jet (~junglecode@public.cloak) (Client closed connection)
# [14:03] * Joins: jet_ (~junglecode@public.cloak)
# [14:09] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:11] * Joins: lmclister (~lmclister@public.cloak)
# [14:15] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [14:42] * heycam is now known as heycam|away
# [14:43] * Quits: jet_ (~junglecode@public.cloak) (jet_)
# [14:58] * Quits: lmclister (~lmclister@public.cloak) ("")
# [14:58] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [14:59] * Joins: kawabata2 (~kawabata@public.cloak)
# [15:02] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [15:04] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:05] * Joins: kennyluck (~kennyluck@public.cloak)
# [15:12] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [15:14] * Quits: kawabata2 (~kawabata@public.cloak) (Client closed connection)
# [15:14] * Joins: leif (~lastorset@public.cloak)
# [15:35] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:37] * Joins: sgalineau (~sgalineau@public.cloak)
# [15:37] * Quits: sgalineau (~sgalineau@public.cloak) (sgalineau)
# [15:41] * Joins: emalasky (~Adium@public.cloak)
# [15:42] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [15:46] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [15:47] * Joins: emalasky (~Adium@public.cloak)
# [15:49] * Joins: emalasky1 (~Adium@public.cloak)
# [15:55] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [16:09] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:16] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:26] * Zakim excuses himself; his presence no longer seems to be needed
# [16:26] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [16:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:42] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [16:52] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:10] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [17:20] * Quits: emalasky1 (~Adium@public.cloak) (Client closed connection)
# [17:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:53] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [18:08] * Joins: kennyluck_ (~kennyluck@public.cloak)
# [18:12] * Quits: kennyluck (~kennyluck@public.cloak) (Ping timeout: 180 seconds)
# [18:12] * kennyluck_ is now known as kennyluck
# [18:18] * Joins: kennyluck_ (~kennyluck@public.cloak)
# [18:21] * Quits: kennyluck (~kennyluck@public.cloak) (Ping timeout: 180 seconds)
# [18:22] <TabAtkins> Re: GCPM I'm not supportive of forking for the sake of it. Patent policy doesn't play in here - that's why Hixie made the WHATCG within the W3C, so WHATWG specs could be published under the W3C's patent policy.
# [18:22] * Joins: kennyluck (~kennyluck@public.cloak)
# [18:23] <TabAtkins> The WebApps WG has also showed in spades why you don't just fork for the sake of "having it in the W3C" - their copied specs are out-of-date, sometimes have gratuitous differences, etc.
# [18:24] <TabAtkins> We should try and work with Hakon wherever the specs are living. However, given his previous reticence to bring some aspects of the specs up to reasonable standards, I'd be okay with forking if necessary if he refuses to clarify and define things properly.
# [18:24] <TabAtkins> The point is just to get good specs.
# [18:25] <Ms2ger> Let's say that's your point, at least
# [18:26] * Quits: kennyluck_ (~kennyluck@public.cloak) (Ping timeout: 180 seconds)
# [18:27] <TabAtkins> Re: canvas and video as image, this is what the element() function is for. Already defined. There are some weird aspects I'd like to clarify, but I've been pending on implementor interest for some time, as only Moz has an implemention, and I'm not sure they're interested in extending it to what I want to cover.
# [18:27] <TabAtkins> I'd be okay with reducing the scope of things I'm covering with element() if necessary. Also, I think I'd like to rename it something more obviously image-related, even just element-image() or something.
# [18:28] <TabAtkins> (The big difficulty right now is defining how out-of-document SVG fragments work with element(). We could just drop that functionality, I suppose.)
# [18:29] <TabAtkins> Re: viewports and resolution, we've discussed this before. Florian summarized things well in the MQ thread earlier today. Zoom that changes viewport geometry needs to be included in 'resolution', and that's it.
# [18:37] <TabAtkins> Re: <position> syntax, I think the main ambiguity issue is the fact that we can't predict how many <length>s to consume. Keywords should be fine to keep as a 1-value syntax. (Perhaps even just "center".)
# [18:38] <TabAtkins> I mean, I guess technically if we have only 2/4 values we can even put <position>s next to each other without ambiguity, which is kinda nice.
# [18:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:49] * Joins: r12a (rishida@public.cloak)
# [18:53] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [19:00] * Joins: kennyluck_ (~kennyluck@public.cloak)
# [19:00] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [19:05] * Quits: kennyluck (~kennyluck@public.cloak) (Ping timeout: 180 seconds)
# [19:05] * kennyluck_ is now known as kennyluck
# [19:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [19:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:54] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [19:54] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [20:39] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [20:39] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:45] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [20:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:54] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:03] * Joins: jet (~junglecode@public.cloak)
# [21:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:40] * Joins: cabanier (~cabanier@public.cloak)
# [21:41] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [21:41] * Joins: cabanier (~cabanier@public.cloak)
# [21:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:19] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:37] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [22:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:47] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:59] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:05] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:12] * Quits: jet (~junglecode@public.cloak) (jet)
# [23:13] <astearns> TabAtkins: on canvas as image, the main benefit over element() is that you don't need to add an element just to get a canvas to draw into
# [23:32] * Joins: jdaggett (~jdaggett@public.cloak)
# [23:42] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [23:42] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:49] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:56] <TabAtkins> astearns: You don't need to with element() either - just make the element in script, assign it to the element map, and bob's your uncle.
# [23:56] <TabAtkins> For the elements that know how to provide an image source, they don't need to be in the document.
# [23:58] <astearns> ah, so there's issue 5 in the spec to determine how to refer to it
# Session Close: Mon Nov 11 00:00:00 2013

The end :)