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

Options:

# Session Start: Tue Nov 12 00:00:01 2013
# Session Ident: #css
# [00:09] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [00:19] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [00:25] * Joins: rhauck (~Adium@public.cloak)
# [00:25] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [00:41] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [01:04] * Joins: emalasky (~Adium@public.cloak)
# [01:06] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [01:06] * Joins: glenn (~gadams@public.cloak)
# [01:11] * Joins: myakura (~myakura@public.cloak)
# [01:13] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:18] * Joins: kennyluck (~kennyluck@public.cloak)
# [01:18] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [01:21] * Joins: masatakayakura (~myakura@public.cloak)
# [01:22] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [01:23] * Joins: mgylling (~mgylling@public.cloak)
# [01:26] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:28] * Joins: glenn (~gadams@public.cloak)
# [01:30] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:32] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [01:33] * leaverou_away is now known as leaverou
# [01:34] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:35] * Joins: sgalineau (~sgalineau@public.cloak)
# [01:35] * Joins: cwdoh (~cwdoh@public.cloak)
# [01:36] * Joins: r12a (rishida@public.cloak)
# [01:36] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [01:36] * Joins: glenn_ (~gadams@public.cloak)
# [01:40] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [01:41] * Joins: cwdoh (~cwdoh@public.cloak)
# [01:42] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [01:42] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [01:43] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [01:43] * Joins: glenn (~gadams@public.cloak)
# [01:43] * Quits: dsinger (~dsinger@public.cloak) (dsinger)
# [01:44] * leaverou is now known as leaverou_away
# [01:48] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [01:49] * Quits: silvia (~Adium@public.cloak) ("Leaving.")
# [01:49] * Joins: mgylling_ (~mgylling@public.cloak)
# [01:49] * Joins: dsinger (~dsinger@public.cloak)
# [01:52] * Joins: hayato_ (~hayato@public.cloak)
# [01:52] * masatakayakura is now known as myakura
# [01:52] * Joins: dsinger_ (~dsinger@public.cloak)
# [01:53] * leaverou_away is now known as leaverou
# [01:54] * leaverou is now known as leaverou_away
# [01:55] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [01:56] * Parts: dsinger_ (~dsinger@public.cloak) (dsinger_)
# [01:56] * Quits: dsinger (~dsinger@public.cloak) (Ping timeout: 180 seconds)
# [01:59] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [01:59] * Joins: cwdoh (~cwdoh@public.cloak)
# [02:03] * leaverou_away is now known as leaverou
# [02:03] * Joins: silvia (~Adium@public.cloak)
# [02:03] * Joins: silvia1 (~Adium@public.cloak)
# [02:04] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [02:05] * Joins: liam (liam@public.cloak)
# [02:05] * Joins: cwdoh (~cwdoh@public.cloak)
# [02:05] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [02:05] * Joins: tobie (tobie@public.cloak)
# [02:05] * Joins: cwdoh (~cwdoh@public.cloak)
# [02:06] * Joins: lmcliste_ (~lmclister@public.cloak)
# [02:06] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [02:07] * Joins: kurosawa (~kurosawa@public.cloak)
# [02:09] * Joins: plh (plehegar@public.cloak)
# [02:10] * Quits: silvia (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:11] * leaverou is now known as leaverou_away
# [02:12] * Joins: silvia (~Adium@public.cloak)
# [02:13] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [02:14] * Joins: lmcliste_ (~lmclister@public.cloak)
# [02:15] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [02:16] * Quits: kennyluck (~kennyluck@public.cloak) (Ping timeout: 180 seconds)
# [02:17] * Joins: stakagi (~stakagi@public.cloak)
# [02:17] * Joins: zhouchao (~zhouchao@public.cloak)
# [02:18] * Quits: silvia1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:18] * Joins: leif (~lastorset@public.cloak)
# [02:18] * Joins: rhauck (~Adium@public.cloak)
# [02:21] * Quits: tobie (tobie@public.cloak)
# [02:22] * Joins: Zakim (zakim@public.cloak)
# [02:22] * Joins: kennyluck (~kennyluck@public.cloak)
# [02:22] <plinss> zakim, room for 4?
# [02:22] <Zakim> ok, plinss; conference Team_(css)01:22Z scheduled with code 26634 (CONF4) for 60 minutes until 0222Z
# [02:22] * Quits: kennyluck (~kennyluck@public.cloak) (Client closed connection)
# [02:22] * Joins: kennyluck (~kennyluck@public.cloak)
# [02:22] <plinss> zakim, call Wuzhou_East
# [02:22] <Zakim> ok, plinss; the call is being made
# [02:22] <Zakim> Team_(css)01:22Z has now started
# [02:23] <Zakim> +Wuzhou_East
# [02:23] * Joins: zqzhang (~zqzhang@public.cloak)
# [02:23] * Joins: dbaron (~dbaron@public.cloak)
# [02:23] * Joins: bobby (~bobby@public.cloak)
# [02:23] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [02:23] * Joins: rhauck1 (~Adium@public.cloak)
# [02:24] * Joins: rhauck (~Adium@public.cloak)
# [02:25] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [02:26] <Zakim> -Wuzhou_East
# [02:26] <Zakim> Team_(css)01:22Z has ended
# [02:26] <Zakim> Attendees were Wuzhou_East
# [02:26] * Joins: Rossen_ (~Rossen@public.cloak)
# [02:26] <plinss> zakim, remind us in 9 hours to get some sleep
# [02:26] <Zakim> ok, plinss
# [02:28] * Joins: rhauck2 (~Adium@public.cloak)
# [02:28] <plinss> rrsagent, make logs public
# [02:28] <RRSAgent> I have made the request, plinss
# [02:28] * Joins: lmcliste_ (~lmclister@public.cloak)
# [02:28] * heycam|away is now known as heycam
# [02:28] * Joins: kawabata2 (~kawabata@public.cloak)
# [02:29] * Joins: dino (~dino@public.cloak)
# [02:29] * Joins: r12a (rishida@public.cloak)
# [02:30] <dbaron> ScribeNick: dbaron
# [02:30] <dbaron> Topic: Box generation and elements as regions
# [02:30] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:31] * Joins: jet (~junglecode@public.cloak)
# [02:31] <dbaron> [projector and microphone configuration]
# [02:31] * Joins: koji (~koji@public.cloak)
# [02:32] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:32] <dbaron> Alan shows http://www.theguardian.com/world?view=mobile
# [02:32] <dbaron> Alan: wanted to describe a few things we're doing with regions
# [02:33] <dbaron> Alan: We're pushing for using regions and named flows in responsive UI designs
# [02:33] <dbaron> Alan: I'm showing a site from the guardian, not using regions at all. Has navigation bar at top, with menu that comes out. Assuming for a landscape tablet display. As you narrow the display, the navigation elements move to the menu.
# [02:34] <dbaron> Alan: Script is putting items that don't fit in the width and moves elements around in the DOM.
# [02:34] <dbaron> Alan: script is a little buggy and janky
# [02:34] * Joins: Zeke_ (~Zeke@public.cloak)
# [02:34] <dbaron> Alan: really easy to do by defining navigation elements as belonging to a named flow, two regions: nav bar, and menu
# [02:34] <dbaron> Alan: that's much more performant, and doesn't need script
# [02:35] <dbaron> Alan: Similar thing ,example at http://adobe-webplatform.github.io/regions-adaptive/
# [02:35] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [02:35] <dbaron> Alan: Don't want these buttons to show up on mobile, so at a certain width all the buttons get collected into a named flow and put into a slide-out.
# [02:35] <dbaron> Alan: no script, just a media query that turns on the named flow
# [02:35] * Quits: bobby (~bobby@public.cloak) (bobby)
# [02:35] <dbaron> Alan: just wanted to introduce these ideas to the group
# [02:35] * Joins: bobby (~bobby@public.cloak)
# [02:36] <dbaron> Alan: In this case it's a region chain of regions all with a particular height (viewport height) so the content is interspersed with images (http://adobe-webplatform.github.io/Demo-for-National-Geographic-Orphan-Elephants/ )
# [02:37] <dbaron> Alan: I've been posting to www-style about how named flows work with overflow:fragments in an attempt to convince people that the issue in regions about box generation should be closed because every box generation mechanism we have defined or proposed for CSS is something regions can participate in.
# [02:37] <dbaron> Alan: The original issue was put into the specification because people wanted to see what the page template proposal that we had only talked about would look like.
# [02:37] * Joins: ChrisL (clilley@public.cloak)
# [02:37] <dbaron> Alan: I produced the page template proposal where we can target CSS-generated boxes with region chains.
# [02:37] <dbaron> Alan: I assume we're going to do something similar in future work with this group. Regions works well with that.
# [02:38] <dbaron> Alan: Introduced before and after elements, and introduced overflow:fragments which dbaron ran with and produced an interesting spec; but again, regions works well with overflow:fragments.
# [02:38] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [02:38] <dbaron> Alan: you can take 2 overflow:fragments elements in your document, link with named flow, and have content flowing through elements without adding region elements to markup at all
# [02:39] <dbaron> Alan: so the question was, do we need a box generation mechanism forregions, and I've maintained all along that we don't, and we'll use every box generation mechanism we have for CSS.
# [02:39] <dbaron> Alan: so unless anybody has an objection I'd like to close that one particular issue
# [02:40] * Joins: lmcliste_ (~lmclister@public.cloak)
# [02:41] * Quits: bobby (~bobby@public.cloak) (bobby)
# [02:41] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:41] * Joins: ChrisL (clilley@public.cloak)
# [02:41] * Joins: bobby (~bobby@public.cloak)
# [02:42] <fantasai> dbaron: I'm ok with closing 15733
# [02:42] <fantasai> fantasai: 16858 stays open
# [02:42] <fantasai> astearns: yeah
# [02:42] <dbaron> RESOLVED: closing issue in bug 15733
# [02:43] <dbaron> Alan: I don't know that it's going to be fruitful to talk about elements today. I've been posting to list; on dbaron's todo list to look at those messages.
# [02:43] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:43] <dbaron> Alan: If anyone wanted to discuss what we've been talking about on the list about using named flows and region chains as lower level mechanism for describing fragmentation and pagination and thinsg, but also happy continuing discussion on list.
# [02:44] <dbaron> Alan: Anybody want to talk about that right now?
# [02:44] <dbaron> Alan: if not, move on to next agenda item
# [02:44] * fantasai would like to add css3-background to agenda
# [02:44] <dbaron> Topic: CSS Writing modes, Tr fallback
# [02:44] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:44] * Joins: ChrisL (clilley@public.cloak)
# [02:44] <dbaron> Peter: Maybe we can close this one today?
# [02:44] * Joins: glenn (~gadams@public.cloak)
# [02:45] * leaverou_away is now known as leaverou
# [02:45] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:45] * Joins: ChrisL (clilley@public.cloak)
# [02:45] <dbaron> Koji projects http://www.unicode.org/reports/tr50/
# [02:45] <dbaron> Koji: issue is Tr fallback in writing-modes
# [02:45] <dbaron> Koji: background on discussion:
# [02:46] * Joins: israelh (~israelh@public.cloak)
# [02:46] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:46] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:46] * Joins: Dongwon (~iDongwon@public.cloak)
# [02:46] <dbaron> Koji: UTR50 describes 4 values (shows Table 1). One of them is Tr. T means transform, not only about upright or rotated, but usually requires different type of transformation
# [02:46] * Joins: ChrisL (clilley@public.cloak)
# [02:46] * Joins: glenn (~gadams@public.cloak)
# [02:46] <dbaron> Koji: Tr means if font doesn't provide alternative glyphs it should fall back to rotated
# [02:46] * hober who's channeling jdaggett in the room?
# [02:47] * TabAtkins not it
# [02:47] <dbaron> Koji: Tr has 2 purposes (1) for backwards compat -- but all existing fonts have alternative glyphs
# [02:47] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:47] * Joins: ChrisL (clilley@public.cloak)
# [02:47] <dbaron> Koji: example is U+3030 WAVY DASH - not only about rotation but also includes flipping
# [02:48] <fantasai> for backwards compat -- you can see, these characters are not transformed, just rotated, but since all fonts contain transformed glyhs that perform the rotation, want to use those glyphs
# [02:48] <dbaron> Koji: recommendation is preference for flipping in font system, but preference to fall back to rotated fonts
# [02:48] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:48] <dbaron> Koji: in CSS writing modes, we had same definition for Tr at one point
# [02:48] * Joins: ChrisL (clilley@public.cloak)
# [02:48] <fantasai> s/example is/(2) example is/
# [02:48] <dbaron> Koji: 1.5 years ago John proposed that implementation cost of Tr fallback is high, and # of chars affected is about 10-20 characters
# [02:49] <dbaron> Koji: given the definition -- if font provides all alternative glyphs for these 20 codepoints, issues will go away
# [02:49] * Joins: mz-modeltaxi (~mz_modeltaxi@public.cloak)
# [02:49] <dbaron> Koji: John said even though UTR50 defines fallback, given implementation cost, wants CSS to define fallback to upright
# [02:49] <dbaron> Koji: after that we had 2 different feedback from developers, saying implementation is easy, and they want their UA to display those characters correctly, even with existing fonts
# [02:49] * sgalineau does not believe jdaggett described the cost as sky-high or 'impossible'. his argument was that it was unnecessary.
# [02:50] <dbaron> Koji: so we have a situation where 2 developers want fallback to rotated and 1 to upright
# [02:50] <dbaron> Koji: fantasai and I discussed, considered 5-10 characters as subtle difference.
# [02:50] <dbaron> Koji: We agreed to defined to define UA may fall back to upright or sideways, which is what we have in spec right now.
# [02:50] <dbaron> Koji: in September John raised concern that 2 options can cause confusion to authors, and fallback to rotated is wrong or cost high
# [02:51] <dbaron> Koji: so John wants CSS to define "must upright"
# [02:51] <dbaron> Koji: so sylvain agreed with that; glenn disagrees and wants rotated or both options
# [02:51] <dbaron> Koji: James Clark is ???, fantasai and Rossen are opposed too
# [02:51] <dbaron> Koji: Eric said he agrees with john 2 weeks ago
# [02:51] <dbaron> Koji: I talked with Eric last week during UTC, still wants upright, but ok for WG to resolve
# [02:52] <dbaron> Koji: I think that's pretty much situation up to today
# [02:52] <dbaron> Koji: This issue is last issue remaining for LC of css-writing-modes
# [02:52] <sgalineau> For Adobe, Eric Muller believes the best option is to mandate no fallback http://lists.w3.org/Archives/Public/public-i18n-cjk/2013OctDec/0036.html
# [02:52] <dbaron> SteveZ: 2 comments:
# [02:52] <dbaron> SteveZ: (1) you said TR50 said "should falllback" but what said is "can fallback", though that's a nit.
# [02:53] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [02:53] * Joins: dwim (~dwim@public.cloak)
# [02:53] <dbaron> SteveZ: (2) second point Eric was concerned about was telling whether font had the appropriate characters. He's concerned about looking at font data because with font subsetting you may get false information about what the font is doing if you're getting a subset. So he was concerned about building that particular piece.
# [02:53] * mz-modeltaxi is now known as danielkim
# [02:53] <sgalineau> q+
# [02:53] * Zakim sees sgalineau on the speaker queue
# [02:53] * Joins: eliezerb (~Eliezer@public.cloak)
# [02:53] <dbaron> SteveZ: (3) John's point was that whenever we have optional sorts of things, it means implementations diverge and users get unhappy
# [02:53] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:53] <dbaron> Koji: comments on those three:
# [02:53] <dbaron> Koji: (1) As you said it's "can".
# [02:53] * Joins: ChrisL (clilley@public.cloak)
# [02:54] <dbaron> Koji: and as Eric said this UTR50 is a formalism, so it's not forcing everything.
# [02:54] <fantasai> s/a formalism/informative/
# [02:54] <dbaron> Koji: (2) so I understand that not only it has some other issues like John pointed out, may break dlig
# [02:54] <dbaron> Koji: argument is that can be fixed by designing fonts correctly or designing embedding correctly
# [02:54] <dbaron> Koji: so there are challenges
# [02:54] <dbaron> Koji: but that's not something really not possible
# [02:55] <dbaron> Koji: (3) There may be a ??? on UTR50
# [02:55] <dbaron> Koji: But original goal of UTR50 was to provide consistent orientation
# [02:55] <dbaron> Koji: during development phase we figured it's not possible with existing fonts
# [02:55] <dbaron> Koji: so our goal was to give best consistency, and complete consistency if UTR50 compatible font is used
# [02:55] <dbaron> Koji: and there are 10 characters we are discussing for Tr
# [02:56] <dbaron> Koji: and 20 or more that will be inconsistent anyway
# [02:56] <dbaron> Koji: I'm working with Japanese publishers and AntennaHouse about how authors have to be careful when authoring to be careful orientation consistent across existing fonts
# [02:56] <dbaron> Koji: I agree that allowing both options can diverge and add more burden to authors, but it's not something we can really avoid
# [02:56] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:56] * Joins: ChrisL (clilley@public.cloak)
# [02:56] <dbaron> Koji: given the cost; development cost varies depending on architecture
# [02:57] <dbaron> Koji: Given that we can't reach consensus I think allowing both is best option
# [02:57] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:57] <dbaron> SteveZ: concerned about something you said: fixing a rare case and fixing it at the cost of putting burden on anyone who develops font subsetting
# [02:57] * Joins: ChrisL (clilley@public.cloak)
# [02:57] <dbaron> SteveZ: font subsetting seems likely to be very popular for East Asian fonts. Adding cost to that to fix this problem seems wrong way to go.
# [02:57] <dbaron> fantasai: don't see what this has to do with subsetting
# [02:58] <dbaron> SteveZ: probably not in this case... either character is there or not
# [02:58] <sgalineau> q+
# [02:58] * Zakim sees sgalineau on the speaker queue
# [02:58] <dbaron> Koji: let me explain: Tr defines render as upright, but if no vertical alt, fallback to rotated
# [02:58] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:58] <dbaron> Koji: font subsetting could only subset one glyph without the vert table
# [02:58] * Joins: ChrisL (clilley@public.cloak)
# [02:58] <dbaron> Koji: in that case using the subsetted font UA cannot determine if codepoint has vertical alternate glyph or not.
# [02:58] <dbaron> SteveZ: yes, sounds correct
# [02:58] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:59] * Joins: glenn (~gadams@public.cloak)
# [02:59] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [02:59] <dbaron> Koji: the case for PDF, but for epub or html where user can override writing modes for usability/accessibility, regardless of this issue, font subsetting should include both horizontal and vertical alternate glyphs into the subsetted fonts. If they do that they also solve this problem.
# [02:59] * Joins: ChrisL (clilley@public.cloak)
# [02:59] <dbaron> Koji: It's true that it requires additional step, but it's not only to solve this problem.
# [02:59] <dbaron> Koji: does that answer your questions?
# [03:00] <dbaron> SteveZ: I certainly understand what you're saying; requirement for not subsetting with only one of directional things is not coming from this but coming from that user style sheets could override, so you need that capability anyway.
# [03:00] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:00] * Joins: ChrisL (clilley@public.cloak)
# [03:00] <dbaron> Koji: this is about 10 characetrs. In John's original proposal those 10 characters will be rendered incorrectly for some existing fonts
# [03:00] * Joins: zhouchao_ (~zhouchao@public.cloak)
# [03:00] <dbaron> Koji: John and Eric think that's ok because rarely used characters ...
# [03:00] <dbaron> Sylvain: no, they think fonts will get fixed
# [03:00] * Quits: zhouchao (~zhouchao@public.cloak) (Ping timeout: 180 seconds)
# [03:01] * Quits: dino (~dino@public.cloak) (Ping timeout: 180 seconds)
# [03:01] <dbaron> Koji: I know there are technical differences... if it's about subtle differences why do we care so much?
# [03:01] <dbaron> SteveZ: understand last way, but applies equally way to any resolution
# [03:01] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:01] * Joins: ChrisL (clilley@public.cloak)
# [03:01] * Joins: dino (~dino@public.cloak)
# [03:01] <dbaron> Koji: Thus I ask either behavior. John wants to demand single behavior, I want to know why.
# [03:01] <dbaron> Jet: the cost to every other codepoint that's not those 10
# [03:02] <dbaron> Jet: extra conditional in code -- vs benefit to rendering those characters incorrectly
# [03:02] <ChrisL> q?
# [03:02] * Zakim sees sgalineau on the speaker queue
# [03:02] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:02] <dbaron> Sylvain: I posted a link to Eric Muller's post. Eric thinks no fallback is the better decision.
# [03:02] * Joins: ChrisL (clilley@public.cloak)
# [03:02] <dbaron> Sylvain: That's consistent with feedback I got from other experts.
# [03:03] <dbaron> Sylvain: I think issue about cost was not about absolute cost, but about cost relative to how often it's needed, since expectation is that fonts will be fixed.
# [03:03] * heycam is now known as heycam|away
# [03:03] <dbaron> Sylvain: In general in standards providing optional behavior is a source of incompatibility.
# [03:03] <dbaron> Sylvain: I think that makes sense.
# [03:03] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:03] * Joins: ChrisL (clilley@public.cloak)
# [03:03] <dbaron> Koji: It costs more for one option for one architecture but opposite cost for other architectures.
# [03:03] <dbaron> Koji: So if we mandate one we have to pick one.
# [03:03] <dbaron> Sylvain: That's the point of mandating.
# [03:04] <dbaron> Koji: Costs more for some browsers and less for others.
# [03:04] <dbaron> Sylvain: I don't think having no fall back can cost more than fallback.
# [03:04] <dbaron> Koji: I disagree.
# [03:04] <dbaron> Koji: 1.5 years ago discussion cost is sky high another developer said cost is low another developer said cost is opposite
# [03:05] <dbaron> Sylvain: You write complex fallback code that you have to test for something that will happen extremely rarely. Not sky high in terms of total amount; it's relative to the benefit.
# [03:05] <dbaron> Sylvain: Mandating no fallback will lead fonts to update. (?)
# [03:05] <dbaron> Sylvain: So that code will never be used
# [03:05] * Joins: cabanier (~uid15093@public.cloak)
# [03:05] * Joins: cabanier_ (~uid15093@public.cloak)
# [03:05] <dbaron> Peter: does practice of subsetting potentially break that argument?
# [03:06] <dbaron> Peter: If alternates end up not part of the subset, not guaranteed to have them.
# [03:06] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:06] * Joins: ChrisL (clilley@public.cloak)
# [03:06] <SimonSapin> If we assume fonts will get fixed, can we also assume subsetting tools will get fixed?
# [03:06] <dbaron> SteveZ: Koji's point was that subsetting for CSS requires both glyphs to be there because you don't know what will be there until things arrive. You can always do it wrong, but then people will get bad results and people will stop using your system.
# [03:06] * Joins: glenn_ (~gadams@public.cloak)
# [03:06] <dbaron> Rossen: What if we, instead of disallowing it, discourage it?
# [03:07] <dbaron> Rossen: We can say that behavior is not expected, but if there's an implementation that really wants to do it, it's at least not forbidden?
# [03:07] <dbaron> Rossen: authors reading spec should not expect it to be supported, but not restricted to forbid behavior
# [03:07] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:07] * Joins: ChrisL (clilley@public.cloak)
# [03:07] <dbaron> fantasai: I think another thing to consider would be font formats other than opentype.
# [03:07] <dbaron> fantasai: In OpenType a number of these characters are transformed by convention, but this might not be true in another font format might have different expectations.
# [03:08] <dbaron> fantasai: So even if we want to mandate this for OpenType I don't think it would make sense to mandate for all font formats.
# [03:08] <dbaron> fantasai: Also doesn'tmake sense ... ??? if handled at font engine level rather than text layout level.
# [03:08] <dbaron> SteveZ: Rossen, if I understood you: "if the data for the rotated form is not present, this specification does not define what should be done"?
# [03:08] <dbaron> fantasai: works for me
# [03:08] <dbaron> Rossen: That's more of the undefined case
# [03:09] * Parts: cabanier_ (~uid15093@public.cloak)
# [03:09] <dbaron> SteveZ: I think advantage of undefined, still leaves the forcing function of getting the fonts updated, because you don't know what's going to happen.
# [03:09] <dbaron> Rossen: Would anyone not be able to live with undefined?
# [03:09] * Joins: taocai (~taocai@public.cloak)
# [03:10] <dbaron> r12a: Would it be a question of leaving it undefined like that, or undefined plus recommend that you follow UTR50?
# [03:10] <dbaron> fantasai: wording I'd suggest is that it's undefined whether the UA is allowed to synthesize some kind of substitute glyph
# [03:10] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
# [03:10] * Joins: eliezerb (~Eliezer@public.cloak)
# [03:10] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:11] <dbaron> dbaron: no longer Rossen's "undefined but discouraged" proposal?
# [03:11] * Quits: eliezerb (~Eliezer@public.cloak) (eliezerb)
# [03:11] * Joins: ChrisL (clilley@public.cloak)
# [03:11] <dbaron> (I'd prefer undefined but discouraged over simply undefined.)
# [03:11] <dbaron> SteveZ: where are we?
# [03:11] <dbaron> Rossen: I think between disallowed and undefined?
# [03:11] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [03:11] <dbaron> Rossen: As I understand, John wants disallowed
# [03:11] <sgalineau> fwiw feedback on fallback implementation cost I have heard: cheap to hack it, more expensive to do it right. too expensive for the number of cases that will exercise it
# [03:12] <fantasai> "UA may but is not expected to synthesize the substitute glyph"?
# [03:12] <dbaron> Rossen: If we say UAs are not expected to support rotated sideways glyph, but not required not to, then that should be a way of saying basically: don't expect it to work, but implementations might do it.
# [03:12] <dbaron> ChrisL: or in other words would be saying "you may fall back but not required to" just like TR50 says
# [03:12] <dbaron> SteveZ: That's why I'd prefer it's simply undefined, since otherwise you're back out of undefined.
# [03:13] <dbaron> [various people mumbling]
# [03:13] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [03:13] <dbaron> Bert: That's the wrong way round, I'd say.
# [03:13] <dbaron> Rosssen: Current spec says UA may, but not required to fall back to
# [03:13] <dbaron> Rossen: current statement is close
# [03:13] <dbaron> Bert: current statement suggest that what TR50 says is that rotating better than not
# [03:13] <dbaron> Bert: want implementations to rotate but we still like them to do it
# [03:13] <dbaron> Bert: I think wording should be clear that we still want them to.
# [03:14] <fantasai> dbaron: I think many people here disagree that we want them to
# [03:14] <fantasai> dbaron: ppl think we're bette roff expecting font to have correct data in it, instead of addign features to work around bugs in a font
# [03:14] <sgalineau> +1 to dbaron
# [03:14] <dbaron> Bert: That' assumes it's a bug in the font, maybe it's not.
# [03:14] <dbaron> Peter: In general I'm ok with any of these proposals.
# [03:14] <fantasai> I think for OpenType it would be considered a bug in the font, but for other font formats might not be...
# [03:15] <dbaron> Peter: I'm concerned that I don't want us to say "you must not do this" because if you have a font engine that does this then the UA has to undo what the font engine is doing.
# [03:15] <Rossen_> s/bette roff/better of/
# [03:15] <dbaron> Peter: Just saying it's undefined because it is defined in UTR50
# [03:15] <dbaron> Peter: if we're explicitly undefining it then we're just sanctioning what UTR50 says
# [03:15] <fantasai> +1 to Peter
# [03:15] <fantasai> wrt undoing font engine
# [03:16] <dbaron> Peter: so if we have an explicit preference we'd ???
# [03:16] <dbaron> Peter: I have concerns if we're willfully violating an other spec, if it says "can do it" and we say "must not do it"
# [03:16] <Rossen_> "the UA is not expected to fallback..."
# [03:16] <dbaron> fantasai: Can we straw poll on wording "may, but is not expected to"?
# [03:17] <dbaron> Peter: should we reference April 1 update to RFC2119?
# [03:17] <dbaron> fantasai: ?
# [03:17] <dbaron> Rossen: what if we say UA is not expected to do fallback?
# [03:17] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [03:17] <dbaron> fantasai: we have to say allowed disallowed or optional
# [03:17] * Joins: glenn (~gadams@public.cloak)
# [03:17] <dbaron> fantasai: we have to say, normatively, what is it
# [03:17] * Joins: ChrisL (clilley@public.cloak)
# [03:17] <dbaron> fantasai: saying something is expected or not expected is not really normative
# [03:17] <dbaron> SteveZ: Seems to me we have 3 possibilities:
# [03:17] * Joins: cabanier1 (~cabanier@public.cloak)
# [03:17] <dbaron> SteveZ: (1) John's "must not"
# [03:17] <dbaron> SteveZ: (2) undefined
# [03:18] * Quits: cabanier1 (~cabanier@public.cloak) (cabanier1)
# [03:18] <dbaron> SteveZ: (3) should use the font, but failing that can do fallback per TR50
# [03:18] * Quits: silvia (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [03:18] <dbaron> SteveZ: I think those are only 3 on the floor. Apperas to me at this point that easiest to eliminate is (1).
# [03:18] * Joins: silvia (~Adium@public.cloak)
# [03:18] * Joins: jehoochen__ (~jehoochen@public.cloak)
# [03:18] <dbaron> SteveZ: that leaves us with 2 different ways of saying can fall back, either by not saying anything or by saying you can
# [03:18] <dbaron> SteveZ: I'd propose a straw poll that would eliminate the first option
# [03:19] <dbaron> SteveZ: and then we can see if there's a significant difference between other two
# [03:19] <dbaron> SteveZ: Seems easier to eliminate (1) from straw poll
# [03:19] <dbaron> fantasai: 2 wordings on floor:
# [03:20] <fantasai> "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph"
# [03:20] <fantasai> vs
# [03:20] <fantasai> "If the vert alt glyph is not present in the font, behavior is undefined"
# [03:20] <fantasai> ??
# [03:20] <dbaron> peterl: RFC6919, "REALLY SHOULD NOT"
# [03:20] <sgalineau> MUST SHOULD NOT
# [03:20] <dbaron> SteveZ: I think fantasai's second option captures what we should get at
# [03:21] <SimonSapin> MAY WISH TO
# [03:21] <fantasai> fantasai: The first one is my proposal, because I don't like leaving things blanket undefined
# [03:21] * Joins: emalasky (~Adium@public.cloak)
# [03:21] <sgalineau> Y U FALLBACK
# [03:21] <dbaron> r12a: What happened about the straw poll to eliminate (1)?
# [03:21] * Quits: bobby (~bobby@public.cloak) (bobby)
# [03:21] <plinss> http://tools.ietf.org/html/rfc6919#section-3
# [03:22] <dbaron> r12a: can we resolve to eliminate option 1?
# [03:22] <dbaron> STRAW POLL:
# [03:22] <dbaron> A) "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph"
# [03:22] <dbaron> B) "If the vert alt glyph is not present in the font, behavior is undefined"
# [03:22] <dbaron> [2013-11-12 10:20:20 +0800] <fantasai> ??
# [03:22] <dbaron> (oops, ignore that extra line of copy/paste)
# [03:22] * Joins: r12a-limechat (rishida@public.cloak)
# [03:22] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [03:23] <dbaron> fantasai: I don't like (B) because it allows the UA to do absolutely anything it wants.
# [03:23] <dbaron> STRAW POLL:
# [03:23] <dbaron> A) "If the vert alt glyph is not present in the font, UA may, but is not expected to, substitute the glyph"
# [03:23] <dbaron> B) "If the vert alt glyph is not present in the font, behavior is undefined"
# [03:23] <dbaron> Alan: A
# [03:23] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:23] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [03:23] <dbaron> rhauck: A
# [03:24] <dbaron> dirk: abstain
# [03:24] <dbaron> Bert: of these two, prefer A
# [03:24] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [03:24] * Joins: emalasky1 (~Adium@public.cloak)
# [03:24] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [03:24] <dbaron> zcorpan: abstain
# [03:24] <dbaron> kazutaka: A
# [03:24] <dbaron> yamamoto: A
# [03:25] <dbaron> Koji: A
# [03:25] <dbaron> Rossen: A
# [03:25] <dbaron> Israel: A
# [03:25] <dbaron> jet: A
# [03:25] <dbaron> chrisL: A
# [03:25] <dbaron> Lea: A
# [03:25] <dbaron> Sylvain: A
# [03:25] <dbaron> 3 A's
# [03:25] <dbaron> Dean: abstain
# [03:25] <dbaron> fantasai: A
# [03:25] <dbaron> dbaron: A
# [03:25] * Joins: cwdoh (~cwdoh@public.cloak)
# [03:25] <hober> hober: mu
# [03:25] <dbaron> SteveZ: A
# [03:25] <dbaron> Kennyluck: A
# [03:25] <dbaron> Leif: abstain
# [03:25] <dbaron> Peter: A
# [03:26] <dbaron> Bert: My question is, are we really doing what Unicode want us to do?
# [03:26] <TabAtkins> TabAtkins: abstain
# [03:26] <dbaron> bert: was it really a neutral choice to be doing it or not, or do we ???
# [03:26] * Joins: bobby (~bobby@public.cloak)
# [03:26] * sgalineau looks for a font that substitutes WTF for A
# [03:26] * Joins: leif1 (~lastorset@public.cloak)
# [03:26] <dbaron> fantasai: descriptions in unicode spec are informative saying what categories mean, not dictating a behavior
# [03:26] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [03:26] <dbaron> Bert: if they didn't want implementations to rotate, why did we write it there/
# [03:27] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:27] <dbaron> Bert: I think we're saying opposite of UTR50.
# [03:27] * hober interop is so passe
# [03:27] <dbaron> Peter: UTR50 says can, we're saying may but not expected to
# [03:27] <dbaron> r12a: is substite the right word, or is rotate?
# [03:27] <dbaron> fantasai: synthesize the substitute glyph
# [03:27] <dbaron> fantasai: wording's a little bit off
# [03:27] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [03:27] * Joins: leif1 (~lastorset@public.cloak)
# [03:28] <dbaron> Peter: I think "MAY WISH TO" from RFC6991
# [03:28] <dbaron> Peter: I think "MAY WISH TO" from RFC6919
# [03:28] <dbaron> Peter: I think we should use "MAY WISH TO" and refence RFC6919.
# [03:28] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [03:29] <dbaron> RESOLUTION: Accepting option A, with term "MAY WISH TO" and referencing RFC6919.
# [03:29] <ChrisL> http://tools.ietf.org/html/rfc6919
# [03:29] <dbaron> Peter: spec ready to advance?
# [03:29] * sgalineau can't wait for the RFC6919 reference in the new charter
# [03:29] <SimonSapin> "This phrase is frequently used to avoid further delay in approval of a document."
# [03:29] <dbaron> fantasai: I expect this to be the first of at least two last calls.
# [03:29] <SimonSapin> seems appropriate
# [03:30] <dbaron> Peter: Anything to rename?
# [03:30] <dbaron> RESOLVED: Take CSS Writing Modes to Last Call.
# [03:30] <dbaron> Peter: break until 11am.
# [03:31] <fantasai> I think there's an open issue on possibly renaming text-combine-horizontal to something better/easier-to-type/less-confusing
# [03:31] * Quits: bobby (~bobby@public.cloak) (bobby)
# [03:31] * Quits: Dongwon (~iDongwon@public.cloak) (Dongwon)
# [03:31] * Quits: Zeke_ (~Zeke@public.cloak) ("Leaving...")
# [03:31] * Quits: danielkim (~mz_modeltaxi@public.cloak) (Client closed connection)
# [03:32] * Joins: danielkim (~mz_modeltaxi@public.cloak)
# [03:32] * Quits: jet (~junglecode@public.cloak) (jet)
# [03:32] * Joins: tobie (tobie@public.cloak)
# [03:33] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [03:34] * Quits: zqzhang (~zqzhang@public.cloak) (Ping timeout: 180 seconds)
# [03:34] * leaverou is now known as leaverou_away
# [03:34] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [03:34] * Joins: ChrisLilley (clilley@public.cloak)
# [03:35] * Joins: simonstewart (~simonstewart@public.cloak)
# [03:35] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [03:35] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [03:35] * Quits: zhouchao_ (~zhouchao@public.cloak) (Ping timeout: 180 seconds)
# [03:36] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [03:37] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [03:38] * Quits: ijongcheol (~ijongcheol@public.cloak) (Client closed connection)
# [03:38] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [03:39] * Quits: danielkim (~mz_modeltaxi@public.cloak) (Ping timeout: 180 seconds)
# [03:39] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [03:41] * Quits: emalasky1 (~Adium@public.cloak) ("Leaving.")
# [03:42] * Joins: dbaron (~dbaron@public.cloak)
# [03:42] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [03:42] * Joins: koji (~koji@public.cloak)
# [03:42] * Joins: Zeke_ (~Zeke@public.cloak)
# [03:43] * Quits: kurosawa (~kurosawa@public.cloak) (Ping timeout: 180 seconds)
# [03:45] * Quits: ijongcheol (~ijongcheol@public.cloak) (Ping timeout: 180 seconds)
# [03:45] * Joins: bobby (~bobby@public.cloak)
# [03:45] * Joins: danielkim (~mz_modeltaxi@public.cloak)
# [03:47] * Joins: dbaron_ (~dbaron@public.cloak)
# [03:49] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:52] * Quits: silvia (~Adium@public.cloak) ("Leaving.")
# [03:53] * Joins: jet (~junglecode@public.cloak)
# [03:53] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [03:55] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
# [03:55] * Joins: trackbot (trackbot@public.cloak)
# [03:55] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [03:55] * Joins: ChrisLilley (clilley@public.cloak)
# [03:55] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
# [03:59] * Quits: bobby (~bobby@public.cloak) (bobby)
# [04:00] * Joins: Dongwon (~iDongwon@public.cloak)
# [04:00] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:00] * Joins: ChrisLilley (clilley@public.cloak)
# [04:01] * Joins: kurosawa (~kurosawa@public.cloak)
# [04:02] * Joins: silvia (~Adium@public.cloak)
# [04:02] * Joins: silvia1 (~Adium@public.cloak)
# [04:08] * Joins: myakura (~myakura@public.cloak)
# [04:09] * leaverou_away is now known as leaverou
# [04:09] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [04:09] * Quits: silvia (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:10] * Joins: stakagi (~stakagi@public.cloak)
# [04:10] * Quits: Dongwon (~iDongwon@public.cloak) (Dongwon)
# [04:11] * leaverou is now known as leaverou_away
# [04:11] * Joins: hayato_ (~hayato@public.cloak)
# [04:13] * Quits: jehoochen__ (~jehoochen@public.cloak) (Ping timeout: 180 seconds)
# [04:13] * leaverou_away is now known as leaverou
# [04:14] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [04:15] * Joins: bobby (~bobby@public.cloak)
# [04:15] * Joins: koji (~koji@public.cloak)
# [04:15] * heycam|away is now known as heycam
# [04:16] * Joins: Rossen_ (~Rossen@public.cloak)
# [04:16] <israelh> q
# [04:17] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [04:17] * Joins: israelh (~israelh@public.cloak)
# [04:18] * Quits: kurosawa (~kurosawa@public.cloak) ("Page closed")
# [04:20] * Joins: kurosawa (~kurosawa@public.cloak)
# [04:20] * Joins: cwdoh (~cwdoh@public.cloak)
# [04:21] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [04:21] <TabAtkins> Did we not return, or is nobody minuting?
# [04:22] * plinss we're not minuting this bit
# [04:22] * Joins: emalasky (~Adium@public.cloak)
# [04:22] <plinss> nothing secret, just not necessary to minute
# [04:22] <TabAtkins> kk
# [04:23] <sgalineau> as far as I know we are making http://girliemac.github.io/presentation-slides/html5-mobile-approach/images/css-is-awesome.png our official logo
# [04:25] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:25] * Joins: ChrisLilley (clilley@public.cloak)
# [04:25] * Joins: hayato___ (~hayato@public.cloak)
# [04:25] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:25] * Joins: ChrisLilley (clilley@public.cloak)
# [04:25] <fantasai> From CSSWG design that didn't get implemented -- "mood": flowing, transparent, layered, professional, informed
# [04:26] <SimonSapin> ScribeNick: SimonSapin
# [04:26] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [04:27] <SimonSapin> Topic: Text module
# [04:27] <SimonSapin> fantasai: to prepared to discuss
# [04:27] <SimonSapin> plinss: defer
# [04:27] <SimonSapin> Topic: Charter
# [04:28] <SimonSapin> Bert: last time we had milestones, wiki page for dates
# [04:28] <SimonSapin> Bert: most people said can’t put dates
# [04:28] * fantasai link?
# [04:28] <SimonSapin> Bert: now list specs in scope, and says we don’t have dates
# [04:28] <plinss> http://www.w3.org/Style/2013/css-charter
# [04:29] <SimonSapin> Bert: mostly same as previous charter
# [04:29] <SimonSapin> Bert: same participation reqs, chairs, mailing list
# [04:29] <SimonSapin> Bert: list of modules longer
# [04:29] * Joins: simonstewart (~simonstewart@public.cloak)
# [04:29] <SimonSapin> Bert: diff list of liaisons
# [04:29] <SimonSapin> Bert: look if it’s complete and not too long
# [04:30] <SimonSapin> Bert: about not having milestones, only a list of things we work on, without dates
# [04:30] * Joins: Dongwon (~iDongwon@public.cloak)
# [04:30] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:30] <SimonSapin> Bert: do you agree with that? Can it get past AC review?
# [04:30] * Joins: ChrisLilley (clilley@public.cloak)
# [04:31] <SimonSapin> Bert: glazou said we have a few drafts that are requirements for other groups, we should give that higher priority
# [04:31] * leaverou is now known as leaverou_away
# [04:31] <SimonSapin> Bert: didn’t list those, glazou sent email with the list
# [04:31] <SimonSapin> Bert: we could mark those explicitly
# [04:31] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [04:32] * leaverou_away is now known as leaverou
# [04:32] * Joins: SteveZ (~SteveZ@public.cloak)
# [04:32] <SimonSapin> astearns: is there a logic to the order?
# [04:32] * Joins: zqzhang (~zqzhang@public.cloak)
# [04:32] <SimonSapin> Bert: no, automatic tool takes the order from the /TR page
# [04:33] <SimonSapin> Bert: date is to be updated when we have review, roughly 2 years
# [04:33] <SimonSapin> dbaron_: guess the order is by age of WD
# [04:33] <SimonSapin> dbaron_: there is a bunch that appear twice
# [04:33] <SimonSapin> Bert: that’s a bug
# [04:33] <SimonSapin> fantasai: suggest taking the Current Work page
# [04:34] <SimonSapin> dbaron_: looks like list of shortnames ever used
# [04:34] <dbaron_> duplication: UI, borders, CSS1 ,CSS2
# [04:34] * dbaron_ is now known as dbaron
# [04:34] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:34] <SimonSapin> Bert: someone wants to get through the list to fix?
# [04:34] * Joins: ChrisLilley (clilley@public.cloak)
# [04:34] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [04:34] <SimonSapin> fantasai: can you take it from Current Page?
# [04:34] <fantasai> http://www.w3.org/Style/CSS/current-work
# [04:34] <SimonSapin> Bert: some are missing
# [04:35] <SimonSapin> ChrisL: that’s a feature
# [04:35] <dbaron> We're also probably not going to work on becss.
# [04:35] * fantasai notes she needs to update Ruby and Syntax in that list
# [04:35] <fantasai> Yeah, don't want to include the Abandoned drafts
# [04:35] * dauwhe_ page templates isn't on the list
# [04:35] <SimonSapin> plinss: any feedback on the charter? folks generally happy with it?
# [04:36] <SimonSapin> ChrisL: we’re looking at the suggested extensions from 1998 and slitting our wrists
# [04:36] <SimonSapin> plinss: update the module list before we submit?
# [04:36] <astearns> dauwhe_: page templates is only an editor's draft
# [04:36] <SimonSapin> ChrisL: looks fine, I suspect AC won’t object
# [04:36] <SimonSapin> ChirsL: we say we don’t have milestones because …
# [04:37] <astearns> dauwhe_: I believe we resolved to get simple pagination done first, before making page templates a working draft
# [04:37] <SimonSapin> ChirsL: and say that things needed by HTML5 are …
# [04:37] <SimonSapin> plinss: email to internal list when ready
# [04:37] <SimonSapin> ACTION: Bert to update the list of deliverables in the charter
# [04:37] * trackbot is creating a new ACTION.
# [04:37] * RRSAgent records action 1
# [04:37] <trackbot> Created ACTION-595 - Update the list of deliverables in the charter [on Bert Bos - due 2013-11-19].
# [04:38] <SimonSapin> plinss: anything else on charter?
# [04:38] * Joins: zhouchao (~zhouchao@public.cloak)
# [04:38] <SimonSapin> Topic: Styling left vs. right pages
# [04:38] <dbaron> I wouldn't mind seeing us doing asynchronous decision making, but I'm not in the mood to have that discussion right now...
# [04:38] * Joins: emalasky1 (~Adium@public.cloak)
# [04:39] * SimonSapin dbaron +1
# [04:39] * astearns dbaron +1
# [04:39] <sgalineau> asynch decision discussion better done asynchronously
# [04:40] <SimonSapin> leaverou: discussed this in private and on mailing list
# [04:40] <SimonSapin> leaverou: long, but no conclusion
# [04:40] * Joins: ChrisL (clilley@public.cloak)
# [04:40] <SimonSapin> leaverou: people write books in CSS, including design of the book
# [04:40] * Joins: naka_ (~naka@public.cloak)
# [04:40] <SimonSapin> leaverou: I first designed mine in Illustrator, then many things were not possible in CSS
# [04:41] <SimonSapin> leaverou: no way to style elements depending on right or left pages
# [04:41] <SimonSapin> leaverou: we have @page, for the page itself or headers/footers, but not elements on the page
# [04:41] <SimonSapin> leaverou: to do sidebars in print formatters, you use "float: outside"
# [04:42] <SimonSapin> leaverou: to push it you use "float-offset" but that’s limited
# [04:42] * Quits: Zeke_ (~Zeke@public.cloak) ("Leaving...")
# [04:42] <SimonSapin> leaverou: it’s not just the sidebar, [projecting]
# [04:42] <SimonSapin> leaverou: these things have different border-radius, rotate transform, margin, etc. depending on left/right page
# [04:42] * Quits: silvia1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:43] <SimonSapin> leaverou: float: inside/outside and margin-inside/outside are not enough
# [04:43] * Joins: silvia (~Adium@public.cloak)
# [04:43] <SimonSapin> leaverou: we can,t keep adding properties, need a more generic solution
# [04:43] * Joins: plh (plehegar@public.cloak)
# [04:43] <leaverou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0607.html
# [04:43] <SimonSapin> leaverou: proposal on the list …
# [04:43] * Joins: satakagi (~stakagi@public.cloak)
# [04:43] * heycam is now known as heycam|away
# [04:43] * Quits: Dongwon (~iDongwon@public.cloak) (Dongwon)
# [04:44] <SimonSapin> leaverou: @page :left, nest style rules
# [04:44] <SimonSapin> leaverou: syntax not doable, ambiguous with declarations
# [04:44] * TabAtkins dbaron, belated +1
# [04:44] <SimonSapin> leaverou: needs infinite look-ahead, same as in Hierarchies
# [04:44] * TabAtkins is writing the Indie UI feedback email right now.
# [04:44] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:44] <SimonSapin> leaverou: proposal to use braces, at-rules, or pseudo-elements
# [04:44] <TabAtkins> Note, Hierarchies has been fixed.
# [04:45] * Joins: ChrisL (clilley@public.cloak)
# [04:45] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:45] * Quits: silvia (~Adium@public.cloak) (Client closed connection)
# [04:45] <SimonSapin> leaverou: div::page(left)
# [04:45] * Joins: silvia (~Adium@public.cloak)
# [04:45] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:45] * Joins: ChrisL (clilley@public.cloak)
# [04:45] <SimonSapin> leaverou: still limited, you want to style based on type of page (chapter, …)
# [04:45] <SimonSapin> leaverou: and other page selectors
# [04:45] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [04:46] <SimonSapin> leaverou: other proposal from AntennaHouse: extending Variables to inherit from @page
# [04:46] <SimonSapin> leaverou: but then you have different property values on different pages for the same element
# [04:46] <SimonSapin> TabAtkins, how?
# [04:47] <SimonSapin> fantasai: whatever syntax we use here should be the same as for Regions
# [04:47] <SimonSapin> dbaron: styling things between pages has a lot in common with between regions
# [04:47] * Quits: silvia (~Adium@public.cloak) (Client closed connection)
# [04:47] <TabAtkins> SimonSapin: http://tabatkins.github.io/specs/css-nesting/Overview.html#the-nested-block
# [04:47] * Joins: silvia (~Adium@public.cloak)
# [04:47] <SimonSapin> dbaron: we don’t want to allow completely arbitrary style
# [04:47] <SimonSapin> dbaron: we don’t want something that starts as a table, continues as a float, etc
# [04:47] <TabAtkins> SimonSapin: Wrap the selectors in an anonymous {} block.
# [04:48] <TabAtkins> Rather, the whole thing.
# [04:48] <SimonSapin> dbaron: there is no concept to continue the inside of a table onto the next page as something else
# [04:48] <SimonSapin> dbaron: so far we don’t have the ability to fragment things into completely different types
# [04:48] * Joins: silvia1 (~Adium@public.cloak)
# [04:48] <SimonSapin> dbaron: if we have a display-inside / display-inside split, we can’t change display-inside between fragments
# [04:48] * Quits: silvia (~Adium@public.cloak) (Client closed connection)
# [04:49] <SimonSapin> dbaron: we’r gonnna need implem experience
# [04:49] <SimonSapin> leaverou: could be limited to not allow some properties like display
# [04:49] <SimonSapin> leaverou: or just no style fragments, only based on the first page
# [04:49] <SimonSapin> dbaron: there may still be some hard cases
# [04:49] <SimonSapin> dbaron: hard to spec and get interop, even if easy to implement, with edge cases
# [04:49] <dauwhe_> q+
# [04:49] * Zakim sees sgalineau, dauwhe_ on the speaker queue
# [04:50] <SimonSapin> dbaron: with this style fits on this page but doesn’t with other style
# [04:50] <sgalineau> q-
# [04:50] * Zakim sees dauwhe_ on the speaker queue
# [04:50] <SimonSapin> dbaron: also not convinced that styling based on the first page is that useful
# [04:50] <SimonSapin> leaverou: I realize there are use cases spawnning pages, but most I’ve seen are within one page
# [04:51] <SimonSapin> astearns: when you’r printing, you control pagination
# [04:51] * dbaron Zakim, who is on the phone?
# [04:51] * Zakim apparently Team_(css)01:22Z has ended, dbaron
# [04:51] * Zakim sees on irc: silvia1, ChrisL, satakagi, plh, naka_, emalasky1, zhouchao, zqzhang, SteveZ, simonstewart, hayato___, ijongcheol, cwdoh, kurosawa, israelh, Rossen_, koji, bobby,
# [04:51] * Zakim ... kimwoonyoung, myakura, trackbot, jet, dbaron, danielkim, tobie, leif1
# [04:51] <SimonSapin> astearns: on screen, things intentended to be on one page may be split
# [04:51] * Joins: silvia (~Adium@public.cloak)
# [04:51] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [04:51] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:51] * Quits: silvia1 (~Adium@public.cloak) (Client closed connection)
# [04:51] <SimonSapin> leaverou: print formatters vendors have clients that demand features, and they will implement even without spec
# [04:51] * Joins: ChrisL (clilley@public.cloak)
# [04:52] * leif1 is now known as leif
# [04:52] <dauwhe_> q?
# [04:52] * Zakim sees dauwhe_ on the speaker queue
# [04:52] <SimonSapin> dino: I agree these are all great use-cases, but who is gonna do the work?
# [04:52] <SimonSapin> fantasai: once we hack the syntax and model stablizes for Regions, the only thing that would different in syntax is changing the work region to page
# [04:53] <ChrisL> s/work/word/
# [04:53] <SimonSapin> fantasai: the hard part of the work, Alan is already working on
# [04:53] * Parts: danielkim (~mz_modeltaxi@public.cloak) (danielkim)
# [04:53] <SimonSapin> astearns: agree with dbaron that we’re gonna need impl experience to decide what can be styled, don’t have it yet for Region
# [04:54] <SimonSapin> leaverou: btw, there is already a pseudo-class for styling … In paged media or GCPM, styling fragments of an element based on what page they appear
# [04:54] <SimonSapin> leaverou: fragmentation problems still exist
# [04:55] <SimonSapin> dauwhe_: want to mention that left/right, named pages, also need to identify arbitrary pages in a sequence
# [04:55] * Quits: taocai (~taocai@public.cloak) (Client closed connection)
# [04:55] <SimonSapin> dauwhe_: 6th page in a sequence
# [04:55] <SimonSapin> leaverou: another thing needed is syntax like :nth-page
# [04:55] <SimonSapin> leaverou: targetting pages between the 10th and the 100th
# [04:55] <SimonSapin> leaverou: would be useful for page number
# [04:56] <SimonSapin> leaverou: there is no such thing as inline-block for margin boxes…
# [04:56] <SimonSapin> dino: you need nested regions of pages that themselves can be styled
# [04:56] <SimonSapin> dauwhe_: PrinceXML has :nth-page
# [04:56] * krit :nth-all-the-things
# [04:56] <SimonSapin> dauwhe_: discussion on www-style, but complicated to define what is a page, first of chapter vs. first of document
# [04:57] <SimonSapin> dauwhe_: whole class of issues around identifying pages
# [04:57] <SimonSapin> SteveZ: XSL did come up with rules to select which of the next template is used for a given page
# [04:57] <SimonSapin> SteveZ: want a number of sources that are active, choos the template based on what kind of things are available
# [04:58] <SimonSapin> SteveZ: which template you pick depend o which are associated with the content of that page
# [04:58] <SimonSapin> SteveZ: this divorces the design of template with their selection, rule-based
# [04:58] <TabAtkins> Note my previous discussion with Hakon, that "foo:nth-page(5)" does *not* select the 5th "foo" page, but rather the 5th page if it is also a "foo" page.
# [04:58] <SimonSapin> SteveZ: :nth-page assumes that you know what content goes there
# [04:58] <TabAtkins> In other words, selectors don't modify each other.
# [04:58] <SimonSapin> SteveZ: as astearns says you may not know
# [04:59] <SimonSapin> SteveZ: XSL tired to define but never succedded sync points
# [04:59] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [04:59] <dino> TabAtkins, so how do we select the 5th foo page?
# [04:59] * Joins: ChrisL (clilley@public.cloak)
# [04:59] <TabAtkins> :nth-match(5 of foo)
# [04:59] <SimonSapin> SteveZ: the notion of identifyin sync content, stream of figures / stream of text
# [04:59] <TabAtkins> We've already solved this problem in Selectors.
# [04:59] <SimonSapin> SteveZ: thing figure goes with this piece of text
# [04:59] <dino> TabAtkins, cool
# [05:00] <SimonSapin> SteveZ: as close as possible , which may not be very close, but at least being able to declare that would be useful
# [05:00] * Quits: hayato___ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [05:00] <SimonSapin> plinss: I agree this should be aligned with Regions
# [05:00] <SimonSapin> fantasai: doesn’t belong in Fragmentation
# [05:01] <SimonSapin> plinss: useful for multicol?
# [05:01] <SimonSapin> fantasai: I think less so
# [05:01] <SimonSapin> fantasai: track as something we need to address, note that we need this for pages, but not much to do right now
# [05:01] <SimonSapin> astearns: if AH or Prince wants to run with it…
# [05:01] * Joins: plh (plehegar@public.cloak)
# [05:02] <SimonSapin> astearns: I,d be happy to put a note "this mechanism should be applied to pages"
# [05:02] <SimonSapin> astearns: if there is impl interest, pages may be done before pages
# [05:02] <SimonSapin> astearns: but I don’t know how Antenna House or Prince are prioritizing
# [05:02] <astearns> s/before pages/before regions/
# [05:03] <SimonSapin> plinss: is there consensus that this is a good idea?
# [05:03] <SimonSapin> leaverou: if the mechinism is defined in Regions, do we still need to define the syntax?
# [05:03] * Joins: myakura_ (~myakura@public.cloak)
# [05:03] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [05:03] <SimonSapin> astearns: there is a syntax for Region […] all contnet that falls in this region, here are their style
# [05:03] * Joins: ChrisL (clilley@public.cloak)
# [05:04] <SimonSapin> astearns: same would apply when selecting a page instead of a region
# [05:04] <SimonSapin> astearns: just changing that part of the selector that says I’m styling this region
# [05:05] <SimonSapin> ChrisL: we still need to write this down
# [05:05] <SimonSapin> astearns: it will be the same for styling content in Shadow DOM
# [05:05] <TabAtkins> Pages use a somewhat different selection mechanism (at-rule to introduce the selector), but yeah, similar mechanics.
# [05:06] * Joins: hayato_ (~hayato@public.cloak)
# [05:06] <SimonSapin> leaverou: the way this will be done in Regions is through pseudo-elements?
# [05:06] <SimonSapin> fantasai: yes
# [05:06] <SimonSapin> leaverou: but @page rules are more concise
# [05:06] <SimonSapin> leaverou: if you have a series of things that need to differ page page style, need to repeat the page selector
# [05:06] <TabAtkins> ".foo::region .bar" for .bars inside of the region hosted by .foo
# [05:06] <SimonSapin> fantasai: same problem with regions, we should solve this for all of the things
# [05:07] * heycam|away is now known as heycam
# [05:07] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [05:07] <SimonSapin> astearns: syntax for Regions has the constraint that it needs to fit in future nesting mechanisms that reduce repetion
# [05:07] * Joins: ChrisL (clilley@public.cloak)
# [05:07] <SimonSapin> leaverou: will this apply to all page selectors and combinations of those?
# [05:08] <SimonSapin> dauwhe_: I guess we just start trying things
# [05:08] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [05:08] * Joins: ChrisL (clilley@public.cloak)
# [05:08] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:08] <SimonSapin> plinss: trailing off, but not hearing any objection. Will follow the work on Regions
# [05:09] <SimonSapin> Bert: we have Dave editor of GCPM, I suggest we concentrate effort around Dave
# [05:09] <SimonSapin> Bert: see which things are already covered in Regions
# [05:09] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [05:09] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [05:09] * Joins: ChrisL (clilley@public.cloak)
# [05:09] * Quits: mgylling_ (~mgylling@public.cloak) (mgylling_)
# [05:10] <dbaron> Why do we want to push this into GCPM?
# [05:10] * r12a-limechat is now known as r12a
# [05:11] <dbaron> [minute taker fell off IRC]
# [05:11] * Joins: kawabata2 (~kawabata@public.cloak)
# [05:11] * Joins: ChrisLilley (clilley@public.cloak)
# [05:11] * Quits: emalasky1 (~Adium@public.cloak) (Client closed connection)
# [05:11] * Joins: emalasky (~Adium@public.cloak)
# [05:11] <dino> ScribeNick: dino
# [05:11] * Quits: naka_ (~naka@public.cloak) (Ping timeout: 180 seconds)
# [05:12] * Quits: ijongcheol (~ijongcheol@public.cloak) (Client closed connection)
# [05:12] <dino> Bert: People should meet informally to discuss the next steps
# [05:12] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [05:12] <dino> plinss: I don't have an issue with David taking this on. Some people have suggested a page layout task force so it doesn't take up much of the group's time
# [05:13] <dino> plinss: i don't want to continue dumping "all the things" into GCPM
# [05:13] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [05:13] <dbaron> +1 to plinss
# [05:13] * Joins: ChrisLilley (clilley@public.cloak)
# [05:13] <dino> dbaron: i'd be inclined that this deserves it's own module
# [05:13] <dino> astearns: or a new level of paged media
# [05:13] <dino> plinss: possible
# [05:13] <dino> Rossen_: what happened to the one daniel was starting in Lyon?
# [05:14] <dino> Rossen_: sounds like the same conversation we've already had
# [05:14] <dino> SimonSapin: he has a proposal for the future of paged media
# [05:14] <dino> (on dev.w3.org)
# [05:14] <dbaron> http://dev.w3.org/csswg/css-page-4/
# [05:14] * Quits: myakura_ (~myakura@public.cloak) (Client closed connection)
# [05:15] <dino> plinss: Dave, are you willing to champion the work?
# [05:15] <dino> dauwhe_: yes
# [05:15] <dino> SimonSapin: We discussed two things: one of which lea asked (styling elements based on page location), and better page selectors (which is in the paged media spec)
# [05:15] * Quits: silvia (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [05:15] <dino> plinss: also need to expand on "spreads"
# [05:16] <dino> --- LUNCH BREAK ---
# [05:16] <dino> hold the lunch break
# [05:16] <dino> r12a: are you going to discuss CSS Text?
# [05:16] <dino> plinss: we deferred because fantasai needed to prepare
# [05:16] <dino> fantasai: i can maybe work on it during lunch
# [05:16] <dino> fantasai: agenda+ backgrounds and borders?
# [05:17] <dino> plinss: ok
# [05:17] <dino> dbaron: agenda+ one thing about charter?
# [05:17] <dino> plinss: let's do this now
# [05:17] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [05:17] <dino> Topic: Charter stuff again
# [05:17] <dino> dbaron: comment about async participation
# [05:18] <dino> dbaron: many WGs have requirements about async decision making. e.g. WebApps, a bunch of related API groups, and HTML (but that is a special snowflake)
# [05:18] * dauwhe_ more avalanche than snowflake
# [05:18] <dino> dbaron: i don't necessarily want to force the async decision making policy here, but I would like to see us try to make async decisions more often
# [05:19] <dino> dbaron: async == decisions are not generally taken in a meeting like a vote. rather the chair sends the notification via email, people can object before some time period elapses.
# [05:19] * Quits: ijongcheol (~ijongcheol@public.cloak) (Ping timeout: 180 seconds)
# [05:19] <TabAtkins> Async decision-making will likely speed up a lot of decisions, too. No need to wait for a slot during telcon, potentially getting bumped multiple weeks.
# [05:19] <dino> dbaron: i often find myself unsure whether or not to object within 10s at a meeting. I think it leads to decisions made with more consideration.
# [05:20] <dino> s/think it/think async/
# [05:20] <dino> dbaron: what do other people think?
# [05:20] <dino> ChrisLilley: on the one hand...
# [05:21] <astearns> TabAtkins: +1
# [05:21] <dino> ChrisLilley: that can be a benefit... e.g. Tab isn't here and he needs 48 hours to object..
# [05:21] <dino> ChrisLilley: but i don't want to be in the situation where we're waiting for people to read the notification, stall, etc
# [05:21] <dino> ChrisLilley: how is it working in other groups?
# [05:22] <dino> dbaron: one of the important points is that these groups are not making the decision EVER on the telcon, but everything is on the mailing list
# [05:22] <dino> dbaron: the forcing function is sometimes useful. i don't participate in these groups, but i've heard it is working well
# [05:22] <dino> steveZ: also allows people not on telcons to get involved
# [05:23] <dino> SteveZ: the notification needs to be clear what the decision will be
# [05:23] <dino> israelh: in webapps, i've noticed that sometimes the decision thread doesn't really give you a clear outcome, and we still need to come together on a call to make the final final final decision. how do you figure out what the tiebreaker is?
# [05:24] <dino> kennyluck: it's often dependent on the type of decision: publishing a spec vs technical decisions
# [05:24] <dino> plinss: in general all i care about is making good decisions
# [05:25] <dino> plinss: i'm ok with whatever technique we use to get to that point
# [05:25] <dino> plinss: i'll note that we often do async because we know someone is not yet ready/present.
# [05:25] <kennyluck> My point is that I don't know who can send CfCs. Everyone?
# [05:25] <dino> plinss: dbaron, are you encouraging us to do it more?
# [05:25] <dino> dbaron: yes, do it more
# [05:26] <dino> krit: so will it be all decisions, or will we still need f2f meetings?
# [05:26] <dino> astearns: I think people will get comfortable will asking more time.
# [05:27] <dino> plinss: yes, to be clear, all WG members are free to ask for more time or open something if it is an error
# [05:27] * Joins: plh (plehegar@public.cloak)
# [05:27] <fantasai> plinss: we've never refused such a request
# [05:28] <dino> zcorpan: i think async works pretty well. but if there is a situation where we can make a decision now, that should be available, just not the common case.
# [05:28] <dino> krit: I'm asking for whether all decisions must be made at telcons, or if the mailing list was enough
# [05:28] <dino> dbaron: mailing list would be enough
# [05:28] <dino> sgalineau: agreed
# [05:28] <dino> plinss: do we want to put this in the charter?
# [05:29] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [05:29] <dino> dbaron: some other groups have it in the charter. i don't think we need it that formal, but we should move in that direction
# [05:29] <dino> SteveZ: should we put that it is allowed into the charter?
# [05:29] <dino> dbaron: maybe
# [05:29] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [05:29] <dino> SteveZ: maybe it should be listed as a process to stop people objecting to the process
# [05:30] <dino> astearns: there is nothing in the charter that says all decisions require a quorum, so we're not explicit
# [05:30] <dino> SteveZ: i would like to understand the rules
# [05:30] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [05:30] <kennyluck> +1 to SteveZ
# [05:31] <dino> krit: dbaron, could you send a proposal to the mailing list?
# [05:31] <dino> dbaron: yes
# [05:31] * dauwhe_ documenting the process would be helpful for new members
# [05:31] <dino> SimonSapin: good q on irc, who can ask for a decision on the mailing list?
# [05:31] <dino> fantasai: it should always come from the chairs
# [05:32] <dino> plinss: i don't think we should say that we're going to do everything this way. Some things might be better this way, others might not.
# [05:32] <dino> plinss: anyone can always ask the chairs to adjust the way we work, even for a particular issue
# [05:32] <dino> plinss: fear is that we'll be making decisions by defualt because people are not participating
# [05:33] <dino> astearns: it will be interesting to see how many bad decisions we've had to back out because no one participated
# [05:33] <dino> plinss: maybe it will be better if the email is clear what the decision will be
# [05:33] <dino> plinss: we'll probably have to have discussion about what the proposed decision will be
# [05:33] <sgalineau> +1. straw polling rarely works over email. better make a call to force feedback.
# [05:34] <dino> dbaron: i think it works for "can we publish"
# [05:34] <dino> SimonSapin: i don't think this is about taking options away
# [05:34] <dino> plinss: agreed.
# [05:34] * Quits: kurosawa (~kurosawa@public.cloak) (Ping timeout: 180 seconds)
# [05:35] <dino> ACTION: dbaron to send a proposal for async decisions
# [05:35] * RRSAgent records action 2
# [05:35] * trackbot is creating a new ACTION.
# [05:35] <trackbot> Created ACTION-596 - Send a proposal for async decisions [on David Baron - due 2013-11-19].
# [05:35] <sgalineau> sp the conclusion is that we'll discuss this on the mailing list….
# [05:35] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [05:35] * Quits: bobby (~bobby@public.cloak) (bobby)
# [05:35] <dino> --- REALLY LUNCH BREAK ---
# [05:35] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [05:35] * Quits: dino (~dino@public.cloak) (dino)
# [05:35] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [05:35] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [05:35] <TabAtkins> When is lunch til?
# [05:35] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [05:35] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [05:35] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [05:35] <TabAtkins> 1?
# [05:35] <TabAtkins> Nah, that's in half an hour.
# [05:36] <fantasai> between 1:30 and 2
# [05:36] * Joins: cwdoh (~cwdoh@public.cloak)
# [05:36] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [05:36] <fantasai> TabAtkins: depending on cafeteria lines
# [05:36] <fantasai> TabAtkins: How about I'll text you if we get back before 2?
# [05:36] <TabAtkins> kk
# [05:36] * Quits: jet (~junglecode@public.cloak) (jet)
# [05:36] * Joins: glenn (~gadams@public.cloak)
# [05:36] * leaverou is now known as leaverou_away
# [05:37] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [05:37] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [05:39] * Quits: rhauck2 (~Adium@public.cloak) (Client closed connection)
# [05:39] * Quits: satakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [05:39] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [05:39] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [05:39] * Quits: zqzhang (~zqzhang@public.cloak) (Ping timeout: 180 seconds)
# [05:39] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [05:40] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [05:41] * Quits: zhouchao (~zhouchao@public.cloak) (Ping timeout: 180 seconds)
# [05:41] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [05:42] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [05:43] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [05:43] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [05:44] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [05:47] * Joins: silvia (~Adium@public.cloak)
# [05:48] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [05:50] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
# [05:50] * Joins: simonstewart (~simonstewart@public.cloak)
# [05:54] * heycam is now known as heycam|away
# [05:55] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [05:57] * Joins: mgylling (~mgylling@public.cloak)
# [05:57] * Quits: simonstewart (~simonstewart@public.cloak) (Ping timeout: 180 seconds)
# [06:07] * Joins: jehoochen__ (~jehoochen@public.cloak)
# [06:14] * Quits: tobie (tobie@public.cloak)
# [06:18] * Joins: silvia1 (~Adium@public.cloak)
# [06:18] * Quits: silvia (~Adium@public.cloak) (Client closed connection)
# [06:22] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:22] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [06:24] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [06:24] * Quits: ijongcheol (~ijongcheol@public.cloak) (Client closed connection)
# [06:25] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [06:27] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:28] * Joins: bobby (~bobby@public.cloak)
# [06:29] * Joins: tobie (tobie@public.cloak)
# [06:32] * Quits: ijongcheol (~ijongcheol@public.cloak) (Ping timeout: 180 seconds)
# [06:33] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [06:34] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:34] * Joins: mgylling (~mgylling@public.cloak)
# [06:35] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [06:36] * Joins: kurosawa (~kurosawa@public.cloak)
# [06:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:36] * Joins: dbaron (~dbaron@public.cloak)
# [06:36] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [06:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [06:37] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [06:39] * Joins: mgylling_ (~mgylling@public.cloak)
# [06:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:41] * Joins: zqzhang_ (~zqzhang@public.cloak)
# [06:41] * Quits: mgylling (~mgylling@public.cloak) (Ping timeout: 180 seconds)
# [06:41] * mgylling_ is now known as mgylling
# [06:41] * Joins: jet (~junglecode@public.cloak)
# [06:42] * Joins: rhauck (~Adium@public.cloak)
# [06:42] * Joins: dino (~dino@public.cloak)
# [06:42] * Quits: silvia1 (~Adium@public.cloak) (Client closed connection)
# [06:42] * Joins: silvia (~Adium@public.cloak)
# [06:42] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [06:43] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [06:43] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [06:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:43] * Joins: lmcliste_ (~lmclister@public.cloak)
# [06:44] * Joins: cyril (~cyril@public.cloak)
# [06:44] * Joins: silvia1 (~Adium@public.cloak)
# [06:44] * Quits: silvia (~Adium@public.cloak) (Client closed connection)
# [06:44] * Joins: myakura (~myakura@public.cloak)
# [06:47] * Joins: rhauck (~Adium@public.cloak)
# [06:48] * Joins: rhauck1 (~Adium@public.cloak)
# [06:49] * Quits: bobby (~bobby@public.cloak) (Ping timeout: 180 seconds)
# [06:49] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [06:49] * Joins: rhauck2 (~Adium@public.cloak)
# [06:50] * Joins: glenn (~gadams@public.cloak)
# [06:53] <dauwhe_> waiting for everyone to get back from lunch
# [06:53] * Joins: hayato_ (~hayato@public.cloak)
# [06:54] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [06:54] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [06:54] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [06:55] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [06:56] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [06:56] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [06:57] * Joins: shepazu (schepers@public.cloak)
# [06:58] * Joins: kennyluck (~kennyluck@public.cloak)
# [06:58] * Joins: emalasky (~Adium@public.cloak)
# [06:59] * Joins: satakagi (~stakagi@public.cloak)
# [07:00] * Quits: jehoochen__ (~jehoochen@public.cloak) (Ping timeout: 180 seconds)
# [07:01] * Joins: simonstewart (~simonstewart@public.cloak)
# [07:01] * TabAtkins is back too.
# [07:02] * Joins: israelh (~israelh@public.cloak)
# [07:02] * Joins: mz-modeltaxi (~mz_modeltaxi@public.cloak)
# [07:03] * Joins: nikos (~Thunderbird@public.cloak)
# [07:03] * mz-modeltaxi is now known as danielkim
# [07:03] * Joins: nsakai2 (~nsakai2@public.cloak)
# [07:03] * Joins: emalasky1 (~Adium@public.cloak)
# [07:03] * Joins: birtles_ (~chatzilla@public.cloak)
# [07:03] * Joins: bobby (~bobby@public.cloak)
# [07:04] * Joins: heycam` (~cam@public.cloak)
# [07:04] <heycam`> Scribe: Cameron
# [07:04] <heycam`> ScribeNick: heycam
# [07:04] <krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#security
# [07:04] <heycam`> Topic: Filter Effects
# [07:04] <heycam`> krit: last time we talked about having a security issues section
# [07:04] <heycam`> ... roc had some concerns about the security model we had
# [07:04] <heycam`> ... hwe asked me to write it
# [07:04] <heycam`> ... this is not just for custom filters
# [07:04] * Joins: Rossen_ (~Rossen@public.cloak)
# [07:04] <heycam`> ...but also some other issues, such as element() function
# [07:05] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [07:05] <heycam`> ... SVG filters have an issue where you can get certain data about the pixels that you filter
# [07:05] <heycam`> ... timing attacks
# [07:05] * Joins: sgalineau (~sgalineau@public.cloak)
# [07:05] <heycam`> ... with normal SVG filter functions
# [07:05] <fantasai> >
# [07:05] <heycam`> ... feDisplacementMap you can cause different timing behaviours depending on pixel values you get
# [07:05] <heycam`> ... we came up with that we taint certain filter primtiives that have reference to user data
# [07:06] <heycam`> ... with feImage, all of the filter sources like SourceGraphic
# [07:06] <heycam`> ... all of these primtiives that take pixel colour that can be affected by the color proprerty are tainted
# [07:06] <heycam`> ... once feDisplacementMap takes such an input, it is tainted
# [07:07] <heycam`> ... some people already reviewed this section, some people at Google and Mozilla
# [07:07] <heycam`> ... roc and heycam kind of looked at it
# [07:07] <heycam`> ... Steven White from Google
# [07:07] <heycam`> ... I think the security section as it is now is OK, but would like wider review, so I'd like to publish a new WD
# [07:07] <heycam`> ... do both WGs support publishing a new WD?
# [07:07] <heycam`> ed: any objections to publishing a new WD?
# [07:07] <heycam`> ... none heard
# [07:08] <heycam`> RESOLUTION: CSS/SVG agree to publish a new WD of FIlter Effects
# [07:08] <heycam`> ed: can we limit this to taining only when use use the color property, or does it have to be for elements in any case?
# [07:08] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [07:08] <heycam`> krit: it's not easy to determine where you get the colour from
# [07:08] <heycam`> ... so I'd rather be more restrictive
# [07:09] <heycam`> ... there are some issues in the spec, SVG specific -- we can discuss them in the SVG WG meeting
# [07:09] <heycam`> Topic: CSS Transforms
# [07:09] <heycam`> krit: for CSS ramsforms, one thing missing is the property definitions
# [07:09] <heycam`> ... we did not specify what the value of these properties means
# [07:09] <heycam`> ... this is now in the Transforms spec
# [07:10] <heycam`> ... a lot of things were clarified, e.g. with transform-origin and perspective
# [07:10] <heycam`> ... there are still some open issue, esp with 3D transforms
# [07:10] <ed> http://dev.w3.org/csswg/css-transforms/
# [07:10] <heycam`> ... smfr is reviewing some of my tests
# [07:10] <heycam`> ... I would like to write more tests, and discuss them in January
# [07:10] <heycam`> ... also new in the spec is a new decomposing model for matrices
# [07:10] <heycam`> ... dbaron found that matrix decompoosing works differently between safari and other browsers
# [07:10] <heycam`> ... dino took an action to review the source code, and I've added the decomposing code to the spec
# [07:11] <heycam`> ... again would like wider review of these things, so would like a new WD of CSS Transforms
# [07:11] * Joins: jehoochen__ (~jehoochen@public.cloak)
# [07:11] <heycam`> ed: any objections to publishing a WD?
# [07:11] <heycam`> ... none heard
# [07:11] <heycam`> RESOLUTION: We will publish a new WD of CSS Transforms.
# [07:11] <heycam`> Topic: Geometric API spec
# [07:11] <heycam`> s/Geometric/Geometry/
# [07:12] <heycam`> krit: simon pieters added new types to the CSSOM View spec
# [07:12] * Joins: kawabata2 (~kawabata@public.cloak)
# [07:12] <heycam`> ... DOMPoint, DOMRect, DOMQuad and DOMRectList
# [07:12] <astearns> https://dvcs.w3.org/hg/FXTF/raw-file/tip/geometry/Overview.html
# [07:12] <heycam`> ... all these interfaces are now joined with DOMMatrix into the one spec
# [07:12] <heycam`> ... if you look at the interfaces, you see them there in the draft
# [07:12] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [07:12] <heycam`> ... we're not asking for FPWD at this point
# [07:12] * Joins: dwim (~dwim@public.cloak)
# [07:13] <heycam`> ... what I'd like to discuss or mention is the model of the interface structure
# [07:13] * Joins: dbaron (~dbaron@public.cloak)
# [07:13] <heycam`> ... we had long discussions about r/o interfaces, and ones which are r/w
# [07:13] * Joins: hayato_ (~hayato@public.cloak)
# [07:13] * Joins: rayberg_ (~rayberg@public.cloak)
# [07:13] <heycam`> ... we had concerns on the ML about having interfaces that are sometimes readable sometimes not
# [07:13] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [07:13] <heycam`> ... the general agreement was not to have these kinds of interfaces in hte future
# [07:14] <heycam`> ... there was a need for DOMRect etc. to have read-only APIs for SVG DOM, and some CSSOM View APIs
# [07:14] <heycam`> ... but we want to have them writable so you can do something useful with them
# [07:14] <heycam`> ... there were different solutions on the ML
# [07:14] <heycam`> ... none were really sufficient
# [07:14] * Joins: emalasky (~Adium@public.cloak)
# [07:14] <heycam`> ... the one that was accepted was having a readable interface as a base interface, and a writable one inheriting from that
# [07:14] <heycam`> ... initially we called the parent interface DOM*ReadOnly, which is foncusing
# [07:14] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:15] <heycam`> ... doing 'instanceof DOMRectReadOnly' would return true even for a writable DOMRect
# [07:15] * Joins: cwdoh (~cwdoh@public.cloak)
# [07:15] <heycam`> ... we discussed in Web Apps WG yesterday, and we at least agreed that the inheritance structure is the best of the proposals we have so far
# [07:15] <heycam`> ... some concerns about using "View" name
# [07:15] <dauwhe_> s/foncusing/confusing/
# [07:15] <heycam`> ... other than that, most people agreed on the naming scheme
# [07:15] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [07:15] <heycam`> ... so this is what will be in the spec
# [07:15] <heycam`> ... I'd also like to discuss some issues
# [07:16] <heycam`> ... first is with SVGPoint
# [07:16] <heycam`> ... we mentioned before DOMRect, DOMRectList (which is needed in CSSOM View)
# [07:16] * Joins: r12a (rishida@public.cloak)
# [07:16] <heycam`> simon: CSSOM View references the GEometry spec for DOMRectList
# [07:16] <TabAtkins> zcorpan_: Yo, several of your IDL interface defs are linking back to CSSOM, which just says that they're defined in Geometry. To force Bikeshed to mark something up as a definition, add dfn-force='' to the <pre>.
# [07:16] <heycam`> krit: SVG has SVGPoint interface we'd like to replace with DOMPoint
# [07:16] <heycam`> ... we also have an SVGPointList
# [07:16] <heycam`> ... compared to DOMRect, do we also want a DOMPoint list?
# [07:16] * Quits: bobby (~bobby@public.cloak) (bobby)
# [07:16] <TabAtkins> Like <pre class=idl dfn-force="DOMPoint DOMPointInit">...</pre>
# [07:16] <heycam`> ... or just recereate SVGPointList and keep that SVG-specific for now
# [07:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:17] <heycam`> doug: is there any evidence that people are using the SVGPointList interface in the wild?
# [07:17] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [07:17] <heycam`> krit: no
# [07:17] <heycam`> ... well that's not fully true
# [07:17] <heycam`> ... there are libraries using the SVG DOM interfaces
# [07:17] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [07:17] <TabAtkins> Is DOMRectList actually needed, or is it just used in the existing IDL and we're keeping it?
# [07:17] * Quits: silvia1 (~Adium@public.cloak) (Client closed connection)
# [07:17] <heycam`> ... Snap SVG for example
# [07:17] <TabAtkins> We should try to migrate it to an Array if possible.
# [07:18] <heycam`> ... he's at least using SVG DOM, not sure if he's using SVGPointList
# [07:18] <heycam`> doug: could somebody at Adobe look into that?
# [07:18] <heycam`> ... I personally think we should de-SVG all the things
# [07:18] <heycam`> ... I think we should do what makes more sense for long term, not for backwards compat with SVG
# [07:18] <heycam`> simon: in general, when adding new list-y things, we try to use a JS Array
# [07:18] <slightlyoff> why the hell aren't any of these things constructable?
# [07:18] <heycam`> ... which can be represented in several ways in WebIDL now
# [07:18] <slightlyoff> and why aren't they just JS arrays?
# [07:19] <SimonSapin> s/simon/zcorpan/
# [07:19] <heycam`> slightlyoff: it's our plan to
# [07:19] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:19] <heycam`> slightlyoff: see also my SVG DOM improvement proposal
# [07:19] <slightlyoff> heycam`: ok, that's good, 'cause this is depressing: http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGPointList
# [07:19] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [07:19] <TabAtkins> slightlyoff: Don't want Points/etc to be just arrays. The Lists, yes, that's what I (and now zcorpan) just said.
# [07:19] <astearns> no instances of SVGPointList in snap source
# [07:20] <heycam`> http://dev.w3.org/SVG/proposals/improving-svg-dom/
# [07:20] <slightlyoff> TabAtkins: yes, was referring to the lists
# [07:20] <heycam`> krit: is SVGPointList already compatible with the new ideas in Web IDL?
# [07:20] * Quits: emalasky1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [07:20] * Joins: leif (~lastorset@public.cloak)
# [07:20] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:20] * Quits: danielkim (~mz_modeltaxi@public.cloak) (Client closed connection)
# [07:21] <heycam`> heycam: I didn't change anything with SVGPointList apart from adding indexed properites and lngth property
# [07:21] <heycam`> ... which implementations already support
# [07:21] <slightlyoff> it'd be much better if there were an svg.* object instead of all of the SVG* prefixing = \
# [07:21] * Joins: danielkim (~mz_modeltaxi@public.cloak)
# [07:21] <heycam`> krit: so I think we should not create a new DOMPointList interface
# [07:22] <heycam`> doug: we should do whatever is best for the longer m, and not feel constained by the previous specs
# [07:22] <heycam`> ... since SVGPointList is not really used
# [07:22] <TabAtkins> slightlyoff: SVG.*. Uppercase for great justice! (And better author-collision avoidance.)
# [07:22] <slightlyoff> TabAtkins: !?!!!?
# [07:22] <slightlyoff> TabAtkins: seriously...that's O_o
# [07:22] <dbaron> So what happened regarding the third (immutable) rect type in http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0045.html ?
# [07:22] <TabAtkins> Um.
# [07:22] <dbaron> did that get dropped?
# [07:22] <TabAtkins> We always uppercase interfaces.
# [07:23] <slightlyoff> TabAtkins: I mean, eventually you'll want this this stuff to be an ES6 module, right?
# [07:23] <TabAtkins> Sure, yeah.
# [07:23] <slightlyoff> TabAtkins: fine for the interfaces, but putting the interfaces in a single object instead of in the global
# [07:23] <TabAtkins> A namespacing interace is just a shitty module.
# [07:23] <slightlyoff> TabAtkins: that was the "." in my "svg.*"
# [07:23] <TabAtkins> ...I know.
# [07:23] <TabAtkins> We already have window.CSS for the same thing.
# [07:23] <heycam`> heycam: depends on what we do with the grand SVG DOM rethinking
# [07:23] <slightlyoff> TabAtkins: beats the dihereah ya'll have going on here
# [07:24] * leaverou_away is now known as leaverou
# [07:24] * Joins: bobby (~bobby@public.cloak)
# [07:24] <TabAtkins> l2spell ^_^
# [07:24] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [07:25] <heycam`> krit: I would like to remove the issue about clarifying whether DOMPointList is needed or not
# [07:25] * Joins: danielki_ (~mz_modeltaxi@public.cloak)
# [07:25] <heycam`> ... because I think it's not
# [07:25] * Quits: danielkim (~mz_modeltaxi@public.cloak) (Client closed connection)
# [07:26] <heycam`> heycam: I agree
# [07:26] <TabAtkins> +1
# [07:26] <heycam`> RESOLUTION: Don't create a new DOMPointList; try to use Arrays if we need something like that.
# [07:27] <heycam`> krit: second I'd like to discuss is SVGPOint has a function matrixTransform
# [07:27] <heycam`> ... should we have that on DOMPoint
# [07:27] <heycam`> ... you can pass a DOMMatrix into it, and it will transform the coordinates of the point and return a new one
# [07:27] <heycam`> simon: isn't that covered by the new Geometry stuff in CSS OM View?
# [07:28] <heycam`> ... oh, it's not the same -- was thinking of convertPointFromNode
# [07:28] <heycam`> krit: the Matrix that is already shipping in Safari/Blink/IE, prefixed, has a function transformPoint
# [07:28] <heycam`> ... it's on DOMMatrix
# [07:28] * shepazu please post a link to CSS OM View
# [07:28] <heycam`> ... SVG put this function on SVGPoint
# [07:28] <heycam`> ... it would be duplication to have in both places
# [07:28] <TabAtkins> http://dev.w3.org/csswg/cssom-view
# [07:29] <heycam`> ... the qn is should we have it for SVG, or can we live with removing it?
# [07:29] <heycam`> ed: my guess is content would break if we remove it
# [07:29] <heycam`> dino: I think we should leave it off
# [07:29] <heycam`> ... DOMPoint doesn't have any methods currently
# [07:29] <heycam`> ed: how do you suggest to resolve the SVGPoint issue? not care about it?
# [07:29] <heycam`> dino: yeah
# [07:29] <heycam`> simon: it might make sense to check how much the function is used in the wild
# [07:29] <heycam`> ... if it's used quite a bit, we might need to retain it as a quirk
# [07:30] <heycam`> ... otherwise remove it
# [07:30] <heycam`> krit: how do we get this data?
# [07:30] * shepazu thanks TabAtkins
# [07:30] <heycam`> simon: we could add in a use counter to blink
# [07:30] <heycam`> ... or research content or something
# [07:30] <slightlyoff> why are all of these things marked readonly?
# [07:30] <slightlyoff> http://dev.w3.org/fxtf/geometry/#DOMPoint
# [07:30] * Joins: myakura (~myakura@public.cloak)
# [07:30] <heycam`> dino: there are plenty of ways this API could break
# [07:30] <heycam`> krit: with the exception of this function, content would not break
# [07:31] * Joins: silvia (~Adium@public.cloak)
# [07:31] <heycam`> ... I would be fine with keeping this issue open, waiting for better data
# [07:31] <heycam`> ... we could ask Blink people to check
# [07:31] <heycam`> ACTION: Erik to add a use counter for SVGMatrix.transformPoint
# [07:31] * trackbot is creating a new ACTION.
# [07:31] <trackbot> Error finding 'Erik'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [07:31] * RRSAgent records action 3
# [07:32] <heycam`> dino: D3 uses Point.matrixTransform
# [07:32] <shepazu> q+ to ask about intersections
# [07:32] * Zakim sees dauwhe_, shepazu on the speaker queue
# [07:32] <dauwhe_> q-
# [07:32] * Zakim sees shepazu on the speaker queue
# [07:32] <heycam`> action should be about SVGPoint.matrixTransform
# [07:32] * trackbot is creating a new ACTION.
# [07:32] <trackbot> Error finding 'should'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [07:33] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [07:33] * Quits: tobie (tobie@public.cloak)
# [07:33] <heycam`> doug: one thing I wanted frmo a Geometry API for 13 years is the ability to get intersections between shapes
# [07:34] <heycam`> ... have you put any thought into that?
# [07:34] <heycam`> krit: no
# [07:34] <heycam`> doug: do
# [07:34] <heycam`> krit: I would like the community group to come up with some proposals
# [07:34] <slightlyoff> again, why is all of this stuff readonly?
# [07:34] <heycam`> doug: interesctions are useful for a bunch of things
# [07:34] <heycam`> simon: would like to see use cases
# [07:35] <heycam`> doug: there is a script librrary out there that kidn of does intersections
# [07:35] <heycam`> ... by kevin lindsey
# [07:35] * ed created https://www.w3.org/Graphics/SVG/WG/track/actions/3534 for the matrixTransform issue
# [07:35] <heycam`> ... I talked with him about that; he said many of the pieces are hacky and hard to do in JS
# [07:35] <heycam`> ... you can't get certain kinds of intersections
# [07:35] <TabAtkins> slightlyoff: It's not readonly. There are readonly *variants* of th einterfaces, for various uses in APIs.
# [07:35] <heycam`> dino: I disagree
# [07:36] <TabAtkins> But they all have mutable versions too.
# [07:36] <heycam`> ... when we proposed the matrix api there was pushback from developers making a point that every time you cross the boundary from JS to native code, you get a performance hit
# [07:36] <slightlyoff> TabAtkins: where are those?
# [07:36] <heycam`> ... in many cases you want to leave things in JS so people can pick the impl they want
# [07:36] <TabAtkins> Right there, in the spec next to the other ones?
# [07:36] <heycam`> ... with intersections, you want them for physics lirbaryies or ...
# [07:36] <slightlyoff> TabAtkins: not seeing mutable version here: http://dev.w3.org/fxtf/geometry/#DOMPoint
# [07:36] <heycam`> ... and they're hand tuned
# [07:36] <slightlyoff> oooh...I see
# [07:36] <heycam`> ... might be better to leave them to JS to see what comes up
# [07:36] <TabAtkins> slightlyoff: The DOMPoint interface is mutable.
# [07:36] <slightlyoff> what's the reason to have the readonly version at all?
# [07:37] <heycam`> ... JS performance is good
# [07:37] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [07:37] * Joins: plh (plehegar@public.cloak)
# [07:37] <heycam`> ... getting fast access to geometry data of SVG could be useful
# [07:37] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [07:37] <heycam`> ... doign intersections in a physics library, you might want to intersect with approximations of a shape, not the accurate actual shapes
# [07:37] <TabAtkins> Because you need readonlys for APIs at various times. Plenty of times you're exposing a point on some interface, and it's not meant to be mutable, or mutating it won't do anything.
# [07:37] <heycam`> krit: there's no JS library that does it completely?
# [07:37] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [07:37] * Joins: silvia1 (~Adium@public.cloak)
# [07:37] <heycam`> ... so it's less likely we can do it in a reasonable amount of time
# [07:37] <TabAtkins> In other words, same reason to have the "readonly" keyword in any situation?
# [07:38] * Joins: silvia2 (~Adium@public.cloak)
# [07:38] <heycam`> heycam: I think it's just as easy/hard in JS as C++
# [07:38] <TabAtkins> Hanging mutable-but-useless attributes off an interfaces is a bad idea. Should either be readonly, or should be a method that returns an object, or should be mutable and live. Pick one.
# [07:38] <TabAtkins> (Apparently the last one is usually bad.)
# [07:39] <slightlyoff> TabAtkins: I'm really unsure why "mutating it wouldn't do anything" is anything other than "it wasn't defiend with an accessor pair, so c'est la vie"
# [07:39] <heycam`> doug: is the cost between JS->native more expensive than doing the operations in JS itself?
# [07:39] <heycam`> dino: I expect you'll be better off leaving it in JS
# [07:39] * Joins: silvia3 (~Adium@public.cloak)
# [07:39] <slightlyoff> TabAtkins: the idea that you should be locking things down is just odd
# [07:39] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [07:39] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [07:39] <heycam`> ... there's also a cost doing it in JS -- nobody else has done it other than Kevin since it's hard
# [07:39] <heycam`> rik: Raphael does it
# [07:39] * Joins: dwim (~dwim@public.cloak)
# [07:39] <heycam`> doug: there's a download cost too
# [07:39] <TabAtkins> slightlyoff: What happens when you mutate a point on a DOMRect? It magically becomes a DOMQuad? It just starts wildly violating rect-based assumptions?
# [07:39] <heycam`> ... is it a common enough case to put it in the browser
# [07:39] <heycam`> ... it's a CBA
# [07:40] <TabAtkins> DOMRect has a mutation API - mutate x/y/width/height.
# [07:40] <heycam`> ... we should do that, rather than just assume it's better to do in JS
# [07:40] <heycam`> ... Kevin is on the hook to put a proposal to the CG
# [07:40] <heycam`> krit: even if it's formalised in a draft, that'd be helpful
# [07:40] * Joins: lmcliste_ (~lmclister@public.cloak)
# [07:40] <slightlyoff> TabAtkins: it's JavaScript? You document your assumptions.
# [07:40] <heycam`> ... even if not implemented in a browser
# [07:40] <heycam`> ... last issue I want to discuss is ISSUE 5
# [07:40] <heycam`> ... DOMMatrix takes a string
# [07:40] <heycam`> ... from a CSS transform
# [07:40] * Parts: silvia3 (~Adium@public.cloak) (silvia3)
# [07:41] <heycam`> ... we agreed on this; only problem is whether this string needs to be strict CSS, or is a string from SVG trasnform="" attribute OK too
# [07:41] <TabAtkins> And your assumptions might be "this isn't how you mutate the object, it's just some useful info you can use. Accordingly, we're documenting it as readonly."
# [07:41] <heycam`> ... e.g. "transform(20,20)" -- CSS needs units, SG doesn't
# [07:41] <heycam`> s/SG/SVG/
# [07:41] <heycam`> ... would this string work passing it to DOMMatrix?
# [07:41] <heycam`> dino: yes
# [07:42] <heycam`> dbaron: I'm not crazy about implicit pixel units
# [07:42] <TabAtkins> I'm okay with accepting the looser SVG syntax, I think.
# [07:42] <slightlyoff> TabAtkins: I'm really just unsure what the case for this is aside from pre-emptive invariant preservation
# [07:42] * Quits: silvia (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [07:42] <slightlyoff> TabAtkins: most JS objects are mutable and the world is not, yet, on fire
# [07:42] <heycam`> ... where do these values go?
# [07:42] <heycam`> krit: it's a parameter to DOMMatrix constructor
# [07:42] <heycam`> dbaron: I guess I'm ok with it
# [07:43] <heycam`> ... it's reasonably isolated
# [07:43] <TabAtkins> slightlyoff: Again, it's identical to making literally anything else readonly. If you'd expose "readonly attribute double x; readonly attribute double y;", you can instead just expose "readonly attribute DOMPointReadonly;"
# [07:43] * Quits: kurosawa (~kurosawa@public.cloak) ("Page closed")
# [07:43] <heycam`> krit: need to time think about it more, or resolve?
# [07:43] <slightlyoff> TabAtkins: that's not a case for *if* it's something you should do, which is what I'm questioning
# [07:43] <heycam`> dino: leave it in, but leave in text saying "speak up if you disagree"
# [07:43] <heycam`> plinss: what's the point of this?
# [07:43] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [07:44] <heycam`> krit: if you have SVG transform="" attribute, it doesn't require px units
# [07:44] <heycam`> plinss: but you're not using this in an SVG context?
# [07:44] <heycam`> krit: you might
# [07:44] * Joins: cwdoh (~cwdoh@public.cloak)
# [07:44] * Quits: silvia1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [07:44] <TabAtkins> slightlyoff: Had this dicussion on the list before. Live objects are discouraged API design (prefer mutating methods). If an object isn't live, it probably shouldn't be mutable either - better author affordance.
# [07:45] * Joins: glazou (~glazou@public.cloak)
# [07:45] <slightlyoff> TabAtkins: this is alien to most JS practice
# [07:45] <TabAtkins> Otherwise, you mutate something, nothing happens, but now the attribute is lying.
# [07:45] * Joins: tobie (tobie@public.cloak)
# [07:45] * Quits: silvia2 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [07:45] <slightlyoff> TabAtkins: so whatever you might prefer from some other perspective, it's just not something I think these WGs should be worrying too much about
# [07:45] <TabAtkins> Sure, because readonly isn't easy to do in JS. Gotta screw around with getters.
# [07:45] <heycam`> heycam: you could say to authors to get the transform values from CSS APIs, which will have the units in there
# [07:45] <heycam`> krit: let's keep the issue in there for now
# [07:46] <heycam`> dbaron: one other question about the vairous rect types
# [07:46] <heycam`> ... earlier in the thread was a proposal for a type representing an immutable rect
# [07:46] <heycam`> ... did that go away?
# [07:46] <TabAtkins> Part of having an interface description language is being able to abstract some of the difficulties of the underlying implementation language, when it's useful to do so.
# [07:46] <heycam`> simon: there is a mutable DOMMrect
# [07:46] <heycam`> dbaron: in the url I pasted earlier, there was a proposal for three types
# [07:46] <heycam`> ... DOMREctView as a base type
# [07:46] <slightlyoff> TabAtkins: that doesn't make this design any less alien
# [07:46] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [07:46] <slightlyoff> TabAtkins: also, you don't need that, you only need a property descriptor
# [07:47] <heycam`> ... that you can't change, but may or may not be changing
# [07:47] * Joins: dwim (~dwim@public.cloak)
# [07:47] <heycam`> ... two derived types
# [07:47] <heycam`> ... one that you can change
# [07:47] <heycam`> .. and one known not to be changing
# [07:47] <TabAtkins> slightlyoff: Property descriptors are at least as fiddly as getters. ^_^
# [07:47] <heycam`> simon: that's what we have now, but the immutable is not used by anything
# [07:47] <heycam`> ... the View interface would get used for live reflections, but from script read only
# [07:47] <TabAtkins> slightlyoff: I don't think cleaving hard to the particular syntax affordances of JS is particularly important.
# [07:47] * Quits: bobby (~bobby@public.cloak) (bobby)
# [07:47] <heycam`> ... there are no objects known to be immutable
# [07:47] <heycam`> dbaron: but if there were you'd add a type?
# [07:47] <heycam`> simon: yes
# [07:48] <dbaron> heycam: or we could go down the road of having a frozen plain object for that
# [07:48] <slightlyoff> +1 to what heycam` said
# [07:48] <TabAtkins> Yeah, more freezing.
# [07:49] <heycam`> alex: until someone presents a compelling use case for the read only versions of these interfaces, seems better to have mutable versions
# [07:49] <heycam`> ... immutable is needed for perserving invaraints the system is sensitive to
# [07:49] <heycam`> ... but if not, preventing the user from modfiying it doesn't seem useful
# [07:49] <heycam`> ... immutability isn't buying anything in those cases
# [07:49] <heycam`> ... there's a generic argument here about it being a better documented pattenr, but I think that's outside the bounds of how you'd write these things in plain JS
# [07:50] <heycam`> simon: that's not a position that has been presented until today
# [07:50] <heycam`> ... it's good that you broughti t up
# [07:50] <TabAtkins> It buys us protection from "I'm reading these values, but they're not accurate!" (because somebody mistakenly mutated them before).
# [07:50] <heycam`> ... the group might need more time to ponder
# [07:50] <heycam`> dbaron: alex is arguing against the third type?
# [07:50] <heycam`> alex: and the View type
# [07:50] <dauwhe_> s/broughti t/brought it/
# [07:51] <TabAtkins> dbaron: Alex is arguing against all but the mutable types.
# [07:51] <heycam`> dbaron: I think one issue that makes rects difficult is that there are multiple ways -- do people want x/y/width/height, top/left/bottom/right, or other ways of looking at it?
# [07:51] <heycam`> ... one factor is if you're not providing mutability, it's easier to provide those views
# [07:51] <heycam`> ... but if it's mutable, you have to define how changing any of those views mean
# [07:51] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [07:51] <heycam`> alex: dont' think that's true
# [07:51] <heycam`> ... just have to define what the relationship between theo bjects is
# [07:52] <heycam`> ... if an object vends a rect, does it have reln?
# [07:52] * Quits: r12a (rishida@public.cloak) (Ping timeout: 180 seconds)
# [07:52] <heycam`> ... or is it just a copy that it's handing out?
# [07:52] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [07:52] <heycam`> ... that's what you're implicitly talking about
# [07:52] <heycam`> dbaron: there are rect apis that you want a mutable rect that maintains a reln with the thing that handed it out
# [07:52] <heycam`> ... one example is on a Quad
# [07:52] <heycam`> ... you want the minimal rect that bounds the quad as a property on the obejct
# [07:52] * Joins: bobby (~bobby@public.cloak)
# [07:52] <heycam`> ... you want it to always give you the same object, otherwise it would be confusing
# [07:53] <heycam`> ... so you want the object to maintain a reln with the quad that handed itout
# [07:53] <heycam`> ... don't want a new object each time you grab the property
# [07:53] <heycam`> plinss: if you mutate the rect do you get a new quad?
# [07:53] <heycam`> dbaron: you can't mutate the rect
# [07:53] <heycam`> ... there's no single mutation to the quad
# [07:53] <heycam`> plinss: so either you raise an execption, or it has no effect
# [07:53] <heycam`> dbaron: right, so in this case, the design is that it would be a DOMRectView
# [07:53] <heycam`> plinss: and you try to mutate it?
# [07:54] <heycam`> heycam: it'd throw a TypeError, no setter
# [07:54] <slightlyoff> I'm saying "just have setting the value do nothing in that case"
# [07:54] <heycam`> plinss: what's the diff between it throwing an exception instead?
# [07:54] <heycam`> simon: throwing an exception idea is what the spec had a first
# [07:54] <heycam`> ... a hidden flag that says "this object is read only"
# [07:54] <heycam`> ... this is what TC39 folks were objecting against
# [07:55] <heycam`> alex: now that we have getters/setters, with [[Writable]], it's easier to imagine plain JS coming up with htis design
# [07:55] * Quits: glazou (~glazou@public.cloak) ("bbl, heading to the office for a meeting")
# [07:55] <heycam`> ... dunno if that means if it's a good/bad API
# [07:55] <heycam`> ... is this idiomatic JS?
# [07:55] <heycam`> ... if setting the value is nonsensical?
# [07:56] <heycam`> ... why not have the object change in the bakground?
# [07:56] <heycam`> s/object/property?
# [07:56] <heycam`> ... why should we nail down the interfaces, when you wouldn't in JS?
# [07:56] * Quits: rayberg_ (~rayberg@public.cloak) (Ping timeout: 180 seconds)
# [07:56] <TabAtkins> You can't have the object change in the background (in at least some cases). (Unless I'm misreading the minutes.)
# [07:56] <heycam`> krit: would be great if you could raise these issues on public-script-coord
# [07:57] <heycam`> Topic: fill and stroke on text decorations
# [07:57] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
# [07:57] <heycam`> krit: hoped Tab would be here -- he could call in, or we could delay the topic
# [07:58] <TabAtkins> Calling in is a giant fail.
# [07:58] <TabAtkins> Never worked yesterday.
# [07:58] <heycam`> fantasai: haven't got around to adding it to the spec
# [07:58] * Joins: simonstewart (~simonstewart@public.cloak)
# [07:58] <heycam`> krit: fine to defer it
# [08:00] * Joins: r12a (rishida@public.cloak)
# [08:00] <fantasai> r12a, we'll want to discuss Text soon, let us know if that works for you or you have other constraints
# [08:00] <fantasai> kennyluck: ^
# [08:01] <fantasai> starting with css3-background for now
# [08:01] <heycam`> Topic: Background & Borders
# [08:01] * kennyluck coming
# [08:01] <heycam`> fantasai: we had some substantive edits to this over the last year
# [08:01] <heycam`> ... we wanted to publish a LCWD
# [08:01] <heycam`> ... get it back into CR after
# [08:01] <r12a> fantasai, ok heading down there
# [08:01] <heycam`> ... one other issue was raised -- two
# [08:01] * Joins: simonste_ (~simonstewart@public.cloak)
# [08:01] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [08:01] * Quits: simonste_ (~simonstewart@public.cloak) (Client closed connection)
# [08:01] <heycam`> ...andrew fedouniak raise an issue that if you have a spread radius on box shadow, and border radius is very small like 0.1, you run into rounding differences between implementations
# [08:02] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
# [08:02] <heycam`> ... because the spec says that at 0, the corners are sharp when you ahve a spread
# [08:02] <heycam`> ... if it's non-zero, the corners get curved by the radius
# [08:02] * Joins: simonstewart (~simonstewart@public.cloak)
# [08:02] * Parts: danielki_ (~mz_modeltaxi@public.cloak) (danielki_)
# [08:02] <heycam`> ... it wasn't the best idea to have discontinuous behaviour
# [08:02] <heycam`> ... but that's been in the spec for a while
# [08:02] * dbaron recalls raising this issue sometime previously, perhaps?
# [08:02] <heycam`> ... and implemented for a while
# [08:02] <heycam`> ... maybe have a none keyword for border-radius, and that would mean sharp corners -- that's the initial value
# [08:02] <heycam`> ... with 0 you could get the rounded behaviour
# [08:02] <TabAtkins> dbaron: Yeah, that led to the wiki page that now says "DON'T DO THIS".
# [08:03] <leaverou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0109.html
# [08:03] <heycam`> ... downsides of that is the initial value would be detectable in the OM
# [08:03] <heycam`> ... if somebdoy set border-radius to 0 and had a spread radius, their spread would no longer be square
# [08:03] <heycam`> ... 3rd detectable case is you can no longer animate from the initial value to some other border radius value
# [08:03] <heycam`> ... those are the 3 detectable diffeerences
# [08:03] <heycam`> ... leah and I both thought it would make sense tnot to make a change to the spec
# [08:03] <heycam`> ... wnat to see if the WG had other opinions
# [08:03] * Joins: jehoochen_ (~jehoochen@public.cloak)
# [08:03] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [08:04] <heycam`> dbaron: i would complain if we made the initial value not animatable
# [08:04] <heycam`> simon: if we do the keyword thing I don't understand why would couldnt animate it
# [08:04] <sgalineau> s/complain/jump up and down screaming
# [08:04] * Joins: kennyluck (~kennyluck@public.cloak)
# [08:04] <heycam`> dino: transition from none to 5?
# [08:04] <heycam`> simon: so?
# [08:04] <heycam`> ... waht's the difference now?
# [08:04] <heycam`> ... you can animate from a square to round
# [08:04] <heycam`> fantasai: this is the point
# [08:04] <heycam`> ... you can animate frmo 0, but 0 would no longer tbe hte initial value
# [08:04] <dauwhe_> s/frmo/from/
# [08:05] <heycam`> simon: we could specify that nimating from none would mean the same as 0
# [08:05] <heycam`> ... don't understand why that is impossible
# [08:05] * Joins: plh (plehegar@public.cloak)
# [08:05] * Joins: kurosawa (~kurosawa@public.cloak)
# [08:05] <dauwhe_> s/nimating/animating/
# [08:05] <heycam`> fantasai: you could say as soon as you step away from none, it can be animated
# [08:05] <heycam`> dbaron: I say this despite that spread is kind of silly, but we could make it continuous in other wways
# [08:05] <heycam`> ... e.g. we could say something like the amount of additional rounding you get --
# [08:05] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [08:06] <heycam`> ... normally the radius of curvature of the outer edge of the spread is the sum of the border radius and the spread value
# [08:06] <heycam`> ... so you get concentric circles or ellipses
# [08:06] <heycam`> ... you could intsead say that it is the max of that and double the border radius, or something like that
# [08:06] <heycam`> ... to cap that effect
# [08:06] <heycam`> ... and thus make it continuous
# [08:07] <heycam`> ... probably a bit silly though
# [08:07] <heycam`> fantasai: no comment on that...
# [08:07] <heycam`> plinss: I'd be in favour of an approach like david describes to avoid the discontinuity
# [08:07] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [08:07] <heycam`> ... don[t think we're helping anything by having none
# [08:07] <heycam`> ... still would be discontinuous as we step off it
# [08:07] <heycam`> leah: would be good to see some examples to see
# [08:08] <heycam`> ... I could make some
# [08:08] <dauwhe_> s/don[t/don't/
# [08:08] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [08:08] <heycam`> fantasai: let's say we can solve that problem
# [08:08] <dbaron> s/that/the animatable/
# [08:08] <heycam`> dbaron: I don't want to mess with the values of border-radius
# [08:08] <heycam`> ... I think it's important to leave them as they are, more improtant than any spread use case
# [08:08] <heycam`> ... the thing I'm proposing is purely related to spread
# [08:08] <heycam`> ... I think we should leave teh spec as it is
# [08:09] <heycam`> fantasai: any other comments on this?
# [08:09] * Quits: simonstewart (~simonstewart@public.cloak) (Ping timeout: 180 seconds)
# [08:09] <heycam`> krit: if we don't change the values, can we still animate it in the future?
# [08:09] <heycam`> fantasai: you can animte it today
# [08:09] <heycam`> krit: leave it to 4?
# [08:09] * Quits: jehoochen__ (~jehoochen@public.cloak) (Ping timeout: 180 seconds)
# [08:09] <heycam`> fantasai: we'd need to errata 3 in that case, as we're changing behaviour
# [08:10] * Joins: r12a (rishida@public.cloak)
# [08:10] <heycam`> bert: I have a strange idea for making it continuous
# [08:10] <heycam`> ... the outer edge of the spread, rather than making the corern the sum of the border-radius and spread, just make it the same as the border-radius
# [08:10] <heycam`> ... maybe looks too msall
# [08:10] <heycam`> leah: it would look horrible
# [08:10] * Quits: kurosawa (~kurosawa@public.cloak) ("Page closed")
# [08:10] <heycam`> ... ther was a bug in webkit
# [08:10] <heycam`> ... lots of complaints about it
# [08:10] * Quits: nikos (~Thunderbird@public.cloak) (nikos)
# [08:10] <leaverou> s/leah:/Lea:/
# [08:11] * heycam` notes that
# [08:11] <heycam`> dbaron: I think it's not that bad for large spreads, but just when the border radius is similar in magnitude or larger than the spread
# [08:12] <TabAtkins> Yeah, the "right" way to spread things is indeed to increase the radius by the amoutn of the spread. That's how you do curved borders, frex.
# [08:12] <heycam`> fantasai: one thing we can do is go make some examples, to show off your suggestion
# [08:12] <sgalineau> we can mitigate the discontinuity for some range of spreads; once a spread is large enough there will always be a point where the corner looks sharp and the spread rounded...
# [08:12] <heycam`> ... if that seems reasonable we can change how spread behaves near 0 border radii
# [08:12] <TabAtkins> (In reverse - the inner curve is equal to the outer curve minus the border width.)
# [08:12] <heycam`> ... or not make a change
# [08:12] <heycam`> fantasai: next issue was the expansion of shorthands
# [08:12] * Zakim heycam`, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:12] * Joins: kurosawa (~kurosawa@public.cloak)
# [08:12] <heycam`> [later]
# [08:12] <heycam`> Topic: css3-text
# [08:12] * Quits: kurosawa (~kurosawa@public.cloak) ("Page closed")
# [08:13] * TabAtkins wishes we could turn off whatever Zakim misfeature causes that message.
# [08:13] <heycam`> fantasai: there are two minor things on auto hyphenation
# [08:13] <heycam`> ... one was if hyphenation was turned on, and you have no appropraite resource, is the UA required to hypheante or turn on auto hyphenation?
# [08:13] <heycam`> ... I think the answer to that should just be yes
# [08:13] <heycam`> ... since that was unclear in the spec
# [08:13] * Joins: teoli (~teoli@public.cloak)
# [08:13] <heycam`> dbaron: for a known language?
# [08:13] <heycam`> fnatasai: yes
# [08:13] <dbaron> s/for a/appropriate resource implies/
# [08:14] <heycam`> ... if you have a soft hyuphen in the word, the text we inherited was that that takes priority over auto hyphenation
# [08:14] <heycam`> ... some implementations mix soft and autohyphenation
# [08:14] <heycam`> ... if the auto is one point away with soft hyphen, it might choose the auto one
# [08:14] <heycam`> ... which doesn't make sense
# [08:14] <heycam`> ... I propose if there are soft hyphens, you only hyphenate there, not auto
# [08:15] <heycam`> richard: wonder if there are languages with words so long youwouldn't want to do that
# [08:15] <heycam`> fantasai: if you want to put soft hyphens, you should put them at all points in the word
# [08:15] <heycam`> ssapin: can you break more than once?
# [08:15] <heycam`> krit: yes
# [08:15] <heycam`> richard: if you only had one soft hyphen, you'd be taking away the other break points in a long word
# [08:16] <heycam`> ... it'd need to be clear that's what's happening
# [08:16] <heycam`> ... sometimes you copy text and it has soft hyphens in it
# [08:16] <heycam`> ... and you're not aware
# [08:16] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [08:16] <heycam`> ... not sure that's what people would expect
# [08:17] <heycam`> ... don't know whether that's a significant objection
# [08:17] <heycam`> bert: people who are used to TeX/LaTeX, that's how it behaves
# [08:17] <heycam`> ... so there is precedent
# [08:17] <heycam`> rossen: same in Word
# [08:17] <heycam`> alan: and InDesign
# [08:17] <heycam`> rossen: it's a well known behaviour
# [08:17] * Joins: simonstewart (~simonstewart@public.cloak)
# [08:18] <heycam`> davecramer: we discovered implementations that allowed auto hyphens as well as soft hyphens, and that confused users
# [08:18] <heycam`> ... if you're going to the effort of adding soft hyphens, that's the most importnat thing
# [08:18] <heycam`> plinss: I think if people put a discretionary hyphen it's because they dont like what the auto hyphenation would doi
# [08:18] <heycam`> s/doi/do/
# [08:19] * Joins: koji (~koji@public.cloak)
# [08:19] <heycam`> ... otherwise you'd need o put ZWNBSP between all other characters to disable
# [08:19] <heycam`> dbaron: another use might be adding soft hyphens for implementations that dont have auto hyphens
# [08:19] <heycam`> ... and only on words where they notice where words are long
# [08:19] <heycam`> alan: that's a mistake
# [08:19] <heycam`> ... you should place them on all places they could occur
# [08:20] <heycam`> richard: there's no issue about existing text that's now goign to break is there?
# [08:20] <heycam`> dbaron: people have to explicitly enable the auto hyphenation
# [08:20] <heycam`> ... I think the resolution is fine, just wanted to point that out
# [08:20] * Quits: ijongcheol (~ijongcheol@public.cloak) (Client closed connection)
# [08:20] <heycam`> davecramer: the only impl I know that has hthis problem is not used by millinos of people
# [08:20] <heycam`> richard: I'm convinced at the moment
# [08:20] <dauwhe_> s/millinos/millions/
# [08:21] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [08:21] <heycam`> fantasai: there was one relatively significant issue with text align, text align last
# [08:21] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [08:21] <heycam`> ... we got feedback from digipub wg
# [08:21] * Joins: cwdoh (~cwdoh@public.cloak)
# [08:21] <heycam`> ... one comment was a suggestion that text-align be a shorthand
# [08:21] * Zakim heycam`, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:22] <heycam`> ... and perhaps there should be a separate property for first line alignment, and then text-align could become a shorthand
# [08:22] * Zakim heycam`, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:22] <heycam`> ... another thing Bert asked me yesterday was, what if I want to justify the only line of a para
# [08:22] <TabAtkins> zakim, shut up
# [08:22] <Zakim> I don't understand 'shut up', TabAtkins
# [08:22] <heycam`> ... wasn't obvious that you should use text-align-last
# [08:22] <TabAtkins> zakim, anything
# [08:22] <Zakim> I don't understand 'anything', TabAtkins
# [08:23] <TabAtkins> Obviously.
# [08:23] <heycam`> ... so while it is the last line, it's the only line, it doesn't seem a logical place to look for that feature
# [08:23] * Quits: simonstewart (~simonstewart@public.cloak) (Client closed connection)
# [08:23] <heycam`> ... makes more inclined to consider text-align being a shorthand taking justify-all
# [08:23] <heycam`> ... rather than it be an independent property
# [08:23] <heycam`> ... seems usability would be better if we do that
# [08:23] * Joins: mz-modeltaxi (~mz_modeltaxi@public.cloak)
# [08:23] <heycam`> davecramer: I was confused by text-align when I first encountered it
# [08:24] <heycam`> ... that it affected lines in the para with line breaks too
# [08:24] <heycam`> alan: that's about the break, not this property
# [08:24] <heycam`> fantasai: that aspect wouldn't change
# [08:24] <heycam`> ... sometimes we use a froced line break because there wasn't one in the text
# [08:24] <heycam`> ... and we don't want the text before the line break to use text-align-last
# [08:24] <heycam`> ... in other cases, you do want the text-aling-last behaviour
# [08:25] <heycam`> davecramer: I think it's a UA problem
# [08:25] <heycam`> fantasai: it's al ine breaking problem that shouldb e handled with ZWSPs
# [08:25] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:25] <heycam`> davecramer: they'd add letter spacing so you don't have a big gap
# [08:25] <heycam`> fantasai: my proposal is we do the opposite of what we said in paris
# [08:25] <dauwhe_> s/al ine/a line/
# [08:25] <heycam`> ... make text-align a shorthand
# [08:25] * Zakim heycam`, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:25] <heycam`> alan: didn't we determine the resolution we had in paris was it's the behaviour that Word, InDesign has?
# [08:26] <heycam`> fantasai: it's not about that
# [08:26] * Quits: mz-modeltaxi (~mz_modeltaxi@public.cloak) ("")
# [08:26] <heycam`> ... it's about an interfae problem on teh CSS side
# [08:26] * Joins: shepazu (schepers@public.cloak)
# [08:26] <heycam`> ... is text-align last an indepenent property from text-align?
# [08:26] <heycam`> ... or is it a longhand?
# [08:26] <heycam`> ... either way, you get various aesthetics
# [08:26] <dauwhe_> s/interfae/interface/
# [08:26] <heycam`> bert: the issue is we had an impl of text-align-last that would sometimes give different results
# [08:26] <heycam`> fantasai: we looked at content compatibility and determined there wouldn't be a problem
# [08:26] <heycam`> ... at the F2F I was ambivalent
# [08:27] <heycam`> ... about which way to go
# [08:27] <heycam`> ... but I'm finding these usability problems
# [08:27] <heycam`> kennyluck: is this issue related to adding text-align justify-all?
# [08:28] * Quits: ijongcheol (~ijongcheol@public.cloak) (Ping timeout: 180 seconds)
# [08:28] <heycam`> fantasai: yes, if we want text-align:justify-all we must make text-align-last a longhand of text-align
# [08:28] * Joins: dbaron (~dbaron@public.cloak)
# [08:28] <heycam`> ... any other comments on this issue?
# [08:28] <dbaron> I'm in favor of making text-align a shorthand containing text-align-last
# [08:28] <heycam`> ... there was acomment in the message from markus bert forwarded
# [08:28] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [08:28] <heycam`> ... two days ago
# [08:29] <dbaron> RRSAgent, pointer?
# [08:29] <RRSAgent> See http://www.w3.org/2013/11/12-css-irc#T07-29-18
# [08:29] <heycam`> fantasai: my recommendation is to go the shorthand route
# [08:29] <heycam`> ... can write a separate thread email if people want
# [08:29] <heycam`> ... stil waiting on i18n's comments anyway
# [08:29] <heycam`> ... happy to discuss this at the next telcon
# [08:29] <kennyluck> (I am not very convinced that 'text-align: justiy-all' implies that 'text-align' should be a shorthand, but I support whatever would make 'text-align: justify-all' in.))
# [08:29] <heycam`> s/stil/still/
# [08:29] * dbaron wonders why http://www.w3.org/2013/11/12-css-irc.txt is lagging
# [08:30] <heycam`> plinss: in that email can you refresh our memories and a comparison?
# [08:30] <heycam`> ACTION: fantasai to mail www-style with the text-align shorthand issue
# [08:30] * trackbot is creating a new ACTION.
# [08:30] * RRSAgent records action 4
# [08:30] <trackbot> Created ACTION-597 - Mail www-style with the text-align shorthand issue [on Elika Etemad - due 2013-11-19].
# [08:30] * leaverou is now known as leaverou_away
# [08:30] <heycam`> koji: text-align: each-line renaming
# [08:30] <heycam`> ... to each-paragraph, or after-line
# [08:30] <heycam`> s/line/break/
# [08:30] <heycam`> ... I have no opinion
# [08:31] <heycam`> fantasai: the bproblem with after-break is it also applies to the first line
# [08:31] * plinss http://log.csswg.org/irc.w3.org/css/?date=2013-11-11 isn't lagging...
# [08:31] <heycam`> ... don't think it's a better name
# [08:31] <heycam`> ... my concern about each-paragraph is that first the use case is really abotu logical lines
# [08:31] <heycam`> ... lines of code, poetry
# [08:31] <heycam`> ... which wrpas to multiple physical lines
# [08:31] <heycam`> ... those are not paragraphs in any sesnse of the word
# [08:31] <dauwhe_> s/abotu/about/
# [08:31] <heycam`> ... second is that a paragraph is for HTML thought of as <p>
# [08:32] <heycam`> ... this would be having units of a paragraph within a <p>
# [08:32] <heycam`> ... my inclination is not to make a change here
# [08:32] <heycam`> kenny: my qn is the use cases for logical lines, why don't you use padding?
# [08:32] <heycam`> fantasai: because it allows you to indent each line hanging, say
# [08:33] <heycam`> ... the first line not indented, but all of the lines that line wraps to would be indented
# [08:33] <heycam`> ... also typical for long lines of code
# [08:33] <heycam`> ... which are wrapped due to the page width
# [08:33] <heycam`> ... any other comments on that?
# [08:34] <heycam`> RESOLUTION: We won't rename text-align: each-line
# [08:34] <heycam`> koji: second issue, for line break behaviour CSS requires to honour UTR14
# [08:34] <dbaron> s/UTR14/UAX14/
# [08:34] <Bert> s/text-align/text-indent/
# [08:35] <heycam`> ... after a NBSP, a replaced element -- UAX14 defines it to be GL+CB
# [08:35] <kennyluck> the case is basically this <input> <input>
# [08:35] <heycam`> ... the other pair is CB, which CSS does not rrequire to honour
# [08:35] <heycam`> ... is there a break opportunity between the two?
# [08:35] <heycam`> fantasai: we should do that on the list
# [08:35] <heycam`> koji: last one from james clark
# [08:36] <heycam`> ... he's saying that letter-spacing applying to grapheme clusters is a bad idea
# [08:36] * Quits: bobby (~bobby@public.cloak) (bobby)
# [08:36] <heycam`> ... he's raising a few examples, Thai, other complex scripts, that sometimes letter-spacing should not be applied between grapheme clusters
# [08:36] <heycam`> ... or one grapheme clusters should be split into multiple glyphs
# [08:36] <heycam`> ... he's not suggesting how to fix this, but just raising some examples that don't work
# [08:36] <heycam`> fantasai: I think the way I'd fix that would be to allow the UA to modify the unit used for letter-spacing and justification in what way is appropriate
# [08:37] <heycam`> s/appropriate/typographically appropriate/
# [08:37] <heycam`> and leave that not defined any further
# [08:37] <heycam`> ... start with UAX14, and then tailor as appropriate as we find it
# [08:37] <heycam`> ... either in UAX14 or css-text
# [08:37] <heycam`> koji: I agree with fantasai
# [08:37] <heycam`> ... I repliedsaying this
# [08:38] <heycam`> ... I want to make sure the WG is fine to base on grpheme clusters, btu allow script specific modifications if needed
# [08:38] <fantasai> s/UAX14/UAX29/
# [08:38] <heycam`> richard: my ugess it's a worse idea to use grapheme clusters most of the time
# [08:38] <dbaron> (that substitution applies to 7 and 8 lines up, but not 20 lines up!)
# [08:38] <heycam`> ... if you start splitting off acute accents from Es etc., you'll have a big mess
# [08:38] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [08:38] <heycam`> fantasai: any other comments?
# [08:39] <heycam`> ... koji and I will continue to make comments
# [08:39] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [08:39] <heycam`> ... we'll come back with DoC after resolving these and getting i18n feedback
# [08:39] <heycam`> ... the action for text-align we can discuss at the next telcon
# [08:39] <heycam`> richard: I should point out we asked for an extension due to the Unicode conference
# [08:40] <heycam`> -- break until 4pm --
# [08:40] * leaverou_away is now known as leaverou
# [08:40] * Joins: glazou (~glazou@public.cloak)
# [08:40] <TabAtkins> What's left after the break?
# [08:41] * heycam` background stuff
# [08:41] * Joins: bobby (~bobby@public.cloak)
# [08:41] * Joins: teoli_ (~teoli@public.cloak)
# [08:41] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [08:41] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [08:41] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [08:41] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [08:42] * Joins: koji (~koji@public.cloak)
# [08:42] <r12a> s/richard: my ugess it's a worse idea to use /richard: my ugess it's a worse idea to not use /
# [08:42] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [08:43] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [08:43] * Joins: cwdoh (~cwdoh@public.cloak)
# [08:45] * Joins: wilhelm (~wilhelm@public.cloak)
# [08:45] * Joins: tantek (~tantek@public.cloak)
# [08:45] * Quits: satakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [08:45] <TabAtkins> s/ugess/guess/
# [08:45] * Quits: heycam` (~cam@public.cloak) ("Leaving")
# [08:45] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [08:46] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [08:46] * Joins: dwim (~dwim@public.cloak)
# [08:46] * Joins: cwdoh (~cwdoh@public.cloak)
# [08:46] * Quits: birtles_ (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [08:47] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [08:47] * Joins: kurosawa (~kurosawa@public.cloak)
# [08:48] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:49] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [08:49] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [08:49] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [08:51] * Quits: bobby (~bobby@public.cloak) (bobby)
# [08:51] * Quits: tobie (tobie@public.cloak)
# [08:52] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [08:53] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [08:54] * leaverou is now known as leaverou_away
# [08:55] * Joins: Jirka (~jirka@public.cloak)
# [08:56] * Quits: jehoochen_ (~jehoochen@public.cloak) (Ping timeout: 180 seconds)
# [08:56] * Joins: shepazu (schepers@public.cloak)
# [08:59] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [09:04] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [09:04] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [09:04] * Joins: dwim (~dwim@public.cloak)
# [09:06] * Joins: cwdoh (~cwdoh@public.cloak)
# [09:06] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [09:06] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:08] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [09:08] * Joins: glenn (~gadams@public.cloak)
# [09:09] * Joins: plh (plehegar@public.cloak)
# [09:11] * Joins: glenn_ (~gadams@public.cloak)
# [09:11] * Joins: mgylling (~mgylling@public.cloak)
# [09:12] * Parts: myakura (~myakura@public.cloak) (myakura)
# [09:12] * Joins: myakura (~myakura@public.cloak)
# [09:12] * Joins: hayato_ (~hayato@public.cloak)
# [09:12] * Joins: glenn__ (~gadams@public.cloak)
# [09:14] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:14] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [09:14] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:15] * Joins: michou (~Adium@public.cloak)
# [09:16] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [09:18] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [09:18] * Quits: rhauck2 (~Adium@public.cloak) (Client closed connection)
# [09:19] * Joins: cwdoh (~cwdoh@public.cloak)
# [09:19] * Quits: glenn_ (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [09:22] * Joins: koji (~koji@public.cloak)
# [09:23] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [09:23] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [09:24] * Joins: dbaron (~dbaron@public.cloak)
# [09:25] * Joins: jehoochen_ (~jehoochen@public.cloak)
# [09:26] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [09:31] * Joins: stakagi (~stakagi@public.cloak)
# [09:31] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [09:32] * Joins: birtles (~chatzilla@public.cloak)
# [09:37] <astearns> scribenick: dauwhe_
# [09:38] * Joins: sgalineau (~sgalineau@public.cloak)
# [09:39] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0178.html
# [09:39] <dbaron> dbaron: I think it's worth testing browsers before defining the behavior here; seems worth doing but doesn't have to happen in this level
# [09:40] <dbaron> zcorpan: I think it's defined in CSS OM; browsers tend to disagree but the definition tries to align
# [09:40] <zcorpan_> http://dev.w3.org/csswg/cssom/#concept-declarations-specified-order
# [09:41] * fantasai doesn't understand
# [09:42] <dauwhe_> fantasai: don't define what happens if you expand something out.
# [09:42] * Quits: jehoochen_ (~jehoochen@public.cloak) (Ping timeout: 180 seconds)
# [09:42] <dauwhe_> zcorpan: we need to define orders of longhands
# [09:42] * Zakim dauwhe_, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [09:42] <dbaron> fantasai: The canonical order seems to define canonical order for serialization, not of longhands
# [09:42] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [09:42] * dauwhe_ I started minuting on wrong channel. Will fix later.
# [09:43] * Quits: Jirka (~jirka@public.cloak) (Jirka)
# [09:43] * Joins: jehoochen_ (~jehoochen@public.cloak)
# [09:43] <dauwhe_> fantasai: what should I do with spec?
# [09:43] <dauwhe_> zcorpan: I want order defined in CSSOM.
# [09:43] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [09:43] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [09:43] <dauwhe_> ... I can take action item to test what browsers do and document it somewhere.
# [09:43] * Joins: lmcliste_ (~lmclister@public.cloak)
# [09:43] <dauwhe_> fantasai: should there be a list of all properties in spec in an order?
# [09:44] <dauwhe_> dbaron: we should see what browsers do. I don't want to break interop.
# [09:44] * Joins: teoli (~teoli@public.cloak)
# [09:44] * Joins: bobby (~bobby@public.cloak)
# [09:44] <dauwhe_> fantasai: what does that spec look like?
# [09:44] <dauwhe_> dbaron: orderings might not fit with list in spec?
# [09:44] <dauwhe_> ... might be easiest to put in propdef
# [09:45] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
# [09:45] <dauwhe_> ... must define order resiliant to addition of new properties
# [09:45] <dauwhe_> fantasai: who's doing this?
# [09:45] <dauwhe_> ... and in what spec?
# [09:46] <dauwhe_> dbaron: do we have def of canonical order in propdef?
# [09:46] <dauwhe_> fantasai: in CSSOM
# [09:46] <dauwhe_> dbaron: CSSOM has canonical order, but does not define it.
# [09:46] <dbaron> s/has/uses the term/
# [09:46] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [09:46] <dauwhe_> fantasai: how to read propdef tables is not part of spec
# [09:46] * Quits: mgylling (~mgylling@public.cloak) (mgylling)
# [09:46] <TabAtkins> Ah, I was wondering why it started in the middle of stuff.
# [09:47] * dauwhe_ it's in #dpub :(
# [09:47] <dauwhe_> fantasai: only def. is in CSS 2.1
# [09:48] * Joins: rhauck (~Adium@public.cloak)
# [09:48] <dauwhe_> fantasai: put how to read css propdef tables into snapshot?
# [09:48] * Quits: bobby (~bobby@public.cloak) (bobby)
# [09:48] <dauwhe_> dbaron: used to be in syntax
# [09:48] <dbaron> dbaron: or could be in values
# [09:48] * dauwhe_ thanks!
# [09:48] <TabAtkins> I'm fine with either.
# [09:48] * glazou too
# [09:49] <dauwhe_> plinss: who edits these specs?
# [09:49] <dauwhe_> fantasai: does this need to be rec track document?
# [09:49] <dauwhe_> dbaron: yes
# [09:49] * Joins: taocai (~taocai@public.cloak)
# [09:49] <TabAtkins> ...really?
# [09:49] <dauwhe_> plinss: don't feel strongly about syntax or values but should be rec track
# [09:50] <dauwhe_> fantasai: not convinced about rec track; it's about document conventions
# [09:50] * Joins: rhauck1 (~Adium@public.cloak)
# [09:50] <dauwhe_> astearns: it's about document conventions?
# [09:50] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [09:50] * Joins: Jirka (~jirka@public.cloak)
# [09:50] <dauwhe_> fantasai: how to read a propdef table is largely about document conventions.
# [09:50] <TabAtkins> Are people talkinga bout the same thing?
# [09:50] * Joins: stakagi (~stakagi@public.cloak)
# [09:50] <dauwhe_> plinss: it's meta-normative.
# [09:51] * Quits: jehoochen_ (~jehoochen@public.cloak) ("Leaving")
# [09:51] <dauwhe_> fantasai: snapshot is where you want to put it
# [09:51] <TabAtkins> I think we're talking about the format of a propdef table. It's just a compact representation - how to expand that into the normative def doesn't need to be Rec-track, just recorded.
# [09:51] * fantasai agrees with Tab
# [09:51] * Joins: tobie (tobie@public.cloak)
# [09:51] * astearns thinks he does too
# [09:52] <dauwhe_> fantasai: did you see Tab's comment?
# [09:52] <TabAtkins> We don't need the property grammar in a rec-track doc either. It was just convenient to put it into Values.
# [09:52] * dbaron disagrees with Tab
# [09:52] * astearns thinks all debates should occur via irc emotes
# [09:52] <TabAtkins> I don't understand, dbaron. :/
# [09:52] <dauwhe_> plinss: I suggest we put it in values
# [09:53] <TabAtkins> But the only thing that got minuted was "Yes" from you, so shrug.
# [09:53] <dauwhe_> fantasai: some of it is about values
# [09:53] <dauwhe_> ... is it inherited.
# [09:53] * glazou thinks that would help to reach interop here and interop needs a standard, ie a REC
# [09:53] <dbaron> TabAtkins, It affects what some pretty important stuff in the spec means
# [09:53] <dauwhe_> astearns: I agree it should be in values.
# [09:53] <dbaron> TabAtkins, stuff that changes what an implementation is required to do
# [09:53] <dbaron> TabAtkins, it seems pretty odd to make something like that non-normative
# [09:53] <fantasai> glazou, interop on how to read a propdef table? Yeah, I guess so, but the implementations are people here...
# [09:54] <zcorpan_> i agree with dbaron
# [09:54] <astearns> *if it needs to be in a rec track document
# [09:54] <glazou> fantasai, yeah...
# [09:54] <dauwhe_> plinss: do we need a resolution
# [09:54] <dauwhe_> fantasai: we need an action
# [09:54] <TabAtkins> dbaron: No, the content inside of it is normative. How to read it is just descriptive. But whatever, I'm fine with it in Values or Syntax, I just don't see that it *needs* to be in one of those.
# [09:54] <dauwhe_> plinss: who takes the action?
# [09:55] <fantasai> ACTION: fantasai put something somewhere
# [09:55] * RRSAgent records action 5
# [09:55] * trackbot is creating a new ACTION.
# [09:55] <trackbot> Created ACTION-598 - Put something somewhere [on Elika Etemad - due 2013-11-19].
# [09:55] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [09:55] <glazou> lol
# [09:55] * astearns it's the punchy end-of-meeting time
# [09:55] <TabAtkins> You're going to look at that later and be so confused, fantasai.
# [09:55] * fantasai never looks at her actions list, so meh
# [09:55] <dauwhe_> astearns: one other thing on backgrounds
# [09:55] <dauwhe_> ... remove three-value positions?
# [09:56] <dauwhe_> fantasai: we'd also have to remove one-value positions, including center
# [09:56] <dauwhe_> astearns: we would have to remove one value that is not keyword
# [09:56] <dauwhe_> fantasai: not something we can fix
# [09:57] <dauwhe_> ... what are Tab's thoughts?
# [09:57] <fantasai> e.g., 'center' would no longer be a valid <position>
# [09:57] <fantasai> so I'm less convinced this is a good idea
# [09:57] <TabAtkins> Why do we have to also remove 1-value?
# [09:57] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [09:57] <fantasai> when it was just 3-value syntax, well, that seemed unpopular enough to get rid of... but not 1-value
# [09:57] <fantasai> TabAtkins, because it's ambiguous
# [09:57] <dauwhe_> plinss: do we want tab to call in?
# [09:58] <TabAtkins> The problem with 3-value is that "left top 5px" is maybe a <position> and maybe a <position> <length>.
# [09:58] <dauwhe_> dbaron: if he does, would he hear us?
# [09:58] <TabAtkins> But "left 5px" isn't ambiguous.
# [09:58] <fantasai> it is
# [09:58] <TabAtkins> No, I won't hear anything.
# [09:58] <fantasai> it can be <position> <length>, too
# [09:58] <fantasai> or it can be <position> with 2 values
# [09:58] <TabAtkins> Aw man, I thought I remembered the 2-value as being either 2 lengths or 2 keywords.
# [09:58] <TabAtkins> Sigh, okay.
# [09:58] <fantasai> Close no change?
# [09:59] * astearns that last bit is asking you, Tab
# [09:59] <TabAtkins> Oh.
# [10:00] * Joins: nsakai (~nsakai@public.cloak)
# [10:00] <TabAtkins> Given that this is *not* intending to be a backwards-compatible change (we'll define the old position syntax as <legacy-position> and still use it in the older properties), what about making the 2-value change to have it only be lengths or keywords, not both?
# [10:00] <fantasai> I think this is getting more confusing than helpful
# [10:00] <TabAtkins> Then we could allow 1-value as keywords only, and no ambiguity.
# [10:01] <TabAtkins> I'll write it up.
# [10:01] <dauwhe_> astearns: this has no effect on backgrounds
# [10:01] <TabAtkins> Right.
# [10:01] <dauwhe_> ... for backgrounds we close no change
# [10:01] <TabAtkins> Yes.
# [10:01] <dauwhe_> fantasai: that we'd have to do anyway
# [10:01] <dauwhe_> ... syntax that's almost but not quite the same
# [10:01] <dauwhe_> ... that might be confusing
# [10:01] <TabAtkins> What we name the grammar term in bg-position isn't important anyway.
# [10:01] <dauwhe_> ... whether it's valid in one case or the other
# [10:02] <dauwhe_> astearns: use different terms for left and right
# [10:02] <dauwhe_> fantasai: don't have any cases
# [10:02] <dauwhe_> ... where it make a significant difference
# [10:02] <dauwhe_> ... not worth pursuing
# [10:02] <TabAtkins> Yeah we do - we can't use something position-like for 3d.
# [10:02] <TabAtkins> Because of the ambiguity.
# [10:02] <astearns> s/astearns: use different terms for left and right//
# [10:02] * astearns was a joke that fell flat
# [10:03] <TabAtkins> But anyway, I'll write this up.
# [10:03] <fantasai> TabAtkins, then let's make transform-origin a special snowflake
# [10:03] * dauwhe_ I thought it was funny
# [10:03] <fantasai> TabAtkins: it's special in having 3 dimensions of position already
# [10:03] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:04] <fantasai> I'm rather less convinced that we should be altering gradients(), shapes, et al.
# [10:04] <fantasai> to be different from background-position
# [10:04] <fantasai> than altering transform-origin in that way
# [10:04] <TabAtkins> It probably doesn't matter much, but whatever.
# [10:05] <dauwhe_> fantasai: thoughts on altering transform-origin() to allow to expand to
# [10:05] <dauwhe_> ,.. so the problem is that it only takes this length arg. that represents third dimension
# [10:05] <dauwhe_> ... so we're stuck with css1 backround positioning
# [10:05] <dauwhe_> ... that's the problem case we have
# [10:06] * TabAtkins suggests the 3d side keywords be "face" and "infinity".
# [10:06] <dauwhe_> ... since this is a 3-d position
# [10:06] <dauwhe_> ... it's less bad.
# [10:07] <dauwhe_> astearns: dirk has strong opinions about transform-origin()
# [10:07] <dauwhe_> ... that I can't channel
# [10:07] * Joins: cwdoh (~cwdoh@public.cloak)
# [10:07] <dbaron> s/()//
# [10:08] <fantasai> ACTION: fantasai write up with Tab potential changes to transform-origin to reduce/alter inconsistencies with background-position
# [10:08] * trackbot is creating a new ACTION.
# [10:08] * RRSAgent records action 6
# [10:08] <trackbot> Created ACTION-599 - Write up with tab potential changes to transform-origin to reduce/alter inconsistencies with background-position [on Elika Etemad - due 2013-11-19].
# [10:08] <dauwhe_> fantasai: anything else?
# [10:08] <dauwhe_> fantasai: can we make spread continuous is still an issue
# [10:08] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [10:09] <dauwhe_> ... working on formula so we can have continous animation
# [10:09] <dauwhe_> ... starting from zero
# [10:09] <dauwhe_> ... or we can decide we won't change and publish LC
# [10:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:09] <dauwhe_> plinss: set time limit on new solution
# [10:09] <dauwhe_> ... I don't feel strongly
# [10:10] <dauwhe_> fantasai: neither do I. I'll respond to mailing list.
# [10:10] <dauwhe_> Dean: I've proposed border-image-like slicing for backgground image
# [10:10] <dauwhe_> ... some support on mailing list
# [10:10] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [10:10] <dauwhe_> ... is this enough for a real proposal?
# [10:10] <dauwhe_> fantasai: we can do backgrounds 4.
# [10:10] <TabAtkins> I find the 9-slice function idea interesting.
# [10:10] <dauwhe_> dbaron: don't add to level 3
# [10:11] <dauwhe_> Dean: don't delay progress in level 3
# [10:11] <dauwhe_> dbaron: hesitant about property explosion
# [10:11] <dauwhe_> Dean: haven't thought through
# [10:11] <dauwhe_> ... could be like border-image
# [10:11] <dauwhe_> ... before the comma
# [10:11] * Quits: kurosawa (~kurosawa@public.cloak) (Ping timeout: 180 seconds)
# [10:11] <dauwhe_> Ted: what about a new function?
# [10:11] * Quits: hayato_ (~hayato@public.cloak) (Ping timeout: 180 seconds)
# [10:11] <dauwhe_> Dean: Tab wanted a new function.
# [10:12] * TabAtkins always wants a new function.
# [10:12] <dauwhe_> Lea: very different
# [10:12] * TabAtkins What, the old function isn't good enough for ya?
# [10:12] <dauwhe_> fantasai: consider for level 4 of images
# [10:12] <dauwhe_> ... we have feature for fallbacks
# [10:12] <dauwhe_> ... an image function
# [10:12] <dauwhe_> ... takes comma seperated list
# [10:12] <dauwhe_> ... lots of crazy discussion of image set
# [10:12] * leaverou_away is now known as leaverou
# [10:13] <dauwhe_> ... tied to media fragments and slice
# [10:13] <dauwhe_> ... UA's that don;t understand media fragments removing image
# [10:13] <dauwhe_> ... people want to implement media fragments
# [10:13] <dauwhe_> ... drop fallback
# [10:13] <dauwhe_> ... only new functionality would be media fragments
# [10:13] <dauwhe_> ... make it more enticing to implement
# [10:13] <dauwhe_> Ted: sounds good
# [10:14] <dauwhe_> plinss: shouldn't be issue to put fallbacks back
# [10:14] <dauwhe_> fantasai: put in image sets
# [10:14] <dauwhe_> ... push to level 4
# [10:14] <dauwhe_> plinss: don't preclude doing something in future
# [10:14] <fantasai> TabAtkins, ok with that?
# [10:14] <TabAtkins> I don't get it. What's the value of using image() just for media fragments? You can do that in url().
# [10:14] <dauwhe_> ... other opinions?
# [10:14] * Joins: nsakai2_ (~nsakai2@public.cloak)
# [10:14] <dauwhe_> Ted: sounds reasonable
# [10:15] <dauwhe_> ... I'm worried that I'm not thinking of something
# [10:15] <TabAtkins> The point of the special image() bheavior wrt fragments was *because* you could do fallback.
# [10:15] <dauwhe_> .... I'd love to see concrete proposal
# [10:15] <fantasai> TabAtkins, no that was image slicing via media fragments
# [10:15] <fantasai> TabAtkins, talking about removing the comma-separated multiple urls funmctionality of image()
# [10:15] <TabAtkins> Yeah, why? The minutes above don't make sense.
# [10:16] <dauwhe_> dbaron: what are you proposing?
# [10:16] <TabAtkins> Fallback is the whoel point of image().
# [10:16] <fantasai> TabAtkins, well, not really. We have two features in the image() function
# [10:16] <dauwhe_> fantasai: there's 2 features in image function
# [10:16] <fantasai> one is fallback urls, so image(foo.svg, foo.png, foo.gif)
# [10:16] <fantasai> other is media framgents
# [10:16] <fantasai> image(foo.png#xywh=20,20,30,40)
# [10:17] <TabAtkins> No, media fragments is not a feature of image(). It's a feature of URLs. They're usable in url(), too.
# [10:17] <fantasai> There's much interest in the first one
# [10:17] <fantasai> but in the second one
# [10:17] <TabAtkins> We just happened to shove in a requirement that image() *must* support media frags.
# [10:17] <fantasai> Yeah, which is what makes it usable
# [10:17] <TabAtkins> Explain?
# [10:17] <fantasai> Also, given the desire for image-set(), would want to co-design fallback URLs with that
# [10:18] <dbaron> Maybe this should go to the mailing list?
# [10:18] <plinss> See http://drafts.csswg.org/css-images-3/#image-fragments example 4
# [10:18] <fantasai> If you have an old UA and you use url() with media frags, it will display the whole image
# [10:18] <TabAtkins> ...yes?
# [10:18] <fantasai> so it's not really usable atm
# [10:18] <dbaron> what was tab saying yes to?
# [10:18] <fantasai> image() makes it possible to transitioning
# [10:18] <dauwhe_> fantasai: fine to move to next topic
# [10:18] <TabAtkins> Okay, I think I understand now.
# [10:18] <TabAtkins> Sure, whatever, reduced implementation.
# [10:18] <dauwhe_> plinss: take issue to mailing list?
# [10:18] <dauwhe_> fantasi: tab says ok
# [10:19] <dauwhe_> dbaron: I think it was OK to something else
# [10:19] <TabAtkins> I'd like to keep the color fallback if possible at this level.
# [10:19] <fantasai> ah
# [10:19] <TabAtkins> dbaron: It was a questioning yes, like "yeah?"
# [10:19] <dauwhe_> plinss: mark as at risk or take out?
# [10:19] <dauwhe_> fantasai: take to mailing list
# [10:19] <TabAtkins> kk
# [10:19] <dauwhe_> Topic: transitions
# [10:19] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Nov/0192.html
# [10:19] <dauwhe_> dbaron: made edits we agreed on in Tokyo
# [10:20] <dauwhe_> ... and would like review of edits, want to publish WD sooner rather than later
# [10:20] <dauwhe_> ... hope there's nothing big left
# [10:20] <dauwhe_> ... still need to troll mailing list
# [10:20] <dauwhe_> ... first, are people OK with new WD for transitions
# [10:20] * TabAtkins is pretty good at trolling mailing lists.
# [10:21] <dauwhe_> ... then take both to LC soon
# [10:21] * fantasai thinks s/troll/trawl/
# [10:21] <dbaron> yes, trawling :-)
# [10:21] <TabAtkins> Hehe, I know. Near homophones.
# [10:21] <dauwhe_> Dean: I support publishing
# [10:21] <TabAtkins> +1 to publish
# [10:21] <dauwhe_> Dean: undecided was reversing behaviour
# [10:21] <dauwhe_> dbaron: 2 big edits
# [10:21] <dauwhe_> ... reversing behaviour
# [10:22] <dauwhe_> ... and starting of transitions, which was scarier change
# [10:22] <dauwhe_> ... implemtations all disagreed
# [10:22] <dauwhe_> ... that's been in spec for a few months
# [10:22] <dauwhe_> ... shane said in Paris he'd implemented it
# [10:22] <dauwhe_> ... and thought it worked
# [10:22] <dauwhe_> ... if people are happy to resolve to publish that's fine
# [10:23] <dauwhe_> RESOLVED: publish new working draft of CSS Transitions
# [10:23] <dauwhe_> Topic: CSS Shapes
# [10:23] <dauwhe_> astearns: i've updated spec
# [10:23] <dauwhe_> ... some clarifations to interpolation I need to add
# [10:24] <dauwhe_> ... add section describing box keywords
# [10:24] <dauwhe_> ... esp. margin box
# [10:24] <dauwhe_> ... minor changes to inset circle and ellipse to clarify
# [10:24] <dauwhe_> ... will ask for last call
# [10:24] <dauwhe_> fantasai: sounds good
# [10:24] <dauwhe_> ... would be OK with LC
# [10:24] <dauwhe_> astearns: interpolation stuff doesn't work
# [10:25] <dauwhe_> fantasai: other things?
# [10:25] <dauwhe_> Topic: backgrounds and borders 4
# [10:26] <dauwhe_> Lea: border clip property
# [10:26] <dauwhe_> ... show only corners, etc.
# [10:26] <dauwhe_> ... wondering about syntax and names
# [10:26] <dauwhe_> ... border clip is confusing
# [10:26] <dauwhe_> ... doesn't draw and then clip
# [10:26] <dauwhe_> ... doesn't show 2/3 of a dot
# [10:26] * Quits: dino (~dino@public.cloak) (dino)
# [10:26] <dauwhe_> ... maybe call it border parts?
# [10:26] <dauwhe_> fantasai: couple of proposals
# [10:27] <dauwhe_> ... border parts property
# [10:27] <dauwhe_> ... awkward for common cases
# [10:27] <dauwhe_> ... need lenght for both what is shown and what is hidden
# [10:28] <dauwhe_> ... do we want low level syntax or easier way to handle common cases
# [10:28] <dauwhe_> s/lenght/length/
# [10:28] <TabAtkins> I think common cases are sufficient, surely. Complex cases, just use border-image.
# [10:28] <dauwhe_> Lea: border-corner-shape
# [10:28] <TabAtkins> Need to show only corners, and no corners, and that's about it.
# [10:28] <dauwhe_> ... scoop, notch, bevel
# [10:29] <dauwhe_> ... I've built a demo of that property
# [10:29] * Joins: plh (plehegar@public.cloak)
# [10:29] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [10:29] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [10:29] <leaverou> http://leaverou.github.io/border-corner-shape/
# [10:29] * Joins: koji (~koji@public.cloak)
# [10:29] <dauwhe_> Lea: only accepts one keyword
# [10:30] <dauwhe_> ... wondering about the name
# [10:30] <dauwhe_> ... border-corner-shape is long
# [10:30] <dauwhe_> ... corner shape isn't obvious that it's related with border radius
# [10:30] <dauwhe_> ... good idea to have border radius defined the fallback
# [10:30] * Quits: tobie (tobie@public.cloak)
# [10:30] * TabAtkins likes 50% / 50%
# [10:30] <dauwhe_> ... fallback for diamond is ellipse
# [10:31] * Quits: bkardell (~uid10373@public.cloak) ("Connection closed for inactivity")
# [10:31] <dauwhe_> ... bigger the corner, the more unrelated having border radius as fallback is
# [10:31] * Joins: stakagi (~stakagi@public.cloak)
# [10:31] <dauwhe_> ... you often want rounding where straight edge join shape
# [10:31] <dauwhe_> ... maybe cubic bezier function
# [10:32] <dauwhe_> ... instead of only four keywords
# [10:32] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [10:32] <glazou> leaverou, clean, simple, understandable at first glance by anyone, probably possible to find better keywords for values
# [10:32] <dauwhe_> Dean: where are these?
# [10:32] <dauwhe_> fantasai: ED of backgrounds and borders 4
# [10:32] <Bert> -> http://dev.w3.org/csswg/css-backgrounds-4/#border-corner-shape bg-4
# [10:32] <dauwhe_> Lea: according to ED it only accepts one keyword
# [10:33] <TabAtkins> I wanna ask implementors about that. Curves are already complicated/slow to implement, dunno if cubic-bezier is lots slower or about the same.
# [10:33] * Quits: zqzhang_ (~zqzhang@public.cloak) (Ping timeout: 180 seconds)
# [10:33] <TabAtkins> s/about that/about cubic-bezier feasibility/
# [10:33] <dauwhe_> zcorpan: if you want rounded corners on bezel, would it make sense to use border-radius for that rounding?
# [10:33] * Quits: ijongcheol (~ijongcheol@public.cloak) (Client closed connection)
# [10:33] <dauwhe_> ... what are the different shapes for corner shape?
# [10:33] * Quits: nsakai (~nsakai@public.cloak) (Client closed connection)
# [10:34] * Joins: ijongcheol (~ijongcheol@public.cloak)
# [10:34] <dauwhe_> Lea: scoop which is like negative border radius
# [10:34] * glazou 'curve inside' 'curve outside' 'square inside' ' square outside' 'diagonal'
# [10:34] <dauwhe_> ... also notch
# [10:34] * TabAtkins glazou, "square outside" is just "ignore border-radius", no?
# [10:34] <dauwhe_> zcorpan: you might want a little radius on corners of the shape
# [10:34] <glazou> TabAtkins, yes
# [10:34] <dauwhe_> Lea: we don't know how to do that
# [10:34] <TabAtkins> kk
# [10:35] <dauwhe_> zcorpan: you should use border radius
# [10:35] <dauwhe_> Lea: that seems complex
# [10:35] * glazou thinks his proposal above is super readable by anyone
# [10:35] <TabAtkins> That seems *very* complex. (zcorpan's).
# [10:35] <dauwhe_> ... if you just want some rounding, do you need complexity of border radius
# [10:35] <dauwhe_> ... like elliptical?
# [10:35] <TabAtkins> What if you want to bevel your notches? Use border-image.
# [10:35] * Joins: shepazu (schepers@public.cloak)
# [10:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:35] * Joins: koji_ (~koji@public.cloak)
# [10:36] * glazou thinks we should start an IRC qdb
# [10:36] <dauwhe_> zcorpan: you're saying too much weight in border radius? Only have one value?
# [10:36] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [10:36] <dauwhe_> Lea: could apply to one corner
# [10:36] <dauwhe_> zcorpan: how would it result in elliptical border radiius?
# [10:36] * Quits: Jirka (~jirka@public.cloak) (Jirka)
# [10:36] <dauwhe_> Lea: would have to apply to all three joints
# [10:37] <dauwhe_> fantasai: bezier function would get you everything you want?
# [10:37] <dauwhe_> ... how do you join different colors etc.
# [10:37] <TabAtkins> Magic, presumably.
# [10:37] <dauwhe_> Bert: notch just works--it's really simple
# [10:37] <dauwhe_> fantasai: one other feature
# [10:37] <dauwhe_> ... for repeat there'd be an extend keyword
# [10:37] * Quits: nsakai2_ (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [10:37] <dauwhe_> ... if you have gradient somewhere
# [10:38] <dauwhe_> ... you clip it
# [10:38] <dauwhe_> ... the color ends at the end of the gradient box
# [10:38] <dauwhe_> ... it doesn't keep going
# [10:38] <dauwhe_> ... fills background margin area but then stops
# [10:38] <dauwhe_> ... if image has property of paint outside boundary, it would keep painting
# [10:38] <TabAtkins> "background-repeat:extend" lets you size a gradient with background-size but still have it fill the background area.
# [10:38] <dauwhe_> ... rather than ending at the boundary of the image
# [10:39] <dauwhe_> ... that's one of our random ideas for the spec
# [10:39] <dauwhe_> ... does anyone have other ideas? Multiple borders?
# [10:39] <TabAtkins> Probably low-value, but it's been some time since I recalled why I wanted it originally.
# [10:39] <TabAtkins> border-colors!
# [10:39] <dauwhe_> Lea: I'd vote for that
# [10:40] * Joins: tobie (tobie@public.cloak)
# [10:40] <glazou> multiple borders have been in Gecko for ages
# [10:40] <dauwhe_> fantasai: should we work on multiple borders?
# [10:40] * Quits: glenn__ (~gadams@public.cloak) (Client closed connection)
# [10:40] <TabAtkins> border-colors: green 1px, red 5px, yellow 3px; Something like that.
# [10:40] <dauwhe_> dauwhe: yes!
# [10:40] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [10:40] <TabAtkins> Would probably take some pressure off 'outline' to be a second border.
# [10:40] <dauwhe_> Bert: use grid and allow regions to have holes in them
# [10:40] <dauwhe_> ... with nested regions
# [10:41] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [10:41] * Quits: ijongcheol (~ijongcheol@public.cloak) (Ping timeout: 180 seconds)
# [10:41] <dauwhe_> fantasai: that's pretty complicated
# [10:41] <dauwhe_> Dean: yes!
# [10:41] * TabAtkins O_o
# [10:41] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [10:41] <glazou> see https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-border-top-colors
# [10:41] <dauwhe_> dbaron: does multiple borders mean multiple colors within a border?
# [10:41] <dbaron> ...or multiple border styles?
# [10:42] <TabAtkins> Probably. Dont' see requests for mutliple border styles.
# [10:42] * Quits: taocai (~taocai@public.cloak) (Client closed connection)
# [10:42] <TabAtkins> People just want some friggin rainbow borders.
# [10:42] <glazou> dbaron, not sure the latter is needed
# [10:42] <dauwhe_> Lea: make it a list
# [10:42] <TabAtkins> Or more seriously, 2 or 3 tone borders.
# [10:42] <TabAtkins> Without the limitations of using inset/outset style.
# [10:42] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [10:42] <dauwhe_> Dean: make a proposal
# [10:42] <glazou> TabAtkins, old iOS style buttons required 3 or 4 IIRC
# [10:42] <dauwhe_> ... lots of little dragons here
# [10:42] <TabAtkins> I propose we copy Moz's current behavior. ^_^
# [10:43] <dauwhe_> ... which won't happen until you try to write spec
# [10:43] <glazou> TabAtkins, +1
# [10:43] <dauwhe_> Bert: multiple everything!
# [10:43] <fantasai> TabAtkins, border-colors? No, you really really really don't want that
# [10:43] <dbaron> dbaron: no, only one border radius
# [10:43] <dauwhe_> Bert: what about border-clip?
# [10:43] <leaverou> TabAtkins: god no, that's awful
# [10:43] <TabAtkins> Hey hey, someone talk about *-1, *-2 longhands for every list-valued property.
# [10:43] <TabAtkins> Hahaha
# [10:43] * glazou waits for TabAtkins to invent a neologism for multiple borders
# [10:43] <dauwhe_> plinss: may be interesting holes there
# [10:44] <dauwhe_> fantasai: action item to write up a proposal
# [10:44] * leaverou COMMAS IN ALL THE THINGS
# [10:44] * Joins: kimwoonyoung (~kimwoonyoung@public.cloak)
# [10:44] <dauwhe_> Topic: longhand for list properties
# [10:44] * glazou has a meeting now ; have fun people
# [10:45] * dauwhe_ see you later Daniel
# [10:45] * TabAtkins is just secretly trying to get foo-1 style attributes copied into SVG, as future precedent for src-N.
# [10:45] <dbaron> just wait until we put zero-width non-breaking spaces in all the things
# [10:45] * glazou is now known as glazou_meeting
# [10:46] <dauwhe_> fantasi: if you have a list valued property, then dash-number represents that position in the list
# [10:46] <dauwhe_> plinss: what if you have -47 with a list of 3 items?
# [10:46] <dauwhe_> s/fantasi/fantasai/
# [10:46] <TabAtkins> Need to make sure that every list has a "null" value.
# [10:46] <dauwhe_> fantasai: dash ones won't take comma
# [10:46] <TabAtkins> So unfilled values between explicitly-given ones get the null.
# [10:46] <dauwhe_> plinss: concerned about cascade
# [10:47] <TabAtkins> Why concerned about cascade? This is standard longhand expansion.
# [10:47] <TabAtkins> (I think most (all?) list-valued props alreayd have null values.)
# [10:47] * Joins: glenn (~gadams@public.cloak)
# [10:47] <dauwhe_> plinss: going back and forth about the proposal
# [10:48] <dauwhe_> ... not time or place for serious discussion
# [10:48] <dauwhe_> ... let's adjourn. Thank you everyone
# [10:48] <TabAtkins> The list-valued shorthand expands into an infinity of indexed longhands. You only serialize up to the last explicitly-given index.
# [10:48] <leaverou> This solves some use cases, but not all
# [10:48] <TabAtkins> Never try to solve all use-cases.
# [10:49] <TabAtkins> Gotta keep 'em hanging on for more.
# [10:49] <leaverou> Quite often you don't have knowledge of all the items in the list and just want to add something in the beginning or end (sort of like a .push() in arrays)
# [10:49] <TabAtkins> Yeah, but that's impossible here. :/
# [10:49] <TabAtkins> We just don't have the structure for it.
# [10:49] <leaverou> so you'll end up with stuff like how people do z-index: 100000000000000000 to be at the top
# [10:49] <leaverou> and no solution for how to add something to the beginning (unless negative indices are allowed)
# [10:49] <TabAtkins> Yes.
# [10:50] <TabAtkins> Correct, these are limitations.
# [10:50] <leaverou> these are very serious limitations
# [10:50] * fantasai supports leaverou's concerns
# [10:50] <TabAtkins> "Put me at the top" is always a self-defeating desire.
# [10:50] <TabAtkins> As soon as two places want to be on top/bottom.
# [10:50] <leaverou> obviously, it's better than nothing, but I think it's worth it to try and find a solution that covers at least, I don't know, half the use cases :P
# [10:50] * Joins: kennyluck (~kennyluck@public.cloak)
# [10:50] <dbaron> we should figure out additive cascading instead
# [10:50] <TabAtkins> Mine covers half!
# [10:51] <leaverou> dbaron++
# [10:51] <TabAtkins> dbaron: If you think that's feasible.
# [10:51] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [10:51] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [10:51] <leaverou> TabAtkins: Obviously it's difficult to prove that, but I doubt it even covers 1/3
# [10:51] * Joins: cwdoh (~cwdoh@public.cloak)
# [10:51] <TabAtkins> leaverou: While we're throwing around arbitrary numbers, I'll assert that it covers at least 4/5
# [10:51] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [10:52] * Joins: shepazu (schepers@public.cloak)
# [10:52] <TabAtkins> Which hits the 80/20 rule and means we don't have to try any more.
# [10:52] <leaverou> you just pulled that number out of your bum, just like I did :P
# [10:53] * Quits: koji_ (~koji@public.cloak) (Client closed connection)
# [10:53] <fantasai> then you'll need variables for the position of the thing of interest
# [10:53] <fantasai> so property-name-variables
# [10:53] * Joins: koji (~koji@public.cloak)
# [10:54] <TabAtkins> leaverou: I thought that's what we were doing!
# [10:54] <TabAtkins> fantasai: Nah, only if you want readability.
# [10:56] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [10:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:56] <fantasai> SimonSapin: ping
# [10:56] * Quits: birtles (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [10:56] <dauwhe_> rrsagent, generate minutes
# [10:56] <RRSAgent> I have made the request to generate http://www.w3.org/2013/11/12-css-minutes.html dauwhe_
# [10:57] * Quits: kennyluck (~kennyluck@public.cloak) (kennyluck)
# [10:58] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [10:58] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [10:58] * Joins: glenn (~gadams@public.cloak)
# [10:58] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [10:58] * Quits: cwdoh (~cwdoh@public.cloak) (Ping timeout: 180 seconds)
# [10:59] * leaverou is now known as leaverou_away
# [11:00] * Quits: kimwoonyoung (~kimwoonyoung@public.cloak) ("This computer has gone to sleep")
# [11:00] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [11:01] * Joins: teoli_ (~teoli@public.cloak)
# [11:02] * Joins: teoli (~teoli@public.cloak)
# [11:03] * Joins: zcorpan (~zcorpan@public.cloak)
# [11:06] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [11:07] * leaverou_away is now known as leaverou
# [11:07] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [11:07] * Joins: zcorpan (~zcorpan@public.cloak)
# [11:07] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [11:08] * Quits: teoli_ (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [11:09] * Joins: leif (~lastorset@public.cloak)
# [11:11] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [11:13] * Joins: koji (~koji@public.cloak)
# [11:14] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [11:14] * Joins: glenn (~gadams@public.cloak)
# [11:16] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [11:18] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [11:18] * leaverou is now known as leaverou_away
# [11:22] * Quits: tobie (tobie@public.cloak)
# [11:22] <fantasai> TabAtkins: you're missing this totally awesome conversation about performant asymptotic functions
# [11:23] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:23] * Joins: koji (~koji@public.cloak)
# [11:25] * Joins: shepazu (schepers@public.cloak)
# [11:26] <Zakim> plinss, you asked to be reminded at this time to get some sleep
# [11:28] * Joins: myakura (~myakura@public.cloak)
# [11:30] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [11:32] * Joins: koji (~koji@public.cloak)
# [11:35] * Joins: antonp (~Thunderbird@public.cloak)
# [11:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:37] * Quits: kawabata2 (~kawabata@public.cloak) (Client closed connection)
# [11:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [11:39] * leaverou_away is now known as leaverou
# [11:40] * Quits: jet (~junglecode@public.cloak) (jet)
# [11:40] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [11:41] <dbaron> Zakim, bye
# [11:41] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [11:41] <dbaron> sr = br + s * (2 / pi) * arctan (K * (br / s))
# [11:41] <dbaron> sr = radius of curvature of spread
# [11:42] <dbaron> br = border radius
# [11:42] <dbaron> s = spread
# [11:42] <dbaron> K = a constant, probably worth testing in the range 3 - 20 or so
# [11:42] <dbaron> want to look at drawings with various ratios of br / s
# [11:42] <fantasai> best represented as a multiple of pi
# [11:42] <fantasai> :)
# [11:42] <dbaron> the goal is that if br is around or greater than s, sr = br + s
# [11:42] <dbaron> but that if br << s, sr = br
# [11:43] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [11:43] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [11:45] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:45] * Joins: koji (~koji@public.cloak)
# [11:46] * Joins: koji_ (~koji@public.cloak)
# [11:46] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:47] * leaverou is now known as leaverou_away
# [11:48] * Joins: darktears (~darktears@public.cloak)
# [11:48] * Quits: koji_ (~koji@public.cloak) (Client closed connection)
# [11:49] * Joins: koji (~koji@public.cloak)
# [11:49] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [11:49] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [11:50] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [11:56] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [11:58] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:02] * Joins: dbaron (~dbaron@public.cloak)
# [12:05] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:07] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [12:13] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [12:33] * Joins: koji (~koji@public.cloak)
# [12:35] * Joins: teoli_ (~teoli@public.cloak)
# [12:38] * Joins: jet (~junglecode@public.cloak)
# [12:41] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [12:41] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [12:42] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [13:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:07] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [13:08] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [13:34] * Quits: jet (~junglecode@public.cloak) (jet)
# [13:48] * Joins: Zeke_ (~Zeke@public.cloak)
# [13:53] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [13:55] * Joins: darktears (~darktears@public.cloak)
# [13:57] * Joins: teoli (~teoli@public.cloak)
# [13:58] * Joins: teoli_ (~teoli@public.cloak)
# [14:00] * glazou_meeting is now known as glazou
# [14:01] * Quits: glazou (~glazou@public.cloak) (glazou)
# [14:04] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [14:05] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [14:06] * Quits: Zeke_ (~Zeke@public.cloak) ("Leaving...")
# [14:29] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:37] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [14:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:38] * Joins: myakura (~myakura@public.cloak)
# [14:42] * Quits: tantek (~tantek@public.cloak) (tantek)
# [14:44] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [14:48] * Joins: liam (liam@public.cloak)
# [14:48] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [15:08] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:10] * Joins: Zeke (~Zeke@public.cloak)
# [15:18] * Joins: tantek (~tantek@public.cloak)
# [15:19] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [15:31] * leaverou_away is now known as leaverou
# [15:32] * Quits: Zeke (~Zeke@public.cloak) ("Leaving...")
# [15:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:39] * Joins: Zeke_ (~Zeke@public.cloak)
# [15:49] * Quits: Zeke_ (~Zeke@public.cloak) ("Leaving...")
# [15:53] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [15:53] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [15:54] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:54] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [15:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:56] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [15:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:58] * Joins: leif (~lastorset@public.cloak)
# [15:58] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:59] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:02] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:04] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:06] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:11] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [16:15] * leaverou is now known as leaverou_away
# [16:18] * leaverou_away is now known as leaverou
# [16:20] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:22] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:24] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:39] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:40] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:41] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:44] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [16:54] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:56] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:58] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:59] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:59] * Quits: michou (~Adium@public.cloak) ("Leaving.")
# [17:00] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:02] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:05] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:06] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [17:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:07] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:11] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [17:14] * Joins: Zeke (~Zeke@public.cloak)
# [17:18] * Joins: cwdoh (~cwdoh@public.cloak)
# [17:19] * leaverou is now known as leaverou_away
# [17:26] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [17:26] * Quits: Zeke (~Zeke@public.cloak) (Ping timeout: 180 seconds)
# [17:28] * leaverou_away is now known as leaverou
# [17:29] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:33] * Joins: cwdoh (~cwdoh@public.cloak)
# [17:33] * leaverou is now known as leaverou_away
# [17:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:50] * Joins: jcraig (~jcraig@public.cloak)
# [17:57] * Joins: dbaron (~dbaron@public.cloak)
# [17:58] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [17:59] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:02] * Joins: myakura (~myakura@public.cloak)
# [18:03] * Joins: masatakayakura (~myakura@public.cloak)
# [18:09] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [18:11] * Joins: rhauck (~Adium@public.cloak)
# [18:12] * Joins: rhauck2 (~Adium@public.cloak)
# [18:12] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [18:18] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [18:23] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:34] * leaverou_away is now known as leaverou
# [18:35] * leaverou is now known as leaverou_away
# [18:36] * Joins: teoli (~teoli@public.cloak)
# [18:42] * Quits: teoli_ (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [18:51] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [18:52] * leaverou_away is now known as leaverou
# [19:01] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [19:04] * Quits: masatakayakura (~myakura@public.cloak) ("")
# [19:18] * Joins: jcraig (~jcraig@public.cloak)
# [19:53] * Joins: bobby (~bobby@public.cloak)
# [19:54] * Parts: bobby (~bobby@public.cloak) (bobby)
# [20:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:00] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [20:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [20:37] * Quits: rhauck2 (~Adium@public.cloak) (Client closed connection)
# [20:44] * Joins: bobby_ (~bobby@public.cloak)
# [20:50] * Joins: cwdoh (~cwdoh@public.cloak)
# [20:54] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [20:55] * Parts: bobby_ (~bobby@public.cloak) (bobby_)
# [20:58] * Joins: jet (~junglecode@public.cloak)
# [21:00] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:07] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:15] * Joins: florian (~Adium@public.cloak)
# [21:20] * Joins: fharper (~fharper@public.cloak)
# [21:20] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [21:23] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [21:26] * Joins: florian1 (~Adium@public.cloak)
# [21:28] * Joins: Guest (~textual@public.cloak)
# [21:32] * Quits: Guest (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [21:32] * Quits: fharper (~fharper@public.cloak) ("Time to leave you, I'll be sad, but hey, it's life!")
# [21:32] * Quits: florian (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [21:33] * Joins: Guest (~textual@public.cloak)
# [21:42] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [22:01] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:01] * Quits: tantek (~tantek@public.cloak) (tantek)
# [22:06] * Joins: jcraig (~jcraig@public.cloak)
# [22:07] * Joins: glenn_ (~gadams@public.cloak)
# [22:07] * Quits: glenn (~gadams@public.cloak) (glenn)
# [22:08] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [22:20] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [22:20] * Joins: glenn (~gadams@public.cloak)
# [22:26] * Joins: glenn_ (~gadams@public.cloak)
# [22:26] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [23:05] * Quits: jet (~junglecode@public.cloak) (jet)
# [23:16] * Joins: nsakai (~nsakai@public.cloak)
# [23:16] * Quits: nsakai (~nsakai@public.cloak) ("")
# [23:18] * Joins: teoli (~teoli@public.cloak)
# [23:21] * Joins: cwdoh (~cwdoh@public.cloak)
# [23:26] * Quits: cwdoh (~cwdoh@public.cloak) (Client closed connection)
# [23:29] * Quits: florian1 (~Adium@public.cloak) ("Leaving.")
# [23:33] * Quits: Guest (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [23:33] * Joins: Guest (~textual@public.cloak)
# Session Close: Wed Nov 13 00:00:00 2013

The end :)