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

Options:

# Session Start: Thu Sep 12 00:00:00 2013
# Session Ident: #css
# [00:00] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [00:04] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [00:33] * Joins: tobie (tobie@public.cloak)
# [00:35] * Quits: lmclister (~lmclister@public.cloak) ("")
# [00:35] * Joins: lmclister (~lmclister@public.cloak)
# [00:41] * Quits: lmclister (~lmclister@public.cloak) ("")
# [00:41] * heycam|away is now known as heycam
# [00:54] * Joins: koji (~koji@public.cloak)
# [01:08] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [01:14] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [01:14] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:19] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [01:20] * Joins: myakura (~myakura@public.cloak)
# [01:20] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [01:20] * Joins: myakura (~myakura@public.cloak)
# [01:20] * leaverou is now known as leaverou_away
# [01:21] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:36] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:39] * Joins: rhauck1 (~Adium@public.cloak)
# [01:42] * Joins: koji (~koji@public.cloak)
# [01:45] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [01:46] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:12] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:12] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [02:20] * Joins: cabanier (~cabanier@public.cloak)
# [02:22] * Quits: tobie (tobie@public.cloak)
# [02:24] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:31] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:44] * Joins: koji (~koji@public.cloak)
# [02:53] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:51] * Quits: tantek (~tantek@public.cloak) (tantek)
# [04:05] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [04:06] * Joins: myakura (~myakura@public.cloak)
# [04:13] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [04:17] * heycam is now known as heycam|away
# [04:50] * Joins: myakura (~myakura@public.cloak)
# [05:05] * Joins: lmclister (~lmclister@public.cloak)
# [05:32] * Disconnected
# [05:33] * Attempting to rejoin channel #css
# [05:33] * Rejoined channel #css
# [05:33] * Topic is 'http://wiki.csswg.org/planning/paris-2013#agenda'
# [05:33] * Set by astearns on Wed Sep 11 13:36:27
# [05:36] * Quits: krijn (~krijnhoetmer@public.cloak) (Ping timeout: 180 seconds)
# [05:38] * heycam|away is now known as heycam
# [05:42] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [05:42] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:45] * Quits: lmclister (~lmclister@public.cloak) ("")
# [06:08] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [06:09] * Joins: myakura (~myakura@public.cloak)
# [06:16] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [06:23] * Joins: lmclister (~lmclister@public.cloak)
# [06:29] * Joins: myakura (~myakura@public.cloak)
# [06:38] * Joins: shans__ (~shans_@public.cloak)
# [06:42] * Quits: lmclister (~lmclister@public.cloak) ("")
# [06:43] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [06:43] * Joins: shans__ (~shans_@public.cloak)
# [07:32] * Joins: ian (~ian@public.cloak)
# [07:43] * Quits: ian (~ian@public.cloak) (Ping timeout: 180 seconds)
# [07:57] * Joins: teoli (~teoli@public.cloak)
# [08:04] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [08:04] * Joins: myakura (~myakura@public.cloak)
# [08:11] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [08:12] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [08:28] * Joins: dbaron (~dbaron@public.cloak)
# [08:46] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [08:54] * Joins: tantek (~tantek@public.cloak)
# [08:58] <jdaggett> dbaron: you guys are starting soon?
# [08:59] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:59] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [09:02] <jdaggett_> dbaron: so you fiddling with the camera?
# [09:03] <dbaron> jdaggett_, not taht many people here yet
# [09:03] * Quits: jdaggett_ (~jdaggett@public.cloak) (jdaggett_)
# [09:04] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [09:04] * jdaggett_ hmm
# [09:05] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:05] * jdaggett_ is now known as jdaggett
# [09:06] * Joins: glazou (~glazou@public.cloak)
# [09:07] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:12] * jdaggett ah, i've become me again...
# [09:13] <jdaggett> dbaron: quorum yet?
# [09:14] * Joins: shans__ (~shans_@public.cloak)
# [09:18] * Joins: astearns (~astearns@public.cloak)
# [09:19] * Joins: tantek (~tantek@public.cloak)
# [09:22] <glazou> jdaggett, nah room 1/2 empty :-(
# [09:22] <glazou> even peter running late
# [09:22] <jdaggett> well, can we just resolve on everything i'd like to resolve...?
# [09:23] <jdaggett> glazou: ^
# [09:23] * Joins: ian (~ian@public.cloak)
# [09:29] * liam catching up on workshop email and will be at css f2f later
# [09:29] <glazou> liam, you did not tell me if i can attend workshop...
# [09:30] <liam> see msg (sorry)
# [09:30] * Joins: jet (~junglecode@public.cloak)
# [09:31] <jdaggett> dbaron: almost?
# [09:33] * Joins: teoli (~teoli@public.cloak)
# [09:34] * Joins: cyril (~cyril@public.cloak)
# [09:37] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:38] * Joins: leif (~lastorset@public.cloak)
# [09:39] <fantasai> ScribeNick: fantasai
# [09:39] <fantasai> Topic: Font Load events
# [09:39] <glazou> jdaggett, starting
# [09:39] <jdaggett> dbaron: can you enable the camera?
# [09:40] <glazou> jdaggett, reviewed it, I have no real comment, no I don't find it strange
# [09:40] <jdaggett> hmmm
# [09:40] <jdaggett> document.fonts.clear() isn't a tad odd?
# [09:41] <glazou> the name yes, the feature, no
# [09:41] <jdaggett> um
# [09:41] <jdaggett> so you have n @font-face rules and you call that
# [09:41] * Joins: projector (~projector@public.cloak)
# [09:41] * Joins: sgalineau (~sgalineau@public.cloak)
# [09:41] <dbaron> trackbot, start telecon
# [09:41] * trackbot is preparing a teleconference.
# [09:41] <jdaggett> you'll have n @font-face rules in your om
# [09:41] <trackbot> RRSAgent, make logs member
# [09:41] <RRSAgent> I have made the request, trackbot
# [09:41] * Joins: Zakim (zakim@public.cloak)
# [09:41] <trackbot> Zakim, this will be Style_CSS FP
# [09:41] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [09:41] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [09:41] <trackbot> Date: 12 September 2013
# [09:41] <dbaron> RRSAgent, make logs public
# [09:41] <RRSAgent> I have made the request, dbaron
# [09:41] <dbaron> Zakim, remind us in 9 hours to go home
# [09:41] <Zakim> ok, dbaron
# [09:42] <glazou> jdaggett, and it clears the fonts loaded in the layout engine, yes
# [09:42] <glazou> despite of rules
# [09:42] <glazou> super useful
# [09:43] <fantasai> TabAtkins: Quick intro on new spec for font load events
# [09:43] <fantasai> TabAtkins: John just sent a bunch of really nice comments on improving spec prose, but nothing major iirc
# [09:43] * leaverou_away is now known as leaverou
# [09:43] <fantasai> jdaggett: Last part of mail suggests fundamental change
# [09:44] <fantasai> TabAtkins: Iteration order?
# [09:44] <fantasai> jdaggett: Yeah, and just how add and delete should throw for CSS-connected font base objects
# [09:44] <fantasai> TabAtkins: Ok, think that's reasonable to discuss after intro
# [09:44] <fantasai> TabAtkins: Recall original proposal John made at last F2F, FontLoad interface, 5 interfaces related to all fonts, 3 for individual fonts
# [09:44] * Joins: ChrisL (clilley@public.cloak)
# [09:44] <fantasai> TabAtkins: Based on consensus, redesigned around Future
# [09:45] <fantasai> TabAtkins: Roughly based on blog post, but made some changes based on thinking of how to make this work in Workers
# [09:45] <fantasai> TabAtkins: Have no story of how to ship a font face over to Workers
# [09:45] <fantasai> TabAtkins: So, start with FontFaceSet
# [09:45] <fantasai> TabAtkins: Closest analogue to John's proposal
# [09:46] <fantasai> TabAtkins: It's a set class, which while not defined in WebIDL quite yet, but similar to Map class that is defined there
# [09:46] * Joins: yamamoto (~yamamoto@public.cloak)
# [09:46] <fantasai> TabAtkins: Acts like a JS set, containing a bunch of Font faces
# [09:46] <fantasai> TabAtkins: Methods and events
# [09:46] <fantasai> TabAtkins: To address original issues, still retained 3 of the events: loading, loadingdone, and loadingerror
# [09:46] <fantasai> TabAtkins: These fire with regards to every single font load
# [09:47] <fantasai> TabAtkins: onload fires as soon as doc starts loading fonts, loadingdone when it's done, simultaneous with loadingerror if there was a failure
# [09:47] <fantasai> TabAtkins: Past events, there are promise-based functions
# [09:47] <fantasai> TabAtkins: load() function, give it font value and optionall some text you want to render with it
# [09:47] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:48] <fantasai> TabAtkins: check() just checks, not async
# [09:48] <fantasai> TabAtkins: ready() promis fulfills once all fonts are loaded
# [09:48] <fantasai> TabAtkins: In blog post and F2F dicussion
# [09:48] <fantasai> TabAtkins: I also added a match() function as well, which exposes CSS font matching algorithm.
# [09:48] <dbaron> s/In/This was previously described in my/
# [09:49] <fantasai> TabAtkins: Returns list of what fonts would be used for some text
# [09:49] <fantasai> jdaggett: The match() method won't work
# [09:49] <fantasai> jdaggett: You can have platform fonts in there, so unless you create font entries for platform fonts, won't work
# [09:49] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [09:49] <fantasai> jdaggett: Honestly, don't think you really want to expose nitty gritty of font matching, unless you have a good reason
# [09:49] <fantasai> glazou: Isn't it security/privacy hole?
# [09:49] <ChrisL> exposing platform fonts is a privacy/profiling issue perhaps
# [09:50] <fantasai> glazou: Web page could discover which fonts you have installed on the system
# [09:50] <fantasai> fantasai: You could figure that out by just ask for local before webfonts, then see which fonts got loaded
# [09:51] <fantasai> dbaron: ...
# [09:51] * fantasai pls fill in...
# [09:51] <fantasai> jdaggett: When you have explicit name of a platform font in the match list. I assume your method doesn't pull in fallback fonts
# [09:51] <fantasai> TabAtkins: Why don't I want to expose fallback fonts?
# [09:51] <ChrisL> s/.../the only way to prevent that would have been to prevent browsers ever loading local fonts
# [09:51] <fantasai> jdaggett: Would be really system specific
# [09:51] <dbaron> s/.../I don't think we can solve the fingerprinting issue without having browsers ship with a set of fonts and then allowing only those and downloadable fonts, and not arbitrary local fonts/
# [09:52] <fantasai> fantasai: Are you talking about system fallback font, or falling back down the list?
# [09:52] <fantasai> jdaggett: System fallback font
# [09:52] <Bert> (I think we should be able to restrict local() to browser and user style sheets.)
# [09:52] <fantasai> jdaggett: That method really needs to have some justification
# [09:52] <fantasai> jdaggett: Use case is just, here's a string that I want to render, just want to make sure that all fonts needed are loaded
# [09:53] <fantasai> TabAtkins: I went through the spec trying to figure out what primitives are needed
# [09:53] <fantasai> TabAtkins: This method was really useful for describing other algorithms
# [09:53] <fantasai> TabAtkins: Although we could make it just a spec-internal method
# [09:53] <fantasai> jdaggett: Anyway, I think we can move on. Just want to note that I think it's a bad idea.
# [09:53] <fantasai> TabAtkins: Ok, if it winds up beign a bad idea, I'll just shift the algorithm to being spec-internal
# [09:53] * Quits: tantek (~tantek@public.cloak) (tantek)
# [09:53] <fantasai> TabAtkins: Anyway, that's the entire FontFaceSet interface, what we discussed at F2F
# [09:54] <fantasai> TabAtkins: Past this is what I had to invent to make ti work well with workers
# [09:54] <fantasai> TabAtkins: One is the FontFace interface
# [09:54] <fantasai> TabAtkins: It is a rough analogue of CSS font-face rule
# [09:54] <fantasai> TabAtkins: But doesn't have any connections to document / style sheet
# [09:54] <fantasai> TabAtkins: So safe to ship to a woker
# [09:55] <fantasai> TabAtkins: load() and ready() methods
# [09:55] <fantasai> TabAtkins: Has also a match() function, which returns bool. John explained why he doesn't think it'll work, so might drop that.
# [09:55] <fantasai> TabAtkins: FontFace can be generated from @font-face rules, or can be constructed via JS
# [09:56] <fantasai> TabAtkins: And that's the entire spec
# [09:56] <fantasai> TabAtkins: Only place I haven't written out yet is the itneraction between CSS and these interfaces
# [09:56] <fantasai> TabAtkins: As I said, each @font-face rule should automatically generate a FontFace object, separate from CSSOM object, and insert into document.fonts
# [09:57] * Joins: michou (~mibalan@public.cloak)
# [09:57] * Joins: israelh (~israelh@public.cloak)
# [09:57] <fantasai> TabAtkins: This is connected up with font-face rule, so that CSSOM and FontFace object reflect each other
# [09:57] <fantasai> TabAtkins: Adding or removing @font-face rules will automatically add/remove FontFace rules
# [09:57] <fantasai> TabAtkins: Intention is that font matching algorithm will iterate over FontFaceSet, not just @font-face rules and local fonts
# [09:57] <fantasai> TabAtkins: jdaggett has a whole bunch of comments, which I'll need to address
# [09:58] <fantasai> jdaggett: The main concern I have about what you specc'ed out already is that while adding a new font-face rule automatically populates into FontFaceSet, if you remove it from that, @font-face is not updated reflect that
# [09:58] <fantasai> jdaggett: So posted restrictions on how that shoudl work
# [09:58] <fantasai> TabAtkins: While I did say that FontFace and font-face rules are connected, there's no connection between them and the style sheets
# [09:59] <fantasai> TabAtkins: So an @font-face rule could still be present in CSSOM after FontFace is removed from FontFaceSet
# [09:59] <fantasai> glazou: Comments on iterating over FontFaceSet
# [09:59] <fantasai> glazou: Seem a little inconsistent
# [09:59] <fantasai> glazou: clear() seems like "unloadAll()", while size() is more like ?
# [10:00] <fantasai> jdaggett: That's the pattern in JS
# [10:00] <fantasai> TabAtkins: clear() doesn't unload, just removes everything from the set
# [10:00] <fantasai> TabAtkins: fonts are still there, if you pulled them out of the set and have reference to those FontFaces
# [10:00] <fantasai> jdaggett: inconsistent from existing DOM APIs
# [10:00] <fantasai> TabAtkins: delete() is fine?
# [10:01] <fantasai> jdaggett: But it is consistent with other JS apis
# [10:01] <fantasai> jdaggett: So for Workers case, this might be more appropriate
# [10:01] * fantasai thinks clear() is clear enough
# [10:01] <fantasai> SteveZ: So clear() removes items from the set, but doesn't delete them
# [10:01] <fantasai> glazou: You may want to add a note clarifying this.
# [10:01] <fantasai> TabAtkins: Think it might be confusing b/c JS sets are new
# [10:02] <fantasai> jdaggett: Could define collection object that matched [?]
# [10:02] <fantasai> TabAtkins: No, people hate collections. With reason. Bad idea.
# [10:02] <fantasai> TabAtkins: Do you have suggestions for better integration between FontFaceSet and CSS @font-face rules
# [10:02] <fantasai> ?
# [10:03] <fantasai> TabAtkins: CSS font-face rules still generate FontFace objects, but can't be removed from FontFaceSet
# [10:03] * Joins: krit (~krit@public.cloak)
# [10:03] <fantasai> jdaggett: In other words, if CSSOM is created, would have to remove it from OM
# [10:03] * fantasai got confused
# [10:03] <fantasai> jdaggett: Trying to remove it from FontFaceSet would throw an exception
# [10:04] <fantasai> TabAtkins: Seems reasonable to me
# [10:04] <fantasai> TabAtkins: As long as FontFace object is in FontFaceSet, would be connectd to style sheet
# [10:04] <fantasai> jdaggett: Tab, are you thinking this going to be transferrable?
# [10:04] <fantasai> TabAtkins: Whichever one doesn't neuter, just copies over
# [10:04] <fantasai> jdaggett: Seems like this should be cloned
# [10:05] <fantasai> TabAtkins: So, you agree, after you transfer it is like normal FontFace and can be added to Workers set like normal?
# [10:05] <fantasai> jdaggett: Sure
# [10:05] <fantasai> TabAtkins: I'm ok with this, simplifies some things
# [10:05] <fantasai> jdaggett: Yeah, bc way you were trying to manage collection seemed really weird
# [10:05] <fantasai> TabAtkins: OK
# [10:05] <fantasai> TabAtkins: Any other changes besides clarifications?
# [10:05] <fantasai> jdaggett: Haven't looked carefully at other parts of spec
# [10:06] <fantasai> jdaggett: e.g. haven't looked at Promises part
# [10:06] <fantasai> TabAtkins: Promises prose is up-to-date with latest spec
# [10:06] <fantasai> jdaggett: Not so worried about that
# [10:06] <fantasai> TabAtkins: Any other comments?
# [10:06] <fantasai> krit: I want Futures instead
# [10:06] <fantasai> ChrisL: In the Future
# [10:07] <fantasai> ...
# [10:07] * zcorpan http://w3cmemes.tumblr.com/post/48887723979/does-your-api-use-futures-yet
# [10:07] <fantasai> TabAtkins: Promises spec is in GitHub atm, expecting it to move over to WHATWG at some point
# [10:07] <projector> https://github.com/domenic/promises-unwrapping
# [10:07] <fantasai> jdaggett: Also I think we need heycam to add set class to WebIDL
# [10:07] <fantasai> TabAtkins: Agreed
# [10:07] * heycam acks
# [10:08] <fantasai> TabAtkins: Review by others would be great, because we are chomping at bit to implement this
# [10:08] <fantasai> israelh: Do you have eventing model here to be replaced by Promises model, or co-exist?
# [10:08] <fantasai> TabAtkins: Will co-exist. Events and Promises do different things
# [10:08] <fantasai> TabAtkins: A lot of things are better off as Promises, but things that fire multiple times are better done as events
# [10:09] <fantasai> israelh: ... Do you get promise and event simultaneously?
# [10:09] <fantasai> TabAtkins: Yes
# [10:09] <fantasai> TabAtkins: One is right before other, but adjacent steps in algo
# [10:09] <fantasai> israelh: Will there be a suggestion of which to listen for?
# [10:09] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [10:09] * Joins: ChrisL (clilley@public.cloak)
# [10:09] <fantasai> TabAtkins: I expect individuals to use different things
# [10:09] <fantasai> TabAtkins: If you want to do something after fonts load, Promise is better
# [10:10] <jdaggett> tabatkins: more typey less talky
# [10:10] <fantasai> TabAtkins: but if you want to have e.g. an indicator of whether fonts are loaded or not, event is better
# [10:10] <fantasai> Everyone is cool with this.
# [10:11] <fantasai> Topic: TPAC and F2F Scheduling
# [10:12] <fantasai> plinss: Sent email wrt space for Sunday meeting, but no response back
# [10:12] <fantasai> SteveZ: There is I believe an event put together by the sponsors that day
# [10:12] <fantasai> jdaggett: Anyone have an office in Shenzhen?
# [10:14] <jdaggett> ...peter is mumbling...
# [10:14] <fantasai> plinss: Doesn't seem like anyone can offer space atm
# [10:14] <dbaron> I think our closest office to Shenzhen with a conf room big enough for the CSS WG is... Paris! :-)
# [10:14] <fantasai> plinss: If you find out about space, let us know
# [10:14] <fantasai> plinss: We have a request from SVGWG for joint meeting on Tuesday
# [10:14] <glazou> dbaron, I can live with that :-)
# [10:14] <fantasai> TabAtkins: Alternately, b/c our schedule is usually packed, could overlap with them on Thursday
# [10:14] <jdaggett> google hong kong?
# [10:14] <fantasai> fantasai: could do half and half
# [10:14] <fantasai> dbaron: Note that AC meeting is Tues afternoon / Thurs morning
# [10:15] <fantasai> plinss: Any fxtf people not going to be around on Thursday?
# [10:15] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [10:15] <fantasai> silence
# [10:15] * Joins: ChrisL (clilley@public.cloak)
# [10:15] <fantasai> plinss: Next topic would be F2F meetings for next year
# [10:16] <fantasai> sylvaing: We can host in Seattle
# [10:16] * fantasai can't hear anything
# [10:16] <jdaggett> http://wiki.csswg.org/planning
# [10:16] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [10:16] <jdaggett> i put strawman proposals in there
# [10:16] <fantasai> plinss: Were thinking East Coast in Feb. Works for folks?
# [10:17] <jdaggett> didn't someone offer nyc?
# [10:17] <jdaggett> cmon, the buildings are heated...
# [10:17] <glazou> jdaggett, justin erenkranz did
# [10:18] <fantasai> [unminuted discussion]
# [10:18] * jdaggett what's peter talking about...? feb meeting?
# [10:18] * ChrisL yes, in NY
# [10:18] <dbaron> jdaggett, who were you thinking of as host for Taiwan?
# [10:18] * ChrisL we can't hear much either
# [10:18] <jdaggett> dbaron: moztaiwan
# [10:18] <dbaron> jdaggett, I don't remember a room big enough
# [10:18] <fantasai> narrowing to 1st week of Feb
# [10:19] <fantasai> asking wrt preferences on days
# [10:19] * Joins: teoli (~teoli@public.cloak)
# [10:19] <fantasai> proposal: Feb 4-6
# [10:19] <jdaggett> well, we can propose it, then investigate the possibility
# [10:19] <hober> RESOLVED: plinss should always be miked.
# [10:19] <fantasai> :P
# [10:19] <jdaggett> YES!!
# [10:19] * hober err, mic'ed
# [10:19] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [10:19] <glazou> I read that as milked
# [10:19] * Joins: shans__ (~shans_@public.cloak)
# [10:19] <jdaggett> anytime in feb is good for me
# [10:20] <jdaggett> oh, very nice...
# [10:20] <glazou> proposal is 4-6 feb 2014
# [10:20] <jdaggett> yes
# [10:20] <hober> s/miked/mic'ed/
# [10:20] <jdaggett> nyc is fine
# [10:20] <fantasai> plinss: NYC or West coast?
# [10:21] * hober fantasai: note that i didn't emote the resolution... :)
# [10:21] <jdaggett> snow is pretty
# [10:21] <jdaggett> and we can have a css hockey game
# [10:21] <dbaron> jdaggett, the what?
# [10:22] <jdaggett> w3c office at mit
# [10:22] <jdaggett> interesting interaction with tech folks at mit?
# [10:22] <fantasai> koji: that week conflicts with UTC
# [10:22] <dbaron> koji: UTC is Feb 3-7
# [10:23] <fantasai> proposal: 10-12 Feb
# [10:24] <fantasai> proposal: jan 28-30
# [10:24] <jdaggett> what's the proposed location? seattle?
# [10:24] <fantasai> NYC
# [10:24] <dbaron> http://www.unicode.org/timesens/calendar.html
# [10:24] <jdaggett> good
# [10:24] <fantasai> krit: Seattle could do joint with SVG
# [10:24] <dbaron> (and http://www.unicode.org/L2/meetings/utc-meetings.html )
# [10:25] <fantasai> krit: CSS/SVG split the week, fxtf on wed
# [10:25] <fantasai> krit: in Seattle
# [10:26] <fantasai> Tentative resolution: Jan 27-31, joint meeting with SVG, in Seattle, hosted by Adobe
# [10:26] <jdaggett> nice feedback
# [10:28] <fantasai> Discussing locations for May
# [10:30] <fantasai> Thinking Asia in May, Sophia in Sept
# [10:31] <fantasai> fantasai: Maybe we can meet in Korea for May, and trap some Korean typesetters for interrogation
# [10:32] <fantasai> dbaron: May is always a crunch of conflicts
# [10:32] <fantasai> glazou: I have to check wrt hosting in Korea
# [10:32] <jdaggett> first week of may is holidays in japan
# [10:32] <jdaggett> oh, that's right, mr. samsung!!
# [10:32] <fantasai> glazou: Not sure Samsung can offer the facilities we need, access to conference rooms / open internet. Security there is super strong
# [10:33] <jdaggett> dbaron: ok, gotta run
# [10:33] <jdaggett> dbaron: back after 2:30 your time
# [10:33] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [10:33] <Bert> (Cannes Filem Festival, if you think of coming to the French Riviera, is 14-25 May 2014)
# [10:34] <Bert> (WWW2014 in Seoul is April 7-14)
# [10:34] * Joins: koji (~koji@public.cloak)
# [10:35] <fantasai> plinss: Mark out May 12-16, several folks to investigate locations in Asia
# [10:35] <fantasai> plinss: Sophia in September, pick dates later?
# [10:35] <fantasai> OK
# [10:36] <fantasai>
# [10:38] <fantasai> koji - http://www.w3.org/Style/CSS/members.en
# [10:42] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [10:46] * Joins: astearns (~astearns@public.cloak)
# [10:47] * Joins: astearns_ (~astearns@public.cloak)
# [10:47] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [10:47] <fantasai> TabAtkins: Simon was asking about alternate chars for token markup, how about white tortoise shell brackets?
# [10:48] <fantasai> http://www.fileformat.info/info/unicode/char/3018/index.htm
# [10:48] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [10:48] * Joins: ChrisL (clilley@public.cloak)
# [10:49] * Quits: jet (~junglecode@public.cloak) (jet)
# [10:50] * Joins: liam (liam@public.cloak)
# [10:55] * Joins: tantek (~tantek@public.cloak)
# [11:00] <TabAtkins> 〘url〙
# [11:01] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:01] * Joins: jet (~junglecode@public.cloak)
# [11:04] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:05] <Bert> Scribe: Bert
# [11:05] <Bert> Topic: CSS Masking
# [11:06] <Bert> krit: [moves to whiteboard]]
# [11:06] <Bert> ... Three topics.
# [11:07] <astearns_> http://www.w3.org/TR/css-masking/
# [11:07] <Bert> ... For mask image, compat with SVG
# [11:08] <Bert> ... 2nd option is to list an image, (like bg image)
# [11:08] <Bert> ... List of mask images, compose togther, than mask
# [11:08] <Bert> ... But impls actually mask each image individually.
# [11:09] <Bert> ... (drawing on wboard)
# [11:09] <astearns_> draws union of shapes as a single mask versus using shapes masking each other
# [11:10] <Bert> ... (result is typically smaller)
# [11:10] <Bert> ... I suggest to use this mode, as it is already implemented.
# [11:10] <Bert> ... Yu can do the other already in a different way.
# [11:10] <Bert> ... So you get more options.
# [11:10] <Bert> fantasai: Not obvious how to get the other, though.
# [11:10] <Bert> krit: Agree
# [11:11] <Bert> ... Webkit and blink impl like this.
# [11:11] <Bert> fantasai: Can we define the property as accepting just one value, not a list?
# [11:11] <Bert> ChrisL: Then you get less functionality.
# [11:11] <Bert> krit: Alpha mask abd lumi mask are different.
# [11:11] * Joins: Rossen_ (~Rossen@public.cloak)
# [11:12] <Bert> ... Lumi mask needs to be converted. (Usually by hardware.)
# [11:12] <Bert> Jet: (About drawing:) is it an intersection.
# [11:12] <Bert> krit: That is effetc of masking in sequence.
# [11:13] <Bert> jet: Diffeeren order of images gives same result?
# [11:13] <Bert> krit: same result, yes.
# [11:13] <Bert> dbaron: It's multiplication alpha, in fact.
# [11:13] <dbaron> s/It's/Is it just
# [11:13] <Bert> lea: Anything in Cmpositing that allows people to compose images for masks?
# [11:13] <dbaron> dirk: could just do it with multiplication of alpha
# [11:14] <Bert> krit: You mean if mask only accepts one image?
# [11:14] <Bert> ChrisL: If it were implemented...
# [11:14] <Bert> leaverou: Is it really useful to have multiple masks?
# [11:15] <ChrisL> advanced compositing is a more recent addition so less supported. masking has been in svg forever
# [11:15] <Bert> tab: thumbs up from Blink :-)
# [11:15] <hober> hober: and webkit
# [11:15] <Bert> krit: You can control. Compose and mask first.
# [11:16] <Bert> fantasai: Logically similar results, but confusing to authors.
# [11:16] <Bert> ... I'd limit it to one layer.
# [11:16] <Bert> ... If we allow multiple layers, then we should also allow operations on them.
# [11:16] <Bert> ... So no need to use SVG as well.
# [11:17] <Bert> krit: USe case of repeating mask pattern and then a single mask for the whole image.
# [11:17] <Bert> ... There are use cases, but fine to restrict to one mask for now.
# [11:17] <Bert> fantasai: I don't like to have just one way of compositing images.
# [11:18] <Bert> ChrisL: Could add ...
# [11:18] <dbaron> ChrisL: doesn't prevent adding a new property later whose default is intersection
# [11:19] * Bert has some failing keys on kbd :-(
# [11:19] <Bert> fantasai: So i'd either limit ot on elayer, or allow operaitons on layers, or at least say that that is where we're going.
# [11:19] <Bert> ChrisL: Reasonable.
# [11:19] <Bert> krit: OK to limit to one layer for now.
# [11:20] <Bert> ChrisL: Any suggestions for how extension might look, krit?
# [11:20] <Bert> krit: Not a comma separated list of operations, just one kwyword, on an extra proeprty.
# [11:21] <Bert> plinss: Or what Lea said, extend the image() type.
# [11:21] <Bert> krit: You could in fact already use the crossfade() today.
# [11:21] <Bert> TabAtkins: But percentages must add up to 100%.
# [11:21] <Bert> plinss: But could create another type for that.
# [11:22] <Bert> fantasai: Yes, but also whether the image is stretched to box or not, and other operations.
# [11:22] <Bert> ... UNion and intersection are just two examples of the oeprations, there are more.
# [11:23] <Bert> ... Order of layers doesn't matter, right? We could have different separateors: slash, comma,...
# [11:23] <Bert> krit: HArd to implement.
# [11:23] <Bert> ... exclusions is already easier than the union to implement.
# [11:23] <Bert> ... One operation only is easier.
# [11:24] <Bert> liam: As soon as you have union and interesection, you also want difference.
# [11:24] <Bert> TabAtkins: So a compositing function miht be reasonable in the future.
# [11:25] <Bert> krit: resolve on restricting to one layer for this level?
# [11:25] <Bert> ChrisL: If we decide just a simgle image as mask, will BLink then change its impl?
# [11:26] <Bert> ... If they continue, then when we add functionality, we're stuck.
# [11:26] <Bert> hober: Single layer case would not change, right?
# [11:26] <Bert> krit: Correct.
# [11:26] <Bert> hober: Prefixed propeerty can cntinue, unpereficed would ,match spec.
# [11:27] <leaverou> s/lea:/leaverou:/
# [11:27] * hober that first hober isn't me
# [11:27] <Bert> RESOLVED: Just one layer.
# [11:27] * ChrisL just one lea
# [11:28] <Bert> krit: I want ot combine two cases:
# [11:29] <Bert> ... combine masked referenced with CSS images as a list in the mask-image property.
# [11:29] <Bert> TabAtkins: Yes, that is possible.
# [11:29] <Bert> krit: Resolve on that?
# [11:30] <Bert> ... Example: filter proeprty:
# [11:30] <Bert> ... can combine in a list. I want the same for mask property.
# [11:30] <Bert> ChrisL: Yes, reasonable.
# [11:31] <Bert> fantasai: Works for me.
# [11:31] <Bert> ... So can have masked image that points to SVG image?
# [11:31] <Bert> krit: Yes, or to CSS image.
# [11:31] <Bert> RESOLVE: combine CSS images and CSS mask references in th emask-image property.
# [11:32] <Bert> krit: last issue is mask shorthand.
# [11:32] <Bert> ... fantasai suggested 'none' as value.
# [11:32] <Bert> ... THat disables mask box as well.
# [11:32] <Bert> ... "Super-shorthand"
# [11:33] <Bert> krit: With 'mask: none' you disable all mask oeprations.
# [11:33] <Bert> dbaron: Still invariant that any value of 'mask' diables mask-box?
# [11:34] <Bert> krit: Yes, you can reset mask-box, not set it to any particulat value.
# [11:34] <Bert> dbaron: OK, shorthand always set all theoir properties, even if that cannot set all values.
# [11:34] <Bert> krit: OK, reasonable.
# [11:34] <Bert> ChrisL: Spec needs example for this, for 'none'
# [11:35] <Bert> ... Not example, actual text.
# [11:35] <Bert> krit: Yes, and example as well.
# [11:35] <Bert> ChrisL: Yes, define what it does.
# [11:35] <ChrisL> makes it testable
# [11:35] <Bert> fantasai: mask-repeat defaults to repeat. Should that change?
# [11:36] <Bert> krit: Was for smilarity to background.
# [11:36] <Bert> ... but expect that most people indeed want to change it.
# [11:36] <Bert> fantasai: More common to have no-repeat,
# [11:36] <Bert> ChrisL: Agree
# [11:36] <Bert> krit: Agree
# [11:36] * heycam is now known as heycam|away
# [11:36] <Bert> RESOLVED: default value for mask-repeat is no-repeat.
# [11:37] <Bert> RESOLVED: Add keyword 'none' to 'mask'
# [11:37] <Bert> fantasai: Should mask-position be center by default?
# [11:37] <Bert> lea: Yeah!
# [11:37] <Bert> krit: makes sense...
# [11:38] <Bert> RESOLVED: Default for mask-position is 'center'
# [11:38] <leaverou> s/lea:/leaverou:/
# [11:38] <Bert> fantasai: mask-origin...
# [11:39] <Bert> krit: use mask-clip (scribe missed)
# [11:40] <Bert> fantasai: Say you non symmetrical borders and want to center it.
# [11:40] <Bert> plinss: Change that, too?
# [11:40] <Bert> krit: mask-oroign should idefault to border-box.
# [11:40] <leaverou> s/oroign/origin/
# [11:41] <Bert> RESOLVED: default for 'mask-origin' is 'border-box'
# [11:41] <Bert> plinss: next agenda topic?
# [11:41] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [11:42] * Joins: yamamoto (~yamamoto@public.cloak)
# [11:42] <Bert> Topic: naming of DOMpoint and matrix
# [11:42] <dbaron> s/DOMpoint/DOMPoint, Quad,/
# [11:43] <Bert> krit: Suggestion was to use "CSS" as prefix.
# [11:43] <Bert> ... I have no preference.
# [11:43] <Bert> ... Another question form hixie was about calling it Matrix.
# [11:43] <Bert> ... We have history of SVGMatrix.
# [11:44] <Bert> ... Also MSMatrix.
# [11:44] <Bert> ... SVG wants to combine them and make new name,
# [11:44] <Bert> ... Hiie suggest just using SVGMatrix.
# [11:44] * Joins: ChrisLilley (clilley@public.cloak)
# [11:44] <Bert> Tab: No pb with SVGMatrix as such, but pb with inconsistent prefixes.
# [11:45] <Bert> krit: duplicate the names.
# [11:45] <Bert> TabAtkins: Use "SVG" on everything in geometry.
# [11:45] <Bert> krit: Not sure we can come up with solution here.
# [11:46] * ChrisLilley suggests using a colon to separate the svg and the rest of the name. maybe tie to URI space too...
# [11:46] <Bert> SimonP: Precedent for having two names, e.g., Document and HTMLDocument, as alias.
# [11:46] <Bert> ... Could do the same trick.
# [11:46] <Bert> ... Have SVGMatrix point ot same i/f object.
# [11:47] <Bert> krit: Anybody preferences?
# [11:47] <Bert> TabAtkins: Fine with that.
# [11:47] <Bert> ... I just want all objects to have the same prefix.
# [11:47] <Bert> ... Can use "DOM" prefix.
# [11:48] <Bert> fantasai: Start with an "X" :-)
# [11:48] <Bert> ... common prefix for geometry things makes sense.
# [11:49] <ChrisLilley> x marks the point
# [11:49] <Bert> simonp: Any objection to "DOM"?
# [11:49] <Bert> ... With SVGMAtrix an alias?
# [11:49] * dbaron suspects some TAG members might have an opinion here
# [11:49] <Bert> ChrisL: SVG didn't want to pretend to have the global Matrix, so "SVGMatrix" instead.
# [11:50] <Bert> simonp: If you change prototype of SVGMatrix, than pointer would not work, but alias would.
# [11:50] <Bert> fantasai: So action the TAG to bikeshed us? :-)
# [11:50] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [11:51] <Bert> RESOLVED: Provisonally go for DOM prefix.
# [11:53] <Bert> [Agenda discussion, lunch expected in 25 minutes]
# [11:53] <Bert> Topic: Sticky position
# [11:53] <dbaron> https://etherpad.mozilla.org/yqbijwrHI6
# [11:53] <Bert> dbaron: A feature that someone at Apple proposed a year ago.
# [11:54] <Bert> ... A bunch of people find it useful.
# [11:54] <Bert> ... Use case is things like in iOS UI, such as calendar, with headers above, and header will stay when you scroll,
# [11:54] <Bert> ... but be replaced by next header when that appears.
# [11:55] <Bert> TabAtkins: I could show demo...
# [11:55] <Bert> Rossen_: Related to Position spec?
# [11:55] <Bert> dbaron: Not sure which spec.
# [11:56] <projector> https://air.mozilla.org/intern-presentation-ford/
# [11:56] <fantasai> Useful in general for cases wher eyou have a header followed by some content (e.g. table rows) where you want the header visible, but the entire content below the header doesn't fit on one screen
# [11:56] <Bert> Rossen_: Was in San Diego ftf when people proposed Positing spec.
# [11:56] <Bert> ... But no edits ever made.
# [11:56] <Bert> ... I'll get some tetx I got yesterday into the spec,
# [11:57] <Bert> dbaron: See my URL above.
# [11:57] * liam wonders if the side-heads on http://stevelosh.com/blog/2013/09/teach-dont-tell/ (scroll down until one appears) are examples, and if so how transitions are handled
# [11:57] <Bert> hober: Russel yesterday sent diff.
# [11:57] <Bert> dbaron: So I guess this is moving along.
# [11:57] <Bert> ... Gecko has it mostly implemented.
# [11:58] <Bert> ... (picture on screen)
# [11:58] <Bert> ... Sticky is a bit like relative, like fixed is to absolute.
# [11:59] <Bert> Bert: (describes case of target of link being underneath fixed pos elt)
# [12:00] <Bert> dbaron: Not the same case, that is bug in fixed pos impl.
# [12:00] <Bert> fantasai: Maybe related after all.
# [12:00] <hober> s/Russel yesterday sent diff/I sent a css3-positioning diff to Rossen yesterday/
# [12:00] <Bert> dbaron: You need to know the height of the header.
# [12:01] <Bert> ChrisLilley: But 'em' may be be different depending on header, so 2em not always the same.
# [12:01] <Bert> dbaron: People do sticky in JS a lot.
# [12:01] <fantasai> fantasai^: gives example of 3-level stacked sticky headers
# [12:02] <fantasai> dbaron: Don't do multi-level sticky so much
# [12:02] <Bert> (JS emulations make jumpy heeaders)
# [12:03] <Bert> hober: CSS define when a scrolling box happens, and I expect to see Overflow or Box. Sticky refers to nearest ancestor.
# [12:03] <Bert> ... Even if not scrolling mechanism.
# [12:03] <Bert> ... Closest content defined somewhere, bit not the right thing.
# [12:03] <Bert> ... Should be definition of a scrolling box.
# [12:03] <michou> s/CSS define/CSS should define
# [12:03] <Bert> liam: Some UAs have that behaviour for table headers, right?
# [12:04] <Bert> hober: Tbale headers a bit different.
# [12:04] <Bert> ... But can apply sticky to table rows, obviously.
# [12:04] <leaverou> s/Tbale/Table/
# [12:05] <Bert> ChrisLilley: Is the link from dbaron the same text as hober referred to?
# [12:05] <Bert> dbaron: no different.
# [12:05] <Bert> Rossen_: I will work on it.
# [12:05] <Bert> ChrisLilley: So this is notes rather than spec text?
# [12:06] <Bert> dbaron: Not as formal as spec text, but good attempt by college student with no prior experience.
# [12:06] <Bert> ACTION: Rossen to get text about sticky into Position spec.
# [12:06] * trackbot is creating a new ACTION.
# [12:06] * RRSAgent records action 1
# [12:06] <trackbot> Created ACTION-579 - Get text about sticky into position spec. [on Rossen Atanassov - due 2013-09-19].
# [12:07] <Bert> dbaron: Cory's last day as intern is tomorrow...
# [12:07] <Bert> RESOLVED: Add Rossen as editor to Position module.
# [12:08] <dbaron> s/Cory/Corey/
# [12:08] <dbaron> and the thread on sticky from July started with http://www.w3.org/mid/51E030E2.4020608@mozilla.com
# [12:08] <Bert> (Agenda discussion, but nothing can be done in 10 minutes, it seems.)
# [12:09] <Bert> Topic: text-combine naming
# [12:09] <Bert> fantasai: The name isnot super-obvious
# [12:09] <dbaron> fantasai: text-combine-horizontal doesn't seem like a very obvious name
# [12:10] <Bert> ... glyph-orientation-horizontal applis only in hor., but text-combine only applis in vertical.
# [12:10] <Bert> SteveZ: 'horizontal-in-vertical' is theobvious name.
# [12:11] <Bert> Rossen_: mumble mmble
# [12:11] <Bert> ... One of the proposed names in Tucson
# [12:11] <Bert> ... but was way too generic
# [12:11] <Bert> ... Only applies to tatechuyoko
# [12:12] <dbaron> fantasai: text-combine-upright?
# [12:12] <Bert> ... We also expored 'tatechuyoko'
# [12:12] <Bert> fantasai: with "upright"? John said we should clrify that the text was upright.
# [12:13] <Bert> fantasai: EPUB uses 'text-combine'
# [12:14] <Bert> ChrisLilley: How about ??
# [12:14] <Bert> fantasai: It's not about a specif number of characters
# [12:14] <Bert> Rossen_: 'all' could be any number.
# [12:14] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [12:14] * Joins: shans__ (~shans_@public.cloak)
# [12:14] <Bert> SteveZ: digits and all do two different things.
# [12:15] <Bert> ChrisLilley: ASCII digits only it says?
# [12:15] <Bert> fantasai: There was discssion with John about fullwidth feature in Fonts.
# [12:16] <Bert> [Lunch]
# [12:18] * Quits: jet (~junglecode@public.cloak) (jet)
# [12:19] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [12:23] * Joins: jet (~junglecode@public.cloak)
# [12:24] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [12:34] * Quits: astearns_ (~astearns@public.cloak) (Client closed connection)
# [12:34] * Joins: astearns (~astearns@public.cloak)
# [12:38] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [12:38] * Joins: astearns (~astearns@public.cloak)
# [12:40] * Quits: jet (~junglecode@public.cloak) (jet)
# [12:49] * Joins: darobin (rberjon@public.cloak)
# [12:53] * Quits: glazou (~glazou@public.cloak) (glazou)
# [12:59] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [13:06] <fantasai> TabAtkins, I'm getting fatal errors when trying to regen writing modes. It's kindof a blocker?
# [13:08] * Quits: tantek (~tantek@public.cloak) (tantek)
# [13:09] * dbaron think's fantasai's regular expressions shirt would have gone along well with SimonSapin's science shirt
# [13:09] <dbaron> er, thinks
# [13:09] * dbaron is sometimes thinking a word ahead of his typing
# [13:10] <SimonSapin> dbaron, is this the one? http://store.xkcd.com/products/i-know-regular-expressions
# [13:10] <fantasai> yes
# [13:12] * Joins: glazou (~glazou@public.cloak)
# [13:15] * Joins: shans__ (~shans_@public.cloak)
# [13:20] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
# [13:23] * Joins: curvedmark (~curvedmark@public.cloak)
# [13:26] <ChrisLilley> http://w3cmemes.tumblr.com/post/61012799999/berts-having-a-bit-of-trouble-scribing-rossen
# [13:26] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [13:29] * Joins: shans___ (~shans_@public.cloak)
# [13:33] * Joins: leif (~lastorset@public.cloak)
# [13:34] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [13:35] <TabAtkins> ScribeNick: TabAtkins
# [13:35] <TabAtkins> Topic: GCPM
# [13:35] <TabAtkins> howcome: Yesterday's Napoleon rule still applies today.
# [13:35] <TabAtkins> howcome: We have a WD from 2011.
# [13:36] <TabAtkins> howcome: It shoudl probably be updated.
# [13:36] <TabAtkins> howcome: Lots of thigns have happend to the ED.
# [13:36] <TabAtkins> howcome: Main focus was to document and track impls.
# [13:36] <TabAtkins> howcome: This is a chart that lists the features/main sections in the draft, then the implementations, tests, and example rendering.
# [13:37] <projector> http://people.opera.com/howcome/2013/tests/css-gcpm/coverage.html
# [13:37] <TabAtkins> howcome: Two main impls are AH and Prince.
# [13:37] <TabAtkins> howcome: They're in the process of changing the way books are published.
# [13:38] <TabAtkins> howcome: 2 of the 4 top new york times bestsellers are published with Prince, and Lea is writing a book now in Prince.
# [13:38] <TabAtkins> howcome: It's possible to write a book in those formatters today, but it's hard.
# [13:38] <leaverou> s/Lea is writing a book now in Prince./Lea is writing a book now in AntennaHouse./
# [13:39] <TabAtkins> howcome: A lot of work went in to make sure the two do things the same way.
# [13:39] <TabAtkins> howcome: The differences between them has been the main focus of gcpm edits.
# [13:40] <TabAtkins> howcome: So this spec is a little different from other specs.
# [13:40] <TabAtkins> howcome: Applying the normal rules to this spec could lead it to being kicked out of the gruop, which I hope doesn't happen.
# [13:40] <TabAtkins> ChrisLilley: Do you expect the unarchived discussion to continue, or transition to a more public forum?
# [13:40] <TabAtkins> howcome: There's some healthy discussion on www-style now.
# [13:40] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [13:41] * Joins: ChrisLilley (clilley@public.cloak)
# [13:41] <TabAtkins> howcome: But my communication with the vendors is private email.
# [13:41] <TabAtkins> howcome: I have no problem publishing that, but it seems like I get better responses when I talk to them privately.
# [13:41] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [13:41] <TabAtkins> howcome: Documentation is usually sparse, but asking them tends to work.
# [13:41] <TabAtkins> ChrisLilley: Do they consider the info private?
# [13:41] <TabAtkins> howcome: Not to my understanding.
# [13:42] <TabAtkins> ChrisLilley: Proper WG discussion happens in an archived forum. How can we encourage this, so people other than those impls can contribute their pov?
# [13:43] <TabAtkins> plinss: I'm concerned about patent policy when technical info is coming from outside the consortium.
# [13:43] <dbaron> peterl: They're also not members of the WG and thus not under the patent policy.
# [13:44] <ChrisLilley> where do these external panent grants go?
# [13:44] <TabAtkins> howcome: I believe Prince has signed *something*, which might be a patent policy thing.
# [13:44] <ChrisLilley> s/panent/patent/
# [13:45] <TabAtkins> glazou: The fact that Hakon serves as a proxy for AH and Prince slows down the comm. process. We don't have direct access to the implementors, and can't discuss given technical points.
# [13:46] <TabAtkins> liam: We had AH in the xsl-fo group, but their implementors were japanese and didn't speak or write English (or at least not well), so we rarely ever got feedback from them.
# [13:46] <TabAtkins> liam: When we closed the group, we found out they'd implemented most of the draft.
# [13:46] * Joins: darobin (rberjon@public.cloak)
# [13:46] <TabAtkins> liam: So while I'd like to have a venue for them to participate, I recognize that in the past this has been a practical difficulty for them.
# [13:47] * Joins: kawabata (~kawabata@public.cloak)
# [13:47] <TabAtkins> howcome: And they have a fantastic impl. I think documenting and getting it out will make the world a better place.
# [13:47] <TabAtkins> howcome: If you go back to the table, the msot complex part of the spec is page flaots.
# [13:47] <TabAtkins> howcome: And the bottom of the table is page floats.
# [13:48] <TabAtkins> howcome: I'd say the focus in this should be to make these impls converge.
# [13:48] <TabAtkins> howcome: I'd like to have a good forum for that.
# [13:48] <TabAtkins> howcome: So my goal is to get another WD out.
# [13:48] <TabAtkins> TabAtkins: Never say no to a WD.
# [13:49] <TabAtkins> fantasai: I think one of the problems is that the discussion isn't archived.
# [13:49] <TabAtkins> fantasai: So somebody else coming up with the same discussion can't see it.
# [13:49] <TabAtkins> fantasai: Maybe www-style is intimidating, too high traffic. Would it help to have a separate list just for this?
# [13:49] * Joins: Rossen_ (~Rossen@public.cloak)
# [13:50] <TabAtkins> howcome: Maybe.
# [13:50] <Rossen_> steve, israel and I are stuck downstairs again :/
# [13:51] <TabAtkins> krit: If AH and Prince could give public feedback for this implementation table, that would be great.
# [13:51] <TabAtkins> glazou: We've always had trouble with communication based on language.
# [13:51] <TabAtkins> glazou: It's not going to change easily.
# [13:51] <TabAtkins> glazou: Problem is documenting features that you have little input on.
# [13:51] * Quits: Rossen_ (~Rossen@public.cloak) ("Page closed")
# [13:52] <TabAtkins> glazou: If I take some sections of GCPM, like page floats, misses a lot of layout details. Some examples, but not enough detail.
# [13:52] <TabAtkins> glazou: How does it interacct with other layout features, etc. Too light as a spec.
# [13:52] <TabAtkins> howcome: I don't disagree. Part of the reason is that we dont' know what those rules should be.
# [13:52] <TabAtkins> howcome: And I've had experience that the rules aren't actually followed.
# [13:53] <TabAtkins> howcome: AH/Prince implement based on customer requests, and then try to align it with the spec, but it's not really their first concern.
# [13:53] <TabAtkins> plinss: But the spec isn't really describing what impls are doing.
# [13:53] <TabAtkins> plinss: "Put it at the top of a column", for example, still doesn't let me know what it's doing.
# [13:53] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
# [13:54] * Joins: darobin (rberjon@public.cloak)
# [13:54] * Joins: israelh (~israelh@public.cloak)
# [13:54] <TabAtkins> liam: AH had a poster at the balisage conference, listing approx 200 custom CSS properties they've added.
# [13:54] <TabAtkins> liam: That's like 50% more, quite a bit.
# [13:54] <TabAtkins> liam: Some are rather ad-hoc, because they came direct from a customer request. Proper design would probably end up with fewer.
# [13:55] <Bert> -> http://antennahouse.com/CSSInfo/property.html AH property list
# [13:55] <TabAtkins> liam: Second, we have now at W3C a publishing interest group, where a number of major publishers have come to discuss their requirements.
# [13:55] * Joins: Rossen_ (~Rossen@public.cloak)
# [13:55] <TabAtkins> liam: Their problem si that the CSSWG is too technical for most of them, but it might be that that's a good place to take some of this work, and discuss with them how it meets their reqs.
# [13:55] <TabAtkins> liam: I wonder if that might be a more productive way forward.
# [13:56] <TabAtkins> liam: Work with those people, and then come back to CSS having established something with both publishers and implementors.
# [13:56] <TabAtkins> howcome: I can't say there's anything wrong with your proposal.
# [13:56] * Joins: jdaggett (~jdaggett@public.cloak)
# [13:56] <TabAtkins> howcome: I'm just worried about giving people false expectations here. Listen to them, put it in the spec, and then nothing happens.
# [13:56] <TabAtkins> ChrisLilley: Precedent - the JLTF reviewed stuff, produced a req document, but then the relevant groups did nothing with that document.
# [13:57] * Joins: jet (~junglecode@public.cloak)
# [13:57] * Joins: SteveZ (~SteveZ@public.cloak)
# [13:57] <TabAtkins> glazou: O'Reilly isn't going to just change their engine if we come up with a compromise that is different form their impl.
# [13:57] * Joins: koji (~koji@public.cloak)
# [13:57] <TabAtkins> glazou: This is a big issue - you're forced to spec what they've done even if it's suboptimal.
# [13:57] <ChrisLilley> s/did nothing with/decided how to implement thos requirements based on/
# [13:57] <TabAtkins> glazou: Even if we have a much better idea how to integrate it with CSS.
# [13:58] <TabAtkins> glazou: So standardizing what the impls do is okay when what they do is good.
# [13:58] <TabAtkins> glazou: I've carefully looked at Prince/AH additions, and some are really hacky.
# [13:59] <TabAtkins> Rossen_: So is the point of documenting this just to validate their properties, or is it to try and work with us to come up with a solution, even if things change?
# [13:59] <TabAtkins> howcome: I think it's something between there.
# [13:59] <TabAtkins> howcome: But they're going outside of where CSS has gone before, and coming up with solutions that I think fit within the CSS space.
# [13:59] <TabAtkins> howcome: AH and Prince are different, but not *that* different. We can gently move to a common foundation.
# [14:00] <TabAtkins> plinss: I think the win comes when we get these features in CSS that everyone implements in browsers, etc.
# [14:00] <TabAtkins> plinss: If all we're doing is documenting how they've shoehorned something into their impl, that won't help the web at large.
# [14:00] <TabAtkins> howcome: Absolutely. And speaking as a browser vendor, I'm interested in this too.
# [14:01] <TabAtkins> howcome: The things that haven't been implemented with AH/Prince (blank spaces in the table) came out of discussion with Opera and Blink.
# [14:01] <TabAtkins> plinss: I'm not sure there shoudl be an exercise in trackign impls, but rather in designing these features.
# [14:02] <TabAtkins> plinss: These features aren't being designed as part of the platform. The fact that you have two implementations in Opera isn't enough, because I htink you said it's the same person.
# [14:02] <TabAtkins> plinss: What we're missing here is specification prose that allows different people to read the spec and come up with impls that are compatible.
# [14:03] <TabAtkins> plinss: If we can't get that, these shouldnt' be in the spec as features, but just as ideas of things that we might like.
# [14:03] <liam> +1
# [14:03] <TabAtkins> astearns: And the point of doing this in the group is to get other implementors interested, so one day O'Reilly doesn't have to be stuck with AH, they can get their books rendering in browsers, or any other place.
# [14:04] <TabAtkins> ChrisLilley: That was one of the failures of XSL-FO - every feature was optional, so it was very hard to get interoperable.
# [14:04] <liam> [not every feature, of course]
# [14:04] <TabAtkins> howcome: But until browsers do real paged projections, there's no reason for browsers to read this.
# [14:05] <ChrisLilley> my point was that many stylesheets were aimed at, and only usable on, a single processor
# [14:05] <TabAtkins> glazou: Not true. Some things, like string-set, are useful regardless of printing, and can happen at any time.
# [14:05] <TabAtkins> plinss: In Hamburg a year ago, we had every browser around the table to agree to make printing a priority.
# [14:05] * Joins: plh (plehegar@public.cloak)
# [14:05] <liam> [agree with the point, yes]
# [14:05] <TabAtkins> plinss: I think having some of this discussion not taking place in this group is part ofthe problem.
# [14:06] <TabAtkins> howcome: The resource constraint is implementors.
# [14:06] <TabAtkins> plinss: And you have companies like Adobe here, which work in multiple engines.
# [14:06] <TabAtkins> astearns: We haven't seen the right solutions yet.
# [14:06] <TabAtkins> howcome: I disagree - this spec has enough detail.
# [14:06] <TabAtkins> glazou: I disagree.
# [14:07] <TabAtkins> glazou: I read the spec in deep details. A name of a value and a one-line description doesn't give you info about the feature.
# [14:08] <TabAtkins> krit: You were concerned about the platform in general.
# [14:08] <TabAtkins> krit: Our WG in particular is about the we bplatform.
# [14:08] <TabAtkins> krit: The book people may be interested in some of the web platform, but extending to fill all of their needs may not be necessary for the web.
# [14:08] <TabAtkins> krit: Our WG is quite sensitive about defining properties not defined in the CSSWG.
# [14:08] <TabAtkins> krit: So what do we do?
# [14:09] <TabAtkins> glazou: So, two options. These people are extending CSS. These people can use vendor prefixes, and claim you are "CSS-like" forever. We can't do anything. Or two, do what Hakon does, and try to build something standardized and get everyone to implement.
# [14:09] <TabAtkins> glazou: And if it's in this WG, it has to obey the rules of spec production.
# [14:09] <TabAtkins> glazou: And that's an issue - we can't discuss with them. Thus, the feature descriptions are extremely light.
# [14:10] <TabAtkins> glazou: I agree that some of these features *work*. I think I would have designed things different myself, but this is the start of a compromise that never happened.
# [14:10] <TabAtkins> glenn: I think Dirk's point was a good one - where does work occur on future specs that this group doesn't focus on?
# [14:11] <TabAtkins> glenn: Maybe for a long time this group has been focused on the web platform, but there are other applications where the web is not where they live.
# [14:11] <TabAtkins> glenn: I don't think we should make a decision today that this isn't appropriate to work on.
# [14:11] <TabAtkins> glazou: It's not just about the web. epub has been interacting for a long time.
# [14:11] <TabAtkins> glazou: And ebooks are not the web platform. Still very static.
# [14:11] <TabAtkins> glazou: Very specific requirements that differ from the browser world.
# [14:12] <TabAtkins> glazou: HTML is used on TV, will be used on cameras, etc. everywhere.
# [14:12] <TabAtkins> plinss: "web platform" doesn't necessary mean "what you see in the browser".
# [14:12] <TabAtkins> ChrisLilley: You could shrink down the "web platform", or you could extend it out.
# [14:12] <TabAtkins> ChrisLilley: Advantages to both.
# [14:13] <TabAtkins> szilles: It seems the problem si not the size or th escope, but getting eyes on the doc that are interested.
# [14:13] <TabAtkins> szilles: Part of what I'm hearing is that hakon putting it in the spec doesn't generate views and doesn't generate impls.
# [14:13] <TabAtkins> szilles: This is the hardest part. It's easy to get a proposal, it's hard to get people to look at it.
# [14:13] <TabAtkins> szilles: In part, the lack of participation by AH/Prince is making that process more difficult in this case.
# [14:14] <TabAtkins> szilles: That's not a comment on the validity of it, just that you need to market and sell something to get the uptake.
# [14:14] <TabAtkins> howcome: I've been trying - I've been putting substantial efforts into this.
# [14:14] <TabAtkins> howcome: The participation problem is that in a couple cases, the WG has decided to remove functionality that is essential for those implementors.
# [14:15] <TabAtkins> glazou: This WG works on consensus - we agreed to remove two things, and you didn't comply.
# [14:15] <TabAtkins> glazou: For example, Regions and Exclusions we're chartered to work on in two docs. Anything about those should be in those documents, not in GCPM.
# [14:15] <TabAtkins> howcome: They're there because I think the current specs lack some functionality.
# [14:16] <TabAtkins> plinss: You're saying this is a scratch space, but you're also asking to publish as a WD.
# [14:16] <TabAtkins> plinss: Scratch space is one thing, publishing a WD is saying it's the work of the CSSWG.
# [14:16] <TabAtkins> howcome: I'm happy to move those sections somewhere else - a note, for example.
# [14:16] <TabAtkins> ChrisLilley: I noticed that those sections dont' figure in the impl table.
# [14:17] <TabAtkins> ChrisLilley: I assumed that meant you wanted to publish only the things in the table.
# [14:17] <TabAtkins> ChrisLilley: And meant to remove the other things.
# [14:17] * sgalineau is considering taking pictures of all the nuances of WTF expressed by jdaggett's face
# [14:17] <TabAtkins> howcome: No, they're lacking just because they don't have implementations.
# [14:17] <TabAtkins> dbaron: I disagree strongly with what daniel said.
# [14:17] <TabAtkins> dbaron: About regions/exclusions being chartered, and so all related work is in those documents.
# [14:18] <TabAtkins> dbaron: Particularly since there have been many objections, and the actions of the editors has been to repeatedly ask to remove the issues without addressing the udnerlying issue.
# [14:18] <TabAtkins> dbaron: And second, I want to *agree* with what daniel said.
# [14:18] <TabAtkins> dbaron: We should be able to have multiple proposals for a tech.
# [14:18] <TabAtkins> dbaron: To respond to hakon, the comment of "oh, this is just an ED" is part of what prevents this spec from advancing.
# [14:19] <TabAtkins> dbaron: You keep adding to it and changing what is in it, such that we don't really know what it is, or what any plan for it in the future would mean.
# [14:19] <TabAtkins> glazou: I said both that we were chartered, and decided to remove the two sections from gcpm.
# [14:19] <ChrisLilley> that would be helpful, to see exactly what you plan to publish
# [14:19] <TabAtkins> dbaron: I dont' remember this, and probably would have objected.
# [14:20] <TabAtkins> glazou: You've made a lot of edits in the last year to the draft, hakon, that we haven't seen.
# [14:20] <TabAtkins> glazou: You've posted only a few small details, almost too late to comment on.
# [14:20] <TabAtkins> glazou: I think the ED is a living spec for whatever AH and Prince are doing, and that's not the standardization process is for.
# [14:20] <TabAtkins> howcome: If you don't care, you should kick it out.
# [14:21] <TabAtkins> plinss: It's not that we dont' care. It's that they're not trying to make this tech part of the open web platform.
# [14:21] <TabAtkins> ChrisLilley: You said you had a presentation about what you want to publish?
# [14:21] <TabAtkins> ChrisLilley: I think that might help.
# [14:21] <TabAtkins> dbaron: IN repsonse to Peter, I think the level of precision and detail needed to move forward with features like this in browsers, is much higher than what's in the spec.
# [14:22] <TabAtkins> dbaron: I think there's a relation to that and the lack of interop between Prince and AH.
# [14:22] <TabAtkins> dbaron: I think that one of the steps to actually getting this implemented is (1) there's a bunch of existing paged media stuff we haven't implemente dyet, and some of it's actually pretty hard and not well-specified.
# [14:23] <TabAtkins> dbaron: To build more features on top of that... the bigger the pile of features is, the scarier it looks, especially when those features aren't very clearly defined and explained in terms of how they work and interact with other features.
# [14:23] <TabAtkins> dbaron: One of the things that's often lacking in this spec is a description of an underlying model that makes it clear, not just how the feature works in simple cases, but how it works in interaction with everything else.
# [14:23] <TabAtkins> ChrisLilley: Relevant to the web paltform, I think Paged Media has been more about things that aren't document-like.
# [14:24] <TabAtkins> ChrisLilley: So naturally, Paged Media seems more appropriate - it if was sold properly, about there being lnots of useful things where "paged" presentation was an ideal fit, I think it would be better.
# [14:24] <TabAtkins> howcome: I wish I could agree, but even simple things like page numbering haven't been taken up.
# [14:25] <ChrisLilley> s/like/like, such as webapps
# [14:25] <TabAtkins> glazou: What david said about models, though - for example, the 16 margin boxes are complicated, and go against the print options exposed by browsers. So we have a lot of things to expose.
# [14:25] <TabAtkins> s/expose/talk about/
# [14:26] <TabAtkins> howcome: The problem is getting layout people to actually work on it. Of course the spec shoudl always be better, but I don't think that's the stopping point.
# [14:26] <TabAtkins> howcome: Simon, what's your understanding? Is the lack of specificity the problem?
# [14:26] <TabAtkins> SimonSapin: I think in the last few years, there were a lot of problems that were basically impossible to implement, like the layout of margin boxes. fantasai and I worked to fix that, so I think it's better now.
# [14:27] <TabAtkins> glazou: Even though the model requires some deep changes, it's not really juste the single feature, but how it works with everything else in CSS.
# [14:27] <TabAtkins> glazou: page-float: bottom? What if I put something else inside - another flow, or a grid?
# [14:28] <TabAtkins> howcome: You could argue that since float:bottom has been there for 10 years, it's Grid that should have specified things.
# [14:28] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [14:28] * Joins: ChrisLilley (clilley@public.cloak)
# [14:29] <TabAtkins> howcome: I don't think it's the quality of the spec that's stopping this, it was the implementor interest, or else they'd have done simple things like page numbers.
# [14:29] <TabAtkins> howcome: A lot of the spec has been pruned.
# [14:29] <TabAtkins> howcome: Useful things we liked, like aligning leaders, have been removed for lack of impl.
# [14:30] <TabAtkins> howcome: The regions and exclusions stuff has been put at the end. I want to move them, but not remove them - I think they're useful to provide alternate ideas for how to implement them.
# [14:30] <TabAtkins> glazou: To move the document along the rec track...
# [14:30] <SimonSapin> in my "it's better now" earlier, "it" is css-page, not GCPM
# [14:30] <TabAtkins> glazou: This document has been on the table so long, everyone who would like to see it published asap is gone.
# [14:31] <TabAtkins> glazou: You'll have to do some major cleanup - put things into another level if you want.
# [14:31] <TabAtkins> glazou: I listed a few actions.
# [14:31] <TabAtkins> glazou: 1) if a property isn't already interoperable for two impls, remove from this version.
# [14:31] <TabAtkins> glazou: 2) a property that is implemented by two, but not interoperably, retain but mark at-risk.
# [14:31] <TabAtkins> glazou: 3) sections that conflict with other specs, remove and put elsewhere.
# [14:31] <TabAtkins> glazou: Like color module for cmyk().
# [14:32] <TabAtkins> glazou: 4) test suite has to be started.
# [14:32] <TabAtkins> glazou: If you want this to progress, it nees to progress with Rec in mind in the next 6 months.
# [14:32] <dbaron> s/cmyk/device-cmyk/
# [14:32] <TabAtkins> plinss: With regards to the testsuite, this isn't something yet that I can bring up in a transition request.
# [14:32] <TabAtkins> plinss: You're only asking for WD now, but you have to keep in mind what will be needed in the future.
# [14:33] <TabAtkins> plinss: Are the tests in our format, in our repo?
# [14:33] <TabAtkins> howcome: No. But these tests are useful for me.
# [14:33] <TabAtkins> plinss: Right there, you're describing the disconnect. You ahve tests useful to you, we need tests useful for the WG.
# [14:34] <TabAtkins> plinss: If this is going to continue being published by the WG, it needs to be a product of the WG, working together with the WG.
# [14:34] <TabAtkins> plinss: Is it a fair requirement to make this document in accordance with the WG's policies?
# [14:34] <TabAtkins> plinss: You're currently producing this document in isolation by yourself.
# [14:34] <TabAtkins> howcome: No, I'm doing it in greater concert with implementors than ever before.
# [14:35] <TabAtkins> plinss: You're not doing it with concert with anyone in this WG.
# [14:35] <TabAtkins> howcome: And if Daniel says that anything needs two impls to get in a WD...
# [14:35] <TabAtkins> glazou: Not for general specs. This is a special case. This spec has been around for *so long*.
# [14:35] <TabAtkins> glazou: I want these features in a Rec as soon as possible. I'm not the only one.
# [14:36] <TabAtkins> glazou: To reach Rec asap, we have to take what can be a Rec now, and the rest can wait.
# [14:36] <TabAtkins> Bert: I think we've heard a number fo speculations about why this hasn't been dsicussed, but I don't think we need to talk about that.
# [14:36] <TabAtkins> Bert: How *can* we get this discussed?
# [14:37] <TabAtkins> glazou: Have Hakon more on our calls. Last time was like a year ago.
# [14:37] <TabAtkins> glazou: When you're on the conf call, you can request things.
# [14:37] <TabAtkins> Bert: It's not on the agenda.
# [14:37] <TabAtkins> plinss: First thing Daniel has always said, after getting a scribe, is to ask for additional agenda items.
# [14:38] <TabAtkins> plinss: Hamburg you definitely got time. I remember a previous meeting where you asked for time and didn't get it.
# [14:38] <TabAtkins> ChrisLilley: I heard comments about the test format. Hakon said he has tests, and is willing to put them in whatever format we want. I don't think that got minuted. I think that's a good point.
# [14:38] <TabAtkins> howcome: Absolutely.
# [14:39] <TabAtkins> [let's do the timewarp again]
# [14:40] <TabAtkins> fantasai: So what's the plan here?
# [14:40] <TabAtkins> howcome: I plan to try and publish a WD, and continue to get interest.
# [14:40] <TabAtkins> fantasai: Can we get those plans minuted?
# [14:41] <TabAtkins> szilles: Exclusions offers an example of how to go faster and further - it was thought to be too broad at first. In several successive revisions, it's been cut down to the point where people *do* agree on the scope, and people are now working on implementations now that it's at a reasonable size.
# [14:41] <TabAtkins> szilles: So I suggest that th efastest way to get this implemented is to cut it down, get it implemented, and then move on from there.
# [14:41] <TabAtkins> szilles: Paper-pile phenomenon.
# [14:42] <TabAtkins> szilles: So I suggest cutting out everything you dont' need *immediately*. And probably rename what's left to get out of the gcpm hole.
# [14:42] <TabAtkins> SimonSapin: Have you heard interest from AH and Prince to converge?
# [14:42] <dbaron> SimonSapin: You said you wanted Prince and AH to converge. Have you heard interest from them in converging?
# [14:42] <TabAtkins> howcome: mumble mumble
# [14:43] <TabAtkins> SimonSapin: I implemented css 2.1 floats in weazyprint. It was *hard*. But because the spec has enough detail, I coudl do it based on the spec.
# [14:44] <TabAtkins> SimonSapin: Based on what I read in gcpm, the examples show what it does, but I have no idea how to implement it.
# [14:44] <TabAtkins> howcome: You're probably right. The two impls didn't go to the spec first.
# [14:44] <TabAtkins> howcome: Now I have to reverse-engineer.
# [14:44] <TabAtkins> glazou: If you agree, I can come up with a list of sections in your document that could go to rec in 6 months time.
# [14:45] <TabAtkins> glazou: So that tomorrow it can be a WD, a CR in 3 month, a Rec in 6.
# [14:45] <SimonSapin> SimonSapin: IMO the whole purpose of a spec is to allow new implementations based on it
# [14:45] <TabAtkins> glazou: And I think that's much better than arguing about process or whatever.
# [14:46] <TabAtkins> glazou: That way you'll have a minimal set of features standardized by this WG, under our process, that you can show to your vendors that can make them converge.
# [14:46] <TabAtkins> glazou: If you don't do that, I'm afraid we'll enter a WD/ED loop for 5 years.
# [14:46] <TabAtkins> Bert: How to get it discussed?
# [14:46] <TabAtkins> glazou: Be on the conf call.
# [14:46] <TabAtkins> howcome: I can't do that - the time is alway sbad.
# [14:47] <TabAtkins> plinss: Just request it. We're always willing to discuss,especially if someone else is willing to champion.
# [14:47] <TabAtkins> howcome: [discusses some sections that can be removed]
# [14:47] <TabAtkins> glazou: From my perspective, the only sections that are reasonable specified is 1,2,3, and maybe 4. Starting with 5, you have a one-liner of prose, and the rest is examples.
# [14:48] <TabAtkins> fantasai: I think 6 is straightforward too.
# [14:48] <TabAtkins> plinss: Pause. I think you're seeing this as a confrontation between you and the WG.
# [14:48] <TabAtkins> plinss: Please understand everyone at this table wants these features to advance. We're not trying to block. We're trying to get it *done*.
# [14:49] <TabAtkins> plinss: We're asking you to work with us to do it.
# [14:49] <TabAtkins> astearns: IN particular, speaking as the editor of Regions, I'd like to see your version advance as well as mine.
# [14:49] <TabAtkins> fantasai: The sections that Daniel calls out are the only ones that are actually generated content.
# [14:50] <TabAtkins> howcome: I think the overhead of going to Rec is significant. Splitting things up would make it too annoying to work with.
# [14:50] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [14:50] * Joins: ChrisLilley (clilley@public.cloak)
# [14:50] <glazou> jdaggett, sorry, important discussion that needed to happen
# [14:51] <jdaggett> no worries
# [14:51] <TabAtkins> plinss: I'm sure that if this got broken up into smaller pieces, each piece could go to Rec in a year each.
# [14:51] <TabAtkins> howcome: I don't think I agree, or have the motivation to do that.
# [14:52] <dbaron> glazou: We never had a say in what these vendors implemented.
# [14:52] <TabAtkins> glazou: Vendors for the last 10 years have gone off and done things on their own, and not asked us.
# [14:53] <TabAtkins> Bert: I don't agree. They've asked. They may not like working in our mode, but they still asked.
# [14:55] <dbaron> Tab: The overhead for publishing rec's isn't great, but it's not that bad.
# [14:55] <dbaron> Tab: It's mainly ... .
# [14:55] <TabAtkins> glazou: Please list the sections you want to include.
# [14:55] <dbaron> (I actually disagree with tab, I think the delays in the publication process are *major* overhead because they require splitting tasks up by months when they're best done together.)
# [14:56] <TabAtkins> howcome: Everything from section 1 to 13.
# [14:56] * Joins: tantek (~tpod@public.cloak)
# [14:56] <TabAtkins> howcome: I feel it would be a betrayal of the implementors to do anything less.
# [14:56] <dbaron> ChrisL: I think 14 could go in selectors4.
# [14:58] <TabAtkins> liam: I think section 15 is just an idea, not a spec, even though I included it.
# [14:58] <TabAtkins> howcome: So now 1-15.
# [14:59] <TabAtkins> jet: Abstain
# [14:59] <TabAtkins> howcome: yes
# [14:59] <TabAtkins> Bert: yes
# [14:59] <TabAtkins> koji: abstain
# [14:59] <TabAtkins> leaverou: I want many of these features, but I also see how many of them are underspecified.
# [15:00] <TabAtkins> leaverou: I want more time.
# [15:00] <TabAtkins> glazou: No more time.
# [15:00] <TabAtkins> leaverou: Abstrain
# [15:00] <TabAtkins> jdaggett: Abstain
# [15:00] <TabAtkins> dbaron: I think no, but not sure.
# [15:00] <TabAtkins> Rossen_: No
# [15:00] <TabAtkins> krijnh: no
# [15:00] <TabAtkins> michou: abstain
# [15:00] <TabAtkins> israelh: abst
# [15:00] <TabAtkins> leif: no, but a smaller set I could say yes to
# [15:01] <TabAtkins> shane: no
# [15:01] <TabAtkins> TabAtkins: All options at once.
# [15:01] <TabAtkins> liam: Yes
# [15:01] <dbaron> Tab: Can't make a decision now because I'm minuting and can't look at the document.
# [15:02] <TabAtkins> kawabata: abstai
# [15:02] <TabAtkins> yamamoto: abstain
# [15:02] <TabAtkins> glenn: yes
# [15:02] <TabAtkins> fantasai: defer to dbaron
# [15:02] <TabAtkins> SimonSapin: With 15, no.
# [15:02] <TabAtkins> ChrisLilley: Yes, if 8, 14, and 15 are marked as "this will move to another document".
# [15:03] <TabAtkins> glazou: That's a no.
# [15:03] <dbaron> zcorpan: no
# [15:03] <dbaron> er
# [15:03] <dbaron> zcorpan: yes
# [15:03] <TabAtkins> zcorpan: yes
# [15:03] <TabAtkins> astearns: yes
# [15:03] <TabAtkins> plinss: absta
# [15:03] <TabAtkins> glazou: no
# [15:03] <TabAtkins> szilles: abstain
# [15:04] <dbaron> howcome: I think what we're voting about is whether this work will continue in w3c or not.
# [15:04] <TabAtkins> fantasai: I think that 1,2,3 seem to be straightforward. problaby need a bit of tightening.
# [15:04] <TabAtkins> fantasai: 4 is a bit underspecified.
# [15:05] <TabAtkins> fantasai: 5 is *vastly* unspecified. And these two interact with lyout.
# [15:05] * sgalineau wants off the CSS Survivor island
# [15:05] <TabAtkins> fantasai: 6 should move to page dmedia.
# [15:05] <TabAtkins> fantasai: 7 seems okay
# [15:05] <TabAtkins> fantasai: 8 should move to color
# [15:05] <TabAtkins> fantasai: 9 is already in paged media (so remeoved from this spec)
# [15:05] <TabAtkins> fantasai: 10 is cool, but not generated content, and needs more specifying.
# [15:05] <TabAtkins> fantasai: 11, likewise.
# [15:05] <astearns> q+
# [15:05] * Zakim sees astearns on the speaker queue
# [15:05] <TabAtkins> fantasai: Those two I think are godo to explore, but not fleshed out.
# [15:06] <TabAtkins> fantasai: 12 needs more detail, but I really think it should be its own independentmodule. Floats level 5 or something.
# [15:06] * Joins: israelh_ (~israelh@public.cloak)
# [15:06] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:06] * Joins: ChrisLilley (clilley@public.cloak)
# [15:06] <TabAtkins> fantasai: 13, I'm not sure where they should go, but probably part in multicol. Needs to be worked out a bit more.
# [15:06] <TabAtkins> fantasai: 14 makes sense. I dont' know where it should go. Interacts well with overflow module. We don't currently have a pseudo-elements module to put it into.
# [15:06] <TabAtkins> fantasai: 15 is not a spec.
# [15:07] <TabAtkins> howcome: I agree with all of this. But I'm just looking for a Working Draft.
# [15:07] <TabAtkins> fantasai: What I'd like to say is that for the things that need to move to another spec, we can take actions to move them.
# [15:07] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:07] * Joins: ChrisLilley (clilley@public.cloak)
# [15:07] <TabAtkins> action tab to move device-cmyk() to colors 4.
# [15:07] * trackbot is creating a new ACTION.
# [15:07] <trackbot> Created ACTION-580 - Move device-cmyk() to colors 4. [on Tab Atkins Jr. - due 2013-09-19].
# [15:08] <TabAtkins> action fantasai to move page marks and bleed area to css3 page
# [15:08] * trackbot is creating a new ACTION.
# [15:08] <trackbot> Created ACTION-581 - Move page marks and bleed area to css3 page [on Elika Etemad - due 2013-09-19].
# [15:08] <dbaron> q+ SteveZ
# [15:08] * Zakim sees astearns, SteveZ on the speaker queue
# [15:08] <TabAtkins> fantasai: Can you split page floats into a separate module?
# [15:08] <liam> [note, the heartbeat requirement howcome mentioned is per WG, not per spec]
# [15:08] <TabAtkins> howcome: No, I don't think so right now.
# [15:09] <dbaron> Zakim, ack astearns
# [15:09] <Zakim> I see SteveZ on the speaker queue
# [15:09] <ChrisLilley> q?
# [15:09] * Zakim sees SteveZ on the speaker queue
# [15:09] <TabAtkins> astearns: I voted to have a WD because I think this is the right direction to go - paring it down to have a better chance of ipmlementing.
# [15:09] <TabAtkins> astearns: To get the feedback that fantasai just gave.
# [15:09] * Quits: israelh (~israelh@public.cloak) (Ping timeout: 180 seconds)
# [15:09] <TabAtkins> astearns: I've had experience dealing with multiple documents over a monolithic one, and I find it *much* easier to deal with, and to get comments on.
# [15:09] <TabAtkins> astearns: Rather than ahving people walk away because it's too much reading.
# [15:10] * Quits: tantek (~tpod@public.cloak) (Ping timeout: 180 seconds)
# [15:10] <dbaron> q+ glenn
# [15:10] * Zakim sees SteveZ, glenn on the speaker queue
# [15:10] <astearns> Q-
# [15:10] * Zakim sees SteveZ, glenn on the speaker queue
# [15:10] <dbaron> ack SteveZ
# [15:10] * Zakim sees glenn on the speaker queue
# [15:10] <TabAtkins> SteveZ: In some sense, Alan said what I wanted.
# [15:10] <dbaron> glazou: 9 no, 7 yes
# [15:10] <TabAtkins> SteveZ: I voted to give you a guiding function to actually do the decomposition.
# [15:11] <TabAtkins> SteveZ: My perception is that the WG has given you a lot of input to move more effectively, and you've said no.
# [15:11] <ChrisLilley> my no was only because my yes with 3 sections marked with editorial notes was not accepted
# [15:12] <dbaron> glazou: 10 no, 7 yes
# [15:12] <TabAtkins> howcome: If it's so important to move page floats to a separate spec, I'll do it.
# [15:12] <TabAtkins> TabAtkins: With page flaots moved, and the other moves that fantasai suggested, I"ll do a yes.
# [15:12] * Bert would actually prefer to merge several modules...
# [15:12] <TabAtkins> SteveZ: Normally we operate by getting the docs first, then agreeing to publish, rather than publishing based on promise to produce docs.
# [15:13] <TabAtkins> howcome: I don't want to spend time splitting without consensus to publish.
# [15:13] <TabAtkins> SteveZ: I think you've heard consensus on the first six sections.
# [15:14] <dbaron> Zakim, ack glenn
# [15:14] <Zakim> I see no one on the speaker queue
# [15:14] <TabAtkins> glenn: The negative consequence of not publishing is not getting the early chance to get a clal for exclusions.
# [15:14] <TabAtkins> fantasai: This has already been WD, so we've gotten that.
# [15:14] <TabAtkins> glenn: I think WDs have a low bar, and don't think we should hold things up to much.
# [15:15] <TabAtkins> ChrisLilley: I heard several nos turning to yes with minor changes, so I'd like to see if we can find a straw poll that we can agree on.
# [15:16] <TabAtkins> howcome: So let's move out section 6 and 8, move 12 to a separate draft, and delete 15.
# [15:19] * Quits: shans___ (~shans_@public.cloak) (Client closed connection)
# [15:19] * Joins: shans__ (~shans_@public.cloak)
# [15:20] <dbaron> I think 11 belongs with 10, actually.
# [15:21] <TabAtkins> tantek: If your goal is to advance as fast as possible, you need to ship as little as possible.
# [15:22] <TabAtkins> I strongly agree with dbaron
# [15:23] <astearns> proposal: publish sections 1-5, 7, 13 in a new working draft
# [15:25] * hober thinks dropping presto and continuing to cite it as an impl for the purposes of advancing features in the wg is the equivalent of having your cake and eating it too.
# [15:25] <TabAtkins> Given the joking expansion of GCPM to "Garbage Collection Placeholder Module", it seems this is the working group's own mark-and-sweep. /ht hober
# [15:26] <hober> TabAtkins: we need to implement an incremental collector; this stop-the-world-and-run-a-full-gc stuff is too inefficient
# [15:26] * astearns perhaps we should have a GCPM task force
# [15:26] <TabAtkins> We just need to increase memory sufficiently that we never run a GC.
# [15:27] <TabAtkins> I propose brain farms.
# [15:27] * liam would be ok with a page layout tf
# [15:27] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [15:27] <TabAtkins> [by the way, non-minuted horse-trading discussion about what to publish]
# [15:28] * liam thinks at the end of the horse you get... er n/m
# [15:29] * Bert has many references to gcpm and other modules that get and got split and the pointers don't or won't work anymore. :-(
# [15:29] <TabAtkins> Proposal:
# [15:29] <TabAtkins> 1-5, 7, and 13 publish as GCPM WD.
# [15:30] <SimonSapin> Bert, we can keep the anchors in GCPM with "This has moved to …"
# [15:30] <TabAtkins> RESOLVED: Publish sections 1-5, 7, and 13 of GCPM ED as a new WD.
# [15:31] <TabAtkins> Proposal:
# [15:31] <TabAtkins> 6 to CSS3 page
# [15:31] <dbaron> I think 14 should be in the pseudo-elements module instead.
# [15:31] <TabAtkins> 8 to CSS color
# [15:31] <TabAtkins> 9 to Page
# [15:31] <TabAtkins> 10, 11, 14 to Overflow.
# [15:31] <TabAtkins> 12 to Page Floats (new spec)
# [15:32] <TabAtkins> 14 to Overflow (for now, Pseudo-Elements when we write it)
# [15:32] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:32] <TabAtkins> 15 removed
# [15:32] * Joins: ChrisLilley (clilley@public.cloak)
# [15:32] <TabAtkins> 16 and 17 to Page Floats
# [15:33] <TabAtkins> RESOLVED: Accept the above publishing plan for distributing the rest of GCPM ED.
# [15:33] <dbaron>
# [15:33] <dbaron> jdaggett, how was the audio during that discussion?
# [15:34] <jdaggett> howcome was fine, i heard daniel when he was angry :P
# [15:34] <jdaggett> so pretty much i heard everything...
# [15:34] <jdaggett> :D
# [15:39] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [15:39] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [15:44] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [15:44] * dbaron assumes jdaggett can see himself on the screen as well
# [15:44] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:45] * Joins: ChrisLilley (clilley@public.cloak)
# [15:45] * Joins: astearns (~astearns@public.cloak)
# [15:45] <jdaggett> dbaron: am i making funny faces? tracking down a crasher...
# [15:45] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [15:45] * Joins: ChrisLilley (clilley@public.cloak)
# [15:45] <dbaron> jdaggett, not particularly
# [15:52] * Quits: astearns (~astearns@public.cloak) (Ping timeout: 180 seconds)
# [15:53] <TabAtkins> Agenda Request: Go through my Colors spec and get a definite yay/nay on all the features for moving to the ED.
# [15:58] <SimonSapin> TabAtkins, +1
# [16:00] <fantasai> TabAtkins: You'll have to add device-cmyk() to that list now ;0
# [16:03] * Joins: astearns (~astearns@public.cloak)
# [16:03] <SimonSapin> TabAtkins, wouldn’t that we the third time we’re doing this, though?
# [16:04] * astearns is watching jdaggett debug, imagining he's fixing the WG
# [16:05] <jdaggett> astearns: hey, i figured out how to reproduce a crasher without using windows, i'm a happy camper... ;)
# [16:05] <jdaggett> interesting listening to håkon talking about trolls...
# [16:05] <astearns> you still have to test your fix on Windows
# [16:06] <jdaggett> :P
# [16:06] <jdaggett> no need to test, i will work perfectly
# [16:06] <jdaggett> no bugs, no, no, no bugs...
# [16:06] * Joins: leif (~lastorset@public.cloak)
# [16:06] <TabAtkins> SimonSapin: Last time it was just a surprising "Yeah, let's publish". I know that dbaron had objections, but don't recall if he was even on the call.
# [16:07] <TabAtkins> I just want to make sure there's no landmines that'll show up in the future.
# [16:08] <sgalineau> we could split it into one doc for each color...
# [16:09] <dbaron> I don't want to publish 2^24 working drafts.
# [16:09] <fantasai> http://dev.w3.org/csswg/css-writing-modes/
# [16:09] <dbaron> Topic: CSS Writing Modes
# [16:10] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [16:10] <dbaron> fantasai: Issue from jdaggett about text-combine-horizontal taking digits only in the range 2-4 rather than 1-4
# [16:11] <dbaron> jdaggett: 'digits 1' value doesn't have much meaning
# [16:11] <dbaron> jdaggett: so it means single digits will be upright, but not what the property is about
# [16:11] <dbaron> Rossen: ...
# [16:11] <dbaron> fantasai: key point is that it's rendering it upright
# [16:12] <dbaron> SimonSapin: not very useful, but well defined and not really problematic
# [16:12] <dbaron> fantasai: rossen, implementation?
# [16:12] <dbaron> Rossen: Yes, And I believe I've seen content that depends on it.
# [16:12] <dbaron> Rossen: ... expecting automatic tate-chuu-yoku will hit because it's falling into that range.
# [16:13] * Joins: yamamoto (~yamamoto@public.cloak)
# [16:13] <fantasai> dbaron: Issue is that t-c-h says if you have
# [16:13] <fantasai> 1 0 2 年1月
# [16:14] <fantasai> you combine it into [102]年[1]月
# [16:14] <fantasai> or [102]年[11]月
# [16:14] <fantasai> dbaron: If you're saying combine at most 1 digit, you're not doing any combining.
# [16:15] <fantasai> SteveZ: Suppose I have Latin text, and I want digits upright
# [16:15] <fantasai> fantasai: That wouldn't work, because if you have a sequence of more than one consecutive digit, those digits won't be upright
# [16:15] <dbaron> jdaggett: If an author wants digits upright, they should use text-orientation: upright
# [16:16] <dbaron> jdaggett: yes, it does something in making things upright, but a side effect rather than combining
# [16:17] <dbaron> jdaggett: If somebody thinks it's valuable, they should come up with an example and post to list.
# [16:18] <dbaron> Rossen: is what fantasai wrote on IRC enough?
# [16:18] * Joins: koji (~koji@public.cloak)
# [16:18] <dbaron> fantasai: no. You've seen cases with a single digit upright. If you're having single digits be upright you're usually also going to have pairs of digits be upright, and then you'd want digits 2.
# [16:18] <dbaron> fantasai: not a case we've known people doing
# [16:19] <dbaron> fantasai: can't think why people would want single digits upright but pairs sideways
# [16:19] <dbaron> fantasai: The number is maximum number in sequence that you'd turn upright.
# [16:19] <dbaron> jdaggett: Rossen, you want time?
# [16:19] * Joins: tantek (~tantek@public.cloak)
# [16:19] <dbaron> Rossen: Yes, I'll take some time and get back to you.
# [16:19] <dbaron> fantasai: related issue: we have text about fullwidth numbers that you said when we apply TCY to it it should convert out to ascii
# [16:20] <dbaron> fantasai: did you want digits to also include fulliwdth digits, or just ascii digits?
# [16:20] <dbaron> jdaggett: ascii digits
# [16:20] <dbaron> glenn: There's ... combinations of digits. Does that include fullwidth digits?
# [16:20] <dbaron> fantasai: no
# [16:20] <dbaron> fantasai: The only way you'd get fullwidth digits in TCY is if you specified the 'all' value.
# [16:21] <dbaron> jdaggett: What's in the spec... is the status of linking the text-orientation to UTR50.
# [16:21] <dbaron> fantasai: just need to update reference, everything else as it should be
# [16:21] <dbaron> jdaggett: dfn of text-orientation should be copacetic currently?
# [16:21] <dbaron> fantasai: [reads]
# [16:21] <dbaron> koji: we removed tx values
# [16:22] <dbaron> fantasai: we'll update that
# [16:22] <dbaron> ACTION koji update that
# [16:22] * trackbot is creating a new ACTION.
# [16:22] <trackbot> Created ACTION-582 - Update that [on Koji Ishii - due 2013-09-19].
# [16:22] <dbaron> jdaggett: ... 20 ... example updated?
# [16:22] <dbaron> fantasai: I didn't see what you meant by the example being incorrect?
# [16:22] <dbaron> jdaggett: using width variants a normative requirement ... ? ...
# [16:23] <dbaron> fantasai: only required to use partial width characters if composition doesn't otherwise fit.
# [16:23] <dbaron> fantasai: say I have "'9". I can just put that without requiring turning on halfwidth glyphs.
# [16:23] <dbaron> jdaggett: there's no font that's like that
# [16:23] <dbaron> jdaggett: the minimum width is typically half the width
# [16:23] <dbaron> jdaggett: typically digits in japanese fonts are fixed width, not proportional. example just doesn't make sense.
# [16:24] <dbaron> fantasai: if the text fits without need for compression within 1em, the ua is not required to do any compression
# [16:24] <dbaron> fantasai: the implementation is allowed to check if it needs to use compression and then if it needs to use halfwidth glyphs
# [16:24] <dbaron> jdaggett: in the known universe of japanese fonts either you're going to have to do compression or the font by default has halfwidth glyphs
# [16:24] <dbaron> fantasai: ".9" will often fit without using halfwidth forms
# [16:25] <dbaron> jdaggett: that's only in the context of the all value, not in the context of digits
# [16:25] <dbaron> fantasai: compression algorithm not specific to digits
# [16:25] <dbaron> jdaggett: the cases you're talking about only in the all case
# [16:25] <dbaron> fantasai: ...
# [16:25] <dbaron> jdaggett: I'll look at it again and we'll discuss on the list.
# [16:26] <dbaron> fantasai: So we have one issue out on action from Rossen.
# [16:26] <dbaron> ACTION Rossen check if it's ok to drop support for text-combine-horizontal: digits 1
# [16:26] * trackbot is creating a new ACTION.
# [16:26] <trackbot> Created ACTION-583 - Check if it's ok to drop support for text-combine-horizontal: digits 1 [on Rossen Atanassov - due 2013-09-19].
# [16:26] <dbaron> s/update that/update references to UTR50/
# [16:26] <dbaron> jdaggett: what are we doing about inheritance of text-combine-horizontal
# [16:26] <dbaron> fantasai: we don't have a solution for it
# [16:26] <dbaron> fantasai: dbaron's proposed solution is that 'all' only takes effect if parent isn't all
# [16:27] <dbaron> fantasai: koji had some content with text with t-c-y all containing inside of it a span containing all of the text inside, expecting all the text combined. But this wouldn't be combined due to element boundary.
# [16:27] * sgalineau you'd think walking around the room taking pictures of people wouldn't be so cool after months of NSA scandals; you would be wrong
# [16:27] <dbaron> koji: what do you think about allowing elements within text-combine-horizontal
# [16:27] <dbaron> fantasai: what to do about inline-block with table and some images?
# [16:28] <dbaron> koji: tables not realistic, but are realistic html use cases
# [16:28] <dbaron> koji: allowing elements would be good
# [16:28] <dbaron> SteveZ: example of CO2 in a newspaper
# [16:28] <dbaron> (with subscript)
# [16:28] <Bert> CO2
# [16:29] <dbaron> SteveZ: argument for allowing markup inside TCY
# [16:29] <ChrisLilley> unless you use the opentype features so get a subscript 2, or use the unicode subscript 2
# [16:29] <dbaron> dbaron: non-replaced inline elements only?
# [16:30] <dbaron> SteveZ: plenty of examples in Japan with things with a trademark symbol of some kind embedded; not so likely inside TCY but possible
# [16:30] <dbaron> SteveZ: many signs that begin with a mark
# [16:30] <dbaron> koji: still inline, though
# [16:30] <dbaron> SteveZ: but an image, so replaced
# [16:31] <fantasai> dbaron: Not clear to me, if you're having variant font sizes between things that are supposed to go in TCY, what are you supposed to do to the different font sizes?
# [16:31] * Joins: shans__ (~shans_@public.cloak)
# [16:31] <fantasai> glenn: Similar problem in Arabic with eye-of-alla
# [16:32] <fantasai> glenn: A number of OpenType fonts substitute different sizes of digits to form groups that can fit into this
# [16:32] <fantasai> glenn: Maybe something that's dealt with in font itself
# [16:32] <fantasai> glenn: Looks for enclosing circle followed by N digits, and has entries for 1, 2, or 3 digits
# [16:32] <fantasai> glenn: so font itself might want to select digit variants
# [16:32] <fantasai> dbaron: I feel like we should not try to add complexity to this document right now
# [16:33] <fantasai> jdaggett: Examples koji brings up are relevant, but want to make sure it works without worrying about complicated cases.
# [16:33] <fantasai> SteveZ: Ok with that provided that the way in which we limit it would allow us to extend what's allowed in that in the future
# [16:34] <dbaron> SteveZ: I'm ok if the limitation on content of 縦中横 area is something we could relax in a future draft, and a note saying it would be nice to allow markup inside 縦中横 if we can figure out how to do that.
# [16:34] <dbaron> jdaggett: sounds fine to me
# [16:35] <dbaron> koji: I'm not strongly arguing allowing elements, but want to preserve what's working today.
# [16:35] <dbaron> koji: what's the downside of making this inherit?
# [16:35] <dbaron> koji: I'm happy of making this inherit and keep existing behavior.
# [16:35] <dbaron> fantasai: You get some very interesting behavior
# [16:35] <dbaron> dbaron: I think downside of having inherit makes it nearly impossible to extend to allowing markup in future
# [16:36] <dbaron> koji: but text-combine-horizontal only works in vertical context, and inside is horizontal context
# [16:36] <fantasai> <outer style="text-combine: all">tcy</outer>
# [16:36] <dbaron> fantasai: author expectation is that above markup should work
# [16:36] <fantasai> <outer style="text-combine: all">abc</outer>
# [16:37] <fantasai> a
# [16:37] <fantasai> [bc]
# [16:37] <dbaron> fantasai: but if insted something like above
# [16:37] <dbaron> fantasai: then I get a followed by [bc] as a unit, which is not expected behavior
# [16:37] <dbaron> koji: but if you rotate bc by not inheriting, it's still not expected
# [16:38] <dbaron> fantasai: if we do the case where pretend we're not an inheriting property, then [bc] will just be sideways and none of it will be upright
# [16:38] * Bert thinks that, until we have href on all elements, it will be pretty common to have an extra <a> inside.
# [16:38] <dbaron> SteveZ: could we define the 縦中横 piece to behave like underline does?
# [16:38] <dbaron> SteveZ: so if it's turned on it's turned on for the entire span that it's on?
# [16:38] <dbaron> fantasai: the digits value needs to be inherited but the all value ideally should be inherited
# [16:38] <dbaron> ChrisL: sounds like you need two properties
# [16:39] <dbaron> fantasai: one property was that text-combine-horizontal a shorthand for 2 longhands that authors wouldn't use
# [16:39] <dbaron> s/property/proposal/
# [16:39] <dbaron> ChrisL: what's the downside other than being 2 properties?
# [16:39] <dbaron> fantasai: it's 2 properties
# [16:39] <dbaron> ChrisL: then just do it
# [16:39] <dbaron> koji: it broke my case, right?
# [16:39] <dbaron> fantasai: yes, your case is still broken
# [16:40] * Quits: cyril (~cyril@public.cloak) ("Page closed")
# [16:40] <dbaron> dbaron: not any better than the other solution?
# [16:40] <dbaron> SteveZ: then outer one can behave like underlinne. Once you turn it on, inner levels don't add any more 縦中横. ...
# [16:40] <dbaron> koji: allowing elements inside?
# [16:40] <dbaron> SteveZ: yes.
# [16:40] <dbaron> koji: that's what dbaron doesn't like
# [16:41] <dbaron> SteveZ: once you turn on underline it applies to everything inside
# [16:41] <dbaron> SteveZ: if you define all to behave that way then make it inherit and it doesn't hurt
# [16:41] <dbaron> fantasai: david had suggestion that doesn't have separate properties. Look if your parent has 'all', then you pretend like you're none. And you just have the one property, and we could split later without breakin content.
# [16:42] <dbaron> fantasai: that solves the problem of what's establishing the 縦中横, but still have the problem of inline elements inside it.
# [16:42] <dbaron> ChrisL: the thing about "if your parent has this than do that" sounds like a UA rule using a selector
# [16:42] <dbaron> fantasai: can't select against properties
# [16:42] <dbaron> koji: if the solution is this complex then the only downside of keeping inherit is abc
# [16:42] <dbaron> koji: I don't think anyone would author abc
# [16:43] <fantasai> dbaron: If that's not a problem, then I'm not convinced why the other thing is a problem
# [16:43] <dbaron> fantasai: has to work because of content
# [16:43] <dbaron> koji: probably some converter generates that
# [16:43] <fantasai> koji: Some converter puts directly inside TCY span
# [16:45] <dbaron> dbaron: what if the rule disallowing inlines is changed to say that all the text has to be in the same element parent, but can allow inlines
# [16:45] <dbaron> fantasai: or could allow display:inline
# [16:45] <dbaron> SteveZ: I think dbaron's solution is fairly reasonable, solves koji's problem
# [16:46] <dbaron> Bert: somebody sees it, draws conclusion from that, and then finds it doesn't work anymore
# [16:46] <dbaron> Bert: the spec explains it, but...
# [16:46] <fantasai> [Bert gave example of multiple nested spans with all content, vs trying to make one char blue one char green]
# [16:46] <dbaron> dbaron: If we want to get a spec out the door, we sometimes need to solve a problem with a not very nice solution.
# [16:46] <dbaron> jdaggett: and keep in mind we're talking about 2-4 character spans
# [16:47] <dbaron> SteveZ: I just sent an email to the list with an 8 character span in a 縦中横.
# [16:47] <dbaron> Israel: Does the solution allow for H2O case?
# [16:47] <dbaron> Steve: no
# [16:47] * Quits: Rossen_ (~Rossen@public.cloak) ("")
# [16:47] * Joins: Rossen_ (~Rossen@public.cloak)
# [16:47] <dbaron> fantasai: one thing we could do, maybe not ??? idea, if you have any kind of inline boundaries you still do TCY, but UA allowed to do graphical scale and not do anything smart.
# [16:48] <dbaron> fantasai: Then generator generating markup in Koji's case would not get pretty results, but would still work.
# [16:48] <dbaron> fantasai: Hopefully relatively straightfroward?
# [16:48] <dbaron> fantasai: Rossen, thoughts? you're an implementor.
# [16:48] <dbaron> Rossen: I'm pretty sure we inherit digits.
# [16:48] * Bert to SteveZ: your message was refused by the mlist: too big. Can you make it smaller or put the image somewhere else?
# [16:48] <dbaron> Rossen: and I believe we don't inherit 'all' so we have conditional logic based on the value
# [16:49] <dbaron> Rossen: not awesome ,but solves current problem
# [16:49] <dbaron> SteveZ: I like David's solution, all inherited but if you have parent that has all you ignore it.
# [16:49] <dbaron> Rossen: so you get correct layout but the property from OM is still inherited
# [16:49] <dbaron> SteveZ: the computed value in that case is none then it's effectively none
# [16:49] <dbaron> dbaron: computed value still all
# [16:50] <dbaron> Rossen: In our case we did by ...
# [16:50] * Quits: abucur (~Adium@public.cloak) ("Leaving.")
# [16:50] <dbaron> SteveZ: I think either way is the right answer; the result seems to be the same.
# [16:50] <dbaron> SteveZ: basically saying nested alls don't have any effect.
# [16:50] <dbaron> SteveZ: just different ways of saying that
# [16:50] <dbaron> SteveZ: don't want to rotate internal one again
# [16:51] <dbaron> koji: won't combine again, having no effect is just fine
# [16:51] <fantasai> dbaron: My proposal was that you slightly relax restriction on not having markup inside, say that you can have markup inside if all of the text is in the same parent
# [16:52] * Quits: kawabata (~kawabata@public.cloak) ("Page closed")
# [16:52] <fantasai> dbaron: You could actually get same result by changing rule on when to void all
# [16:52] <fantasai> dbaron: You're limited to text and inline elements
# [16:52] <Bert> (So <tcy>12</tcy> is OK, too)
# [16:52] <fantasai> dbaron: And all of the text has the same parent element
# [16:53] <ChrisLilley> all text and all content are different rules
# [16:53] <fantasai> Alternative proposal: Allow 'display: inline' elements, but if there are any, scale-x the result instead of trying to do fancy things
# [16:53] <fantasai> dbaron: Alternative-alternative proposal is, void the all if your parent is also all unless you're the only child of the parent.
# [16:53] * ChrisLilley except on a tuesday
# [16:54] <fantasai> dbaron: not element-tree child, DOM-tree child
# [16:54] <fantasai> dbaron: though collapsible whitespace might be ok
# [16:54] <fantasai> fantasai: That makes sense to me. I can write that up
# [16:54] <fantasai> dbaron: One thing that makes TCY dangerous is that if you have things inside the markup, you have to worry about borders and padding on those inlines, backgrounds, etc.
# [16:55] <fantasai> dbaron: whereas if there's only text
# [16:55] <fantasai> dbaron: the element that establishes the TCY is still behaving as if it's vertical
# [16:55] <SimonSapin> DOM-tree child meaning that text also counts as a child?
# [16:55] <fantasai> dbaron: New proposal saying that in the case Koji wants to work, you end up with the TCY happening on the innermost element, rather than the outermost element
# [16:55] <fantasai> dbaron: which avoids all that complexity
# [16:56] <fantasai> rossen: If you put inline bg differently on 1, 0, 2, then, what would be effect?
# [16:56] <fantasai> Rossen: ...
# [16:56] <fantasai> dbaron: This is the thing we're trying to not deal with in this level
# [16:57] <fantasai> rossen: or say 'all' doesn't inherit
# [16:57] <fantasai> fantasai: that's a different problem, we already solving that
# [16:57] <fantasai> SteveZ: Why can't we format the string with whatever markup, and then possibly compressing it if I need to?
# [16:58] <fantasai> dbaron: I think jdaggett is better-placed to answer that. A lot of this will be implemented using font features
# [16:58] <fantasai> dbaron: You'll have calculations wrt does it fit, what scaling do we apply to the characters?
# [16:58] <fantasai> dbaron: If you have to deal with inline margins and padding, that makes it much more complicated
# [16:58] <fantasai> SteveZ: Agree it becomes more complex
# [16:59] <fantasai> SteveZ: One simple way out of that is, you simply try to set it to fit, and then squeeze it and live with whatever result is
# [17:00] <fantasai> dbaron: Does the spec require scaling in any other cases?
# [17:00] <fantasai> fantasai: Yes, if you don't get narrow enough glyphs to fit into 1em, you have to scale the result
# [17:01] <fantasai> SteveZ: ...
# [17:01] <fantasai> jdaggett: Up to the implementation
# [17:01] <fantasai> jdaggett: In the case of having appropriate variants for all glyphs, must use those
# [17:02] <fantasai> jdaggett: If not available, then UA does what it thinks is best
# [17:02] <fantasai> SteveZ: If I allow borders and backgrounds around components
# [17:02] <fantasai> SteveZ: I could just set it horizontally, see if it fits, and if it doesn't fit scale it down
# [17:02] <fantasai> SteveZ: borders will change, but oh well
# [17:03] <fantasai> jdaggett: borders inside TCY? really?
# [17:03] <fantasai> SteveZ: Not proposing that as a use case, just as a reasonable fallback
# [17:03] <fantasai> SteveZ: Question is, trying to limit what can be inside TCY
# [17:03] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [17:03] * Joins: ChrisLilley (clilley@public.cloak)
# [17:03] <fantasai> SteveZ: Every time we try to limit, has some disadvantages
# [17:03] <fantasai> SteveZ: So question is, what if we don't limit? would it be a big implementation burden? Produce awful results?
# [17:03] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [17:04] <fantasai> SteveZ: If not too awful, and not so difficult...
# [17:04] <fantasai> koji: What about alternate heights?
# [17:04] * Joins: kawabata (~kawabata@public.cloak)
# [17:04] <fantasai> SteveZ: might need to compress in height direction as well
# [17:04] <fantasai> koji: to 1em
# [17:05] <fantasai> SteveZ: Rossen?
# [17:06] <fantasai> koji: My first vote is just keep it inherited as it is right now
# [17:06] <fantasai> koji: second is dbaron's proposal
# [17:06] <dbaron> s/proposal/first proposal/
# [17:07] * hober dammit rik, are you still in bed?
# [17:07] * glazou that bed really looks like a japanese gate, nice
# [17:08] * jdaggett someone stormed out of the room in disgust?
# [17:10] <SimonSapin> jdaggett, they’re gathering around fantasai drawing on the whiteboard
# [17:11] <jdaggett> yeah, i saw dbaron's camera view...
# [17:11] <Bert> [fantasai is listing the options on the whiteboard]
# [17:11] * glazou and some used that as excuse to get a drink or go to the restrooms ;-)
# [17:12] <koji> Option A) Break TCY if contains elements, inherit to children
# [17:12] <TabAtkins> ScribeNick: TabAtkins
# [17:12] <koji> Option B) Break TCY if contains elements, inherit to only child
# [17:12] <TabAtkins> fantasai: [option a]
# [17:12] <koji> Option B) Accept all 'display:inline' content, scale to 1em square
# [17:12] <koji> s/B/C/
# [17:12] <TabAtkins> fantasai: That means that Koji's case works,
# [17:13] <Bert> <tcy>a<q>bc</q></tcy>
# [17:13] <TabAtkins> fantasai: But it also means that if you have an element with <tcy>a<q>bc</q></tcy>
# [17:13] <TabAtkins> fantasai: The presence of "a" means the outer one won't form tcy, but the inner one will.
# [17:13] <TabAtkins> fantasai: You have to rely on people not using tcy in cases like this.
# [17:13] <TabAtkins> SteveZ: But I can't, so it breaks.
# [17:14] <TabAtkins> fantasai: The only case you need to do this is when it's automatic, for accessibility.
# [17:14] <Bert> <tcy><q>xyz</q></tcy>
# [17:15] <TabAtkins> fantasai: [option b]
# [17:15] <TabAtkins> fantasai: "if my parent has 'all', I won't form tcy, unless I'm the only parent of my child."
# [17:15] <TabAtkins> s/parent of my child/child of my parent/
# [17:15] <TabAtkins> fantasai: [option c]
# [17:16] <TabAtkins> fantasai: Take all display:inline content and generate tcy. If it doesn't fit, we scale it to 1.
# [17:17] <Bert> s/1/1em square/
# [17:17] <TabAtkins> koji: We probably have to disable ??? or tcy ??? for option c.
# [17:18] <TabAtkins> [some discussion of examples on the board, which are way too small for me to see from this distance]
# [17:19] * cabanier hober, kids were yelling downstairs. Quieter up here
# [17:19] <TabAtkins> SteveZ: [something about text emphasis]
# [17:19] <TabAtkins> fantasai: No, it's an inherited proeprty, not like text-decoration. If you change font size, it'll move with it.
# [17:19] <Bert> -> http://dev.w3.org/csswg/css-text-decor-3/#text-emphasis-property text-emphasis in ED
# [17:20] <TabAtkins> fantasai: The escape hatch to put arbitrary stuff in a TCY thing is to just use inline-block instead.
# [17:20] <TabAtkins> fantasai: Instead of actually using TCY
# [17:21] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [17:21] <TabAtkins> [???]
# [17:21] <TabAtkins> szilles: You'd have an inline-block where you're using font substitution to get squished digits.
# [17:22] <Bert> [Discussion of differences between inline block and TCY
# [17:22] <TabAtkins> fantasai: It'll also be underlined, for example, as a single glyph - a strikethrough will be vertical.
# [17:22] <TabAtkins> fantasai: Other Koji point - text emphasis treats TCY as a single character.
# [17:22] <TabAtkins> fantasai: If you allow arbitrary content, you wont' get the right behavior.
# [17:22] <TabAtkins> fantasai: If you scale it.
# [17:23] <TabAtkins> fantasai: This is why we wanted to limit TCY only to text - all these issues start to crop up.
# [17:23] <TabAtkins> dbaron: I don't feel like we have use-cases for this.
# [17:23] <TabAtkins> stearns: CO_2
# [17:24] <TabAtkins> fantasai: That's solvable with unicode codepoints for superscript and subscript chars.
# [17:24] <TabAtkins> SteveZ: Not all fonts have those.
# [17:24] <TabAtkins> fantasai: If it doesn't, sub/sup will look ugly anyway.
# [17:24] <TabAtkins> SteveZ: If do C, with a couple of exceptions you don't have to do anything special.
# [17:24] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [17:25] <TabAtkins> SteveZ: The other require exceptions.
# [17:25] <TabAtkins> koji: Limiting to characters makes code 1 (?) simpler.
# [17:25] <TabAtkins> koji: Code only needs to measure text, not elements.
# [17:25] <TabAtkins> SteveZ: To do line-breaking, it already needs to do all that stuff.
# [17:26] <TabAtkins> SteveZ: You already have code to do inline text layout. That has everything you need.
# [17:26] <TabAtkins> Bert: You don't know how long the line is going to be, as you have no 'width' proeprty.
# [17:26] <TabAtkins> SteveZ: Layout as if the space was infinite, then see if it fits in the em. If it doesn't fit, you compress.
# [17:27] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [17:27] <TabAtkins> Bert: That doesn't work for floats, though - you need containing block size.
# [17:27] <TabAtkins> SteveZ: Yes, but it's typically just a few characters.
# [17:28] <TabAtkins> [agreement to do the rest of the tcy conversation on the side]
# [17:28] <TabAtkins> dbaron: This is what's holding up Writing Modes from CR?
# [17:29] <TabAtkins> fantasai: This, and some cleanup for orthogonal flows (but I don't think that should hold up LC).
# [17:29] <TabAtkins> SteveZ: Could you add these examples and discussion in the thread?
# [17:29] <TabAtkins> fantasai: Okay.
# [17:29] <TabAtkins> fantasai: I still think we should try and solve this in this f2f.
# [17:29] <Bert> (I meant to say that we have to specify in case C what CB you use for the layout, before it gets scaled down.)
# [17:33] <fantasai> ScribeNick: fantasai
# [17:33] <fantasai> sylvaing: Issue 2 in compsoiting spec
# [17:33] <fantasai> sylvaing: specifically about background-blend-mode property
# [17:33] * Quits: ChrisLilley (clilley@public.cloak) (Client closed connection)
# [17:33] * Joins: ChrisLilley (clilley@public.cloak)
# [17:34] * Joins: lmclister (~lmclister@public.cloak)
# [17:34] <fantasai> sylvaing: feedback on that was that instead of specifying backgrounds and blending the backgrounds, could stack elements and blend those
# [17:34] * Joins: koji (~koji@public.cloak)
# [17:34] <fantasai> sylvaing: so question is, whether property is worthit
# [17:34] <fantasai> sylvaing: basic scenario is, element, couple backgrounds, image and color, gradient, etc.
# [17:34] <fantasai> sylvaing: wnat to blend them together
# [17:34] <fantasai> sylvaing: suggest is maybe don't need background-blend-mode property
# [17:34] <fantasai> sy just do it with elements
# [17:34] <fantasai> sy That seems pretty sub-optimal
# [17:34] <fantasai> sylvaing: got to have a bunch of wrapper elements, psoition them together
# [17:35] <fantasai> sylvaing: thigns get more complicated if you want to change blending or backgrounds based on user interaction
# [17:35] * krit Sylvain is sgalineau
# [17:35] <fantasai> sgalineau: we expect that use case for this in many cases will be changing backgrounds
# [17:35] * krit sylvaing as well :P
# [17:35] <fantasai> sgalineau: similar to desire to apply opacity
# [17:36] <fantasai> sylvaing: ppl want bg color, something on top of it, graident, blend them, etc. etc.
# [17:36] <fantasai> sylvaing: if you have to do that with stack of elements, a lot more work
# [17:36] <fantasai> sylvaing: people will not do it, or use js plugin or something to do it
# [17:36] <fantasai> fantasai: So you want to remove issue 2 and close as no change.
# [17:36] <fantasai> fantasai: OK, so are there any objections to that?
# [17:37] <fantasai> dbaron: I guess not?
# [17:37] <fantasai> hober: Who raised the issue?
# [17:37] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [17:37] <fantasai> sylvaing: Don't know?
# [17:37] <fantasai> leaverou: Are there really that many use cases, can't wait until Level 2?
# [17:37] <fantasai> sylvaing: Doesn't seem that hard to implement
# [17:38] <fantasai> leaverou: This is for individual background layers, right?
# [17:38] <fantasai> leaverou: We had discusison on different modes for borders, backgrounds, etc.
# [17:38] <fantasai> sylvaing: Think that was for filters
# [17:38] * cabanier I can only hear Sylvain
# [17:38] <fantasai> krit: we had that in the spec at one point
# [17:38] <cabanier> that was for the different parts of the box model
# [17:39] <cabanier> there are multiple images so you need a list
# [17:39] <fantasai> sylvaing: It's very common for pages to update bg color on hover or active etc.
# [17:39] <fantasai> sylvaing: once you have blending, ppl still do that, say blend color graident + ?
# [17:39] * ChrisLilley he is the only one with a microphone
# [17:39] * cabanier we have a demo that shows the feature
# [17:39] <fantasai> sylvaing: If the only option to do that is stacing bunch of elements, add lots of divs
# [17:39] <fantasai> sylvaing: Question then becomes, is the implementation so heavy that we should force to another level?
# [17:39] <fantasai> sylvaing: Doesn't seem so
# [17:40] <fantasai> ChrisLilley: So you're saying that if we don't do this now, we ask ppl to make bad content
# [17:40] <fantasai> sylvaing: Yeah
# [17:40] <fantasai> sylvaing: [gives more examples, this time with scrolling]
# [17:41] <fantasai> fantasai: What were dbaron's reservations?
# [17:41] <fantasai> dbaron: I'm not convinced it's all that useful, but I guess it's easier than the other stuff in the draft, and therefore might be the only thing we get for awhile
# [17:42] <cabanier> the feature is about to land in mozilla
# [17:42] <fantasai> fantasai: So you're concerned that background-blemd-mode will be implemented and not mix-blend-mode, and so worried ppl will put too much content in backgrounds or something?
# [17:42] <fantasai> dbaron: ...
# [17:42] <fantasai> dbaron: Have lots of concerns wrt mix-blend-mode, but think that's where all the useful stuff is
# [17:43] <dbaron> s/.../I'm ok with it. My bigger concerns are with mix-blend-mode, but that's also where I think the useful stuff is./
# [17:43] <fantasai> fantasai: Do you want to put a note telling implementers to work on mix-blend-mode first?
# [17:43] <fantasai> dbaron: Don't think mix-blend-mode is ready
# [17:43] <fantasai> dbaron: Fine to remove issue
# [17:43] <fantasai> RESOLVED: close issue
# [17:43] <cabanier> yes, would like to know the issues
# [17:44] <fantasai> dbaron: Some of issues with mix-blend-mode were on www-style, also wrote up some as a blog post
# [17:44] <dbaron> http://dbaron.org/log/20130306-compositing-blending
# [17:44] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:44] <fantasai> dbaron: What does mix-blend-mode apply to these days?
# [17:45] <dbaron> sgalineau: all elements?
# [17:45] <fantasai> sylvaing: All elements
# [17:45] <dbaron> dbaron: does it est. a stacking context?
# [17:45] <fantasai> sylvaing: yes
# [17:45] <dbaron> sylvaing/rik: yes
# [17:45] <fantasai> dbaron: If it forces them to establish a stacking context, I have fewer concerns
# [17:45] <fantasai> dbaron: Basic problem with mix-blend-mode is that, and i tried to explain in the blog post, we've been very precise about describing painting order
# [17:46] <fantasai> dbaron: But that assumes that compositive is an associative operation
# [17:46] <fantasai> dbaron: Which is true until you have blend-mode
# [17:46] <fantasai> rik: or opacity
# [17:46] <fantasai> dbaron: No, true with opacity
# [17:46] <fantasai> dbaron: True until you have the stuff in the spec
# [17:47] <fantasai> dbaron: Can get some rounding errors, but in practice ppl don't care about that
# [17:47] <fantasai> dbaron: My issue with this spec is that, in order for this to be interoperable, we need parenthese in Appendix E
# [17:47] <fantasai> dbaron: i.e. not just the list of layers, but which pairs composit in what order
# [17:47] <fantasai> dbaron: Might just be that we pretend it's a postfix op or a prefix op, and all one big operation like that
# [17:48] <fantasai> dbaron: But that's not really the way it works in implementations right now
# [17:48] <fantasai> dbaron: And for this to be interoperable, need to agree on grouping in Appendix E.
# [17:48] <fantasai> dbaron: Problem with doing that is that there are a lot of browser optimizations
# [17:48] <fantasai> dbaron: that interact with this stuff
# [17:49] <fantasai> dbaron: We could disable optimizations when you use this stuff, and probably will need to do that
# [17:49] <fantasai> dbaron: but
# [17:49] <fantasai> dbaron: [...]
# [17:49] <fantasai> krit: ... is defined in the spec
# [17:49] <cabanier> there is really no different of drawing with opacity and drawing with a blendmode
# [17:49] <fantasai> dbaron:
# [17:49] <fantasai> dbaron: where is it defined?
# [17:49] <fantasai> krit: Defined in CSS
# [17:50] <fantasai> dbaron: It's not defined in CSS. We define the layering, but not the grouping.
# [17:51] <cabanier> what is the different between drawing an element with opacity and an element with a blend mode?
# [17:51] <cabanier> there is a difference where you need to know what you draw onto
# [17:52] * Joins: tobie (tobie@public.cloak)
# [17:52] <dbaron> dbaron: I think you're assuming that CSS implicitly defines grouping from the bottom up, in other words that the first composition is the lowest layer with the next lowest, and then the third lowest with that, etc.
# [17:52] <TabAtkins> dbaron: You're probably implicitly assuming that the defined layers are composited in order from the bottom up.
# [17:52] <cabanier> ok. I think that's what David is saying. you need to say that you have to draw in order in order for blending to work
# [17:52] <cabanier> (I think everyone basically does that)
# [17:52] <TabAtkins> dbaron: I think it is worth testing if that is actually what impls do.
# [17:54] <TabAtkins> dbaron: There are definitely some things in cSS that *have* to form a layer.
# [17:54] <TabAtkins> krit: Right. These form a stacking context.
# [17:54] <TabAtkins> dbaron: Right, but there are many other things that make a stacking context.
# [17:54] <TabAtkins> krit: Like transforms.
# [17:55] <SimonSapin> + is associative <=> (a+b)+c == a+(b+c)
# [17:55] <TabAtkins> dbaron: So do we want only the visual things to form groups, or all stacking contexts?
# [17:55] * TabAtkins Simon, + is a bad example - it's also commutative. String addition is a better example.
# [17:56] <SimonSapin> TabAtkins, fair enough
# [17:56] <TabAtkins> krit: Every property that creates a stacking context today creates a group as well.
# [17:56] <TabAtkins> TabAtkins: I think that's what we wanted to do when we last talked about this in SVG as well.
# [17:56] <TabAtkins> sgalineau: And the spec today defines that already.
# [17:57] <TabAtkins> cabanier: The statcking context of the thing you're blending creates a group too.
# [17:57] <TabAtkins> dbaron: Okay. I'll need to review this document.
# [17:57] <TabAtkins> dbaron: It's progressing.
# [17:58] <TabAtkins> cabanier: Can we go to LC?
# [17:58] <TabAtkins> dbaron: I'd like more time to review.
# [17:58] <TabAtkins> dbaron: Last I looked there were parts of the spec that were very difficult to understand, and I"d like to see if that was addressed.
# [17:58] <TabAtkins> dbaron: So I'd like to have more time to review.
# [17:58] <TabAtkins> dbaron: I can try to do it by the next telcon.
# [17:59] * fantasai suggests, in the spirit of renaming things, that we drop the -mode
# [17:59] <dbaron> http://dev.w3.org/fxtf/compositing-1/ is the document you want to take to LC?
# [17:59] <dbaron> cabanier, ^
# [17:59] * fantasai might be biased against -mode properties from having worked off of old CSS3 Text drafts, tho
# [18:00] <dbaron> I think "blend mode" is an existing term.
# [18:00] * Parts: glazou (~glazou@public.cloak) (glazou)
# [18:00] * Joins: glazou (~glazou@public.cloak)
# [18:01] <TabAtkins> RESOLVED: Everyone review Compositing/Blending, we'll take up the question of LC publication at next telcon.
# [18:01] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [18:01] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:01] <TabAtkins> Meeting closed.
# [18:01] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:01] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [18:03] * Quits: Rossen_ (~Rossen@public.cloak) ("")
# [18:03] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [18:03] * Quits: ChrisLilley (clilley@public.cloak) ("Client combusted")
# [18:04] * Quits: michou (~mibalan@public.cloak) ("Leaving.")
# [18:07] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
# [18:07] * Joins: darobin (rberjon@public.cloak)
# [18:08] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [18:09] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [18:09] * Quits: projector (~projector@public.cloak) (Ping timeout: 180 seconds)
# [18:13] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [18:14] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [18:15] * Quits: darobin (rberjon@public.cloak) (Ping timeout: 180 seconds)
# [18:16] * Quits: israelh_ (~israelh@public.cloak) ("Page closed")
# [18:18] * Joins: darktears (~darktears@public.cloak)
# [18:20] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [18:20] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [18:24] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:24] * Quits: ian (~ian@public.cloak) (Ping timeout: 180 seconds)
# [18:25] * Joins: shepazu (schepers@public.cloak)
# [18:33] * Joins: cabanier (~cabanier@public.cloak)
# [18:34] * leaverou is now known as leaverou_away
# [18:35] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:36] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:39] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [18:41] <Zakim> dbaron, you asked to be reminded at this time to go home
# [18:43] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:43] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [18:51] * Joins: rhauck (~Adium@public.cloak)
# [18:52] * Joins: liam (liam@public.cloak)
# [19:03] * Joins: myakura (~myakura@public.cloak)
# [19:04] * Joins: tantek (~tantek@public.cloak)
# [19:05] * Quits: tobie (tobie@public.cloak) (Ping timeout: 180 seconds)
# [19:07] * Zakim excuses himself; his presence no longer seems to be needed
# [19:07] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [19:07] * Joins: krit (~krit@public.cloak)
# [19:44] * Joins: rhauck1 (~Adium@public.cloak)
# [19:47] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [19:48] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [19:59] * Quits: tantek (~tantek@public.cloak) (tantek)
# [20:04] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [20:04] * Joins: darktears (~darktears@public.cloak)
# [20:25] * Joins: teoli (~teoli@public.cloak)
# [20:35] * Joins: dbaron (~dbaron@public.cloak)
# [20:36] * Joins: tobie (tobie@public.cloak)
# [20:43] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [20:52] * Quits: GPHemsley (~GPHemsley@public.cloak) (Ping timeout: 180 seconds)
# [20:52] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [20:52] * Joins: myakura (~myakura@public.cloak)
# [20:52] * Quits: lmclister (~lmclister@public.cloak) ("")
# [20:53] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [20:54] * Joins: myakura_ (~myakura@public.cloak)
# [20:54] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [20:54] * Joins: GPHemsley (~GPHemsley@public.cloak)
# [20:56] * Joins: tantek (~tantek@public.cloak)
# [20:57] * Joins: rhauck (~Adium@public.cloak)
# [21:01] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:11] * Quits: tobie (tobie@public.cloak)
# [21:17] * Joins: lmclister (~lmclister@public.cloak)
# [21:23] * Quits: lmclister (~lmclister@public.cloak) ("")
# [21:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:43] * Joins: leif (~lastorset@public.cloak)
# [21:49] * Joins: leif1 (~lastorset@public.cloak)
# [21:49] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [21:53] * Quits: myakura_ (~myakura@public.cloak) (Client closed connection)
# [21:54] * Joins: myakura (~myakura@public.cloak)
# [22:01] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [22:09] * Joins: lmclister (~lmclister@public.cloak)
# [22:19] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [22:20] * Joins: sgalineau (~sgalineau@public.cloak)
# [22:26] * Joins: shans__ (~shans_@public.cloak)
# [22:27] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:27] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [22:34] * heycam|away is now known as heycam
# [22:36] * Joins: lmclister (~lmclister@public.cloak)
# [22:43] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [22:43] * Joins: darktears (~darktears@public.cloak)
# [22:50] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [22:58] * Joins: florian (~Adium@public.cloak)
# [22:59] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:01] * Joins: teoli (~teoli@public.cloak)
# [23:02] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:21] * Quits: curvedmark (~curvedmark@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [23:24] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:43] * heycam is now known as heycam|away
# [23:44] * Quits: lmclister (~lmclister@public.cloak) ("")
# [23:47] * Joins: lmclister (~lmclister@public.cloak)
# [23:53] * gsnedder1 is now known as gsnedders
# [23:54] * Parts: florian (~Adium@public.cloak) (florian)
# [23:58] * Joins: {Darktears} (~darktears@public.cloak)
# Session Close: Fri Sep 13 00:00:00 2013

The end :)