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

Options:

# Session Start: Fri Sep 13 00:00:00 2013
# Session Ident: #css
# [00:00] * heycam|away is now known as heycam
# [00:02] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 180 seconds)
# [00:10] * Joins: rhauck1 (~Adium@public.cloak)
# [00:14] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [00:20] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:26] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [00:26] * Joins: zcorpan (~zcorpan@public.cloak)
# [00:33] <heycam> TabAtkins, I'm assuming that variable declarations should not work in @keyframes declarations. but should variable references within non-custom properties work there?
# [00:33] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [00:35] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [00:37] * Joins: krit (~krit@public.cloak)
# [00:38] * Joins: krit1 (~krit@public.cloak)
# [00:38] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [00:55] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [01:05] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:14] * Quits: lmclister (~lmclister@public.cloak) ("")
# [01:16] * Joins: lmclister (~lmclister@public.cloak)
# [01:17] * Joins: tantek (~tantek@public.cloak)
# [01:30] * Joins: tobie (tobie@public.cloak)
# [01:40] * Quits: lmclister (~lmclister@public.cloak) ("")
# [01:55] * heycam is now known as heycam|away
# [02:03] * Quits: tobie (tobie@public.cloak)
# [02:10] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:12] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [02:18] * Joins: cabanier (~cabanier@public.cloak)
# [02:20] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:22] * heycam|away is now known as heycam
# [02:28] * Quits: tantek (~tantek@public.cloak) (tantek)
# [02:34] * Joins: lmclister (~lmclister@public.cloak)
# [02:34] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [02:35] * Joins: rhauck (~Adium@public.cloak)
# [02:54] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 180 seconds)
# [03:26] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [03:29] * Joins: jdaggett (~jdaggett@public.cloak)
# [03:31] * Quits: lmclister (~lmclister@public.cloak) ("")
# [03:33] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [04:33] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [05:32] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:41] * Joins: lmclister (~lmclister@public.cloak)
# [06:36] * leaverou_away is now known as leaverou
# [06:37] * leaverou is now known as leaverou_away
# [06:44] * Joins: shepazu (schepers@public.cloak)
# [07:02] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:32] * Joins: teoli (~teoli@public.cloak)
# [07:51] * Joins: krit (~krit@public.cloak)
# [08:04] * heycam is now known as heycam|away
# [08:26] * Joins: projector (~projector@public.cloak)
# [08:26] <projector> trackbot, start telecon
# [08:26] * trackbot is preparing a teleconference.
# [08:26] <trackbot> RRSAgent, make logs member
# [08:26] <RRSAgent> I have made the request, trackbot
# [08:26] * Joins: Zakim (zakim@public.cloak)
# [08:26] <trackbot> Zakim, this will be Style_CSS FP
# [08:26] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [08:26] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [08:26] <trackbot> Date: 13 September 2013
# [08:26] <projector> RRSAgent, make logs public
# [08:26] <RRSAgent> I have made the request, projector
# [08:26] <projector> Zakim, remind us in 10 hours to go home
# [08:26] <Zakim> ok, projector
# [08:28] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [08:34] * Joins: dbaron (~dbaron@public.cloak)
# [08:50] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:50] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [08:50] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:50] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:51] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [08:51] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:52] * Joins: glazou (~glazou@public.cloak)
# [08:52] * Joins: astearns (~astearns@public.cloak)
# [08:54] * heycam|away is now known as heycam
# [09:10] * Joins: sgalineau (~sgalineau@public.cloak)
# [09:10] * liam has a phone call to make that will delay me an hour probably
# [09:13] * dbaron RRSAgent, pointer?
# [09:13] * RRSAgent See http://www.w3.org/2013/09/13-css-irc#T07-06-45
# [09:14] * Joins: yamamoto (~yamamoto@public.cloak)
# [09:15] * Joins: oyvind (~oyvinds@public.cloak)
# [09:15] * heycam is now known as heycam|away
# [09:16] * Joins: krit (~krit@public.cloak)
# [09:20] * Joins: jet (~junglecode@public.cloak)
# [09:20] * krit plinss: glazou In case we have 5min. Can I ask the WG for a review of CSS Masking? I incorporated the feedback of the CSS WG from yesterday and don't have any issues on the spec anymore.
# [09:21] * krit plinss glazou I would like to get to LC after a review time of 2-3 weeks (probably the later because of the other two specs need reviews)
# [09:21] <glazou> krit, ok
# [09:21] <glazou> that's just a review request right ? 5mins ?
# [09:22] <krit> yes, nothing more
# [09:22] <glazou> cool, np
# [09:22] * Joins: florian (~Adium@public.cloak)
# [09:23] * Joins: teoli (~teoli@public.cloak)
# [09:24] * sgalineau Another spec up for LC? We are going to spend the rest of the year renaming things!
# [09:24] * Joins: shans__ (~shans_@public.cloak)
# [09:28] * Joins: darobin (rberjon@public.cloak)
# [09:32] * Joins: michou (~mibalan@public.cloak)
# [09:34] * Joins: israelh (~israelh@public.cloak)
# [09:35] * Joins: kawabata (~kawabata@public.cloak)
# [09:35] <sgalineau> scribenick: sgalineau
# [09:35] <glazou> http://wiki.csswg.org/planning/paris-2013
# [09:35] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:35] <sgalineau> Topic: CSS Masking - review request
# [09:35] <sgalineau> krit: I incorporated yesterday's feedback in the spec
# [09:36] <sgalineau> krit: we will only support one layer of masking
# [09:36] <sgalineau> krit: also I updated the initial values we discussed
# [09:36] <sgalineau> krit: I have no issues in the spec at the moment and would like to ask for review
# [09:36] * Joins: tobie (tobie@public.cloak)
# [09:37] <sgalineau> krit: child selector for the mask image would be at-risk
# [09:37] <sgalineau> glazou: how much time do you need for review
# [09:37] <sgalineau> krit: 3 weeks?
# [09:37] <sgalineau> glazou: ok so 2nd telco from now
# [09:37] <krit> http://dev.w3.org/fxtf/masking/
# [09:38] <sgalineau> fantasai: I'd prefer 4 weeks
# [09:38] <dbaron> so that's October 9
# [09:39] <sgalineau> RESOLVED The WG will review Masking LC transition on 10/9 telcon
# [09:39] <dbaron> Topic: Any interest in working out selection/editing based on display tree rather than DOM?
# [09:39] <sgalineau> astearns: selection/editing only work on the DOM tree
# [09:40] <sgalineau> astearns: when certain positioning modes/layouts get used, selection start looking funny
# [09:40] <sgalineau> astearns: how much interest is there in making selection/editing work on table columns, or select what is inside an abspos and what is next to it vs selecting DOM ranges
# [09:42] <michou> +q
# [09:42] * Zakim sees michou on the speaker queue
# [09:42] <sgalineau> glazou: the problem is selecting visually contiguous areas regardless of whether there are floats or whatever
# [09:43] <sgalineau> astearns: yes. you start selecting inside a float and drag outside, a lot of stuff comes in
# [09:43] <sgalineau> michou: this gets fun with flex box and grids as well, especially when the content has been reordered
# [09:43] <sgalineau> fantasai: my understanding was that the DOM APIs for selection allowed for discontinuous ranges and it was up to the UAs to do the right thing
# [09:44] <sgalineau> astearns: is this WG interested in coming up with an intelligent way to deal with this?
# [09:44] <sgalineau> glazou: I think there are two question 1) is the problem interesting? yes 2) is it a CSS problem? I'm not sure it belong to this WG
# [09:44] <sgalineau> glazou: this seems more a description of visual selection behavior in the UA
# [09:45] <sgalineau> astearns: right. as michou pointed out this is left to UAs
# [09:45] <sgalineau> fantasai: what is the interop we're looking for?
# [09:46] <sgalineau> glazou: I've gotten blue griffon bug reports due to surprises related to caret management
# [09:46] <sgalineau> glazou: WYSIWYG editors behave one way, browser-based editing surprises users
# [09:47] <sgalineau> krit: it's not only selection, it's also accessibility, isn't it?
# [09:47] <sgalineau> fantasai: this can be intentional though
# [09:48] <sgalineau> glazou: I'm really interested in the topic but I do not think this is a CSSWG work item
# [09:48] <sgalineau> plinss: maybe we need APIs that produce ranges based on a geometry
# [09:50] <sgalineau> astearns: the Region spec has APIs to get DOM ranges for a named flow so we're kind of going in that direction
# [09:51] <sgalineau> glazou: would you like to move this to a new ED?
# [09:51] <sgalineau> astearns: not at this time; there doesn't seem to be enough interest in this area at the moment
# [09:52] <sgalineau> Topic: flexbox
# [09:53] <sgalineau> tabatkins: a handful of clarifications and tweaks to the layout algorithm are needed
# [09:53] <projector> http://dev.w3.org/csswg/css-flexbox/#issue-dd911971
# [09:53] * Joins: leif (~lastorset@public.cloak)
# [09:54] <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3
# [09:54] <sgalineau> tabatkins: there is a request to make percentages work well even if the flex item is auto height
# [09:55] <sgalineau> tabatkins: if a flex item is stretched, the fixed container is a fixed height and a child of the flex item uses % the % is resolved against the stretched height of the flex item
# [09:55] <sgalineau> dbaron: is this horizontal only?
# [09:56] <sgalineau> fantasai: apparently IE already implements this; if there is a flex row container and it's auto height, and an item inside it has a % height child….
# [09:56] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:57] <sgalineau> tabatkins: we used to not resolve this. we'll do layout as if it was auto and then resolve those percentage children
# [09:57] <sgalineau> dbaron: what is it that the height applies to?
# [09:57] <sgalineau> dbaron: then I have to relayout
# [09:58] <sgalineau> tabatkins: you relayout the flex item but not the flexbox
# [09:58] <sgalineau> dbaron: small incremental updates may require another pass
# [09:58] <sgalineau> (tabatkins draws a picture)
# [09:59] <sgalineau> dbaron: does the flex box has a fixed height?
# [09:59] <sgalineau> tabatkins: no
# [09:59] <sgalineau> tabatkins: this works well if the item in question is not the tallest
# [09:59] <sgalineau> tabatkins: it's not ideal when the flex item in question is the tallest but it's still better
# [10:00] <sgalineau> dbaron: it sounds a bit like table row sizing
# [10:00] * leaverou_away is now known as leaverou
# [10:00] <sgalineau> dbaron: in tables, % sizing of table cell children appears to be random...
# [10:01] <sgalineau> tabatkins: in this case, it's not hard to depend on
# [10:01] <sgalineau> tabatkins: if you have a fixed height, it just works. otherwise, it does its best attempt and it's workable in most cases
# [10:01] <sgalineau> dbaron: I'd guess I'd be OK. What does dholbert and other implementors think?
# [10:01] <sgalineau> rossen: we're OK with it
# [10:02] <sgalineau> rossen: I thought we had agreed to this at TPAC
# [10:03] <sgalineau> (short exchange ending with tabatkins: oh yeah, I'm making stuff up)
# [10:04] * Joins: tantek (~tantek@public.cloak)
# [10:04] <sgalineau> RESOLVED: use 2-pass algorithm to resolve % height children of flex stretched items pending dholbert's feedback
# [10:05] <sgalineau> tabatkins: issue-3 is the proposed text for issue-2
# [10:06] <sgalineau> tabatkins: next is issue-1 about respecting the intrinsic aspect ratio of flex items
# [10:06] <sgalineau> tabatkins: you don't want to abandon this ratio unless absolutely necessary
# [10:07] <sgalineau> tabatkins: we never resolved the proposed edits
# [10:07] <sgalineau> tabatkins: during the initial sizing, if it is stretched and auto in both dimensions, and the container has a definite cross-size and is single line….then we go ahead and pre-stretch the item and use its ration to figure what its main size
# [10:08] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [10:09] <sgalineau> (tabatkins clarifies the steps for dbaron)
# [10:09] * zcorpan_ unrelated question: are css variables scoped to the stylesheet they're declared in?
# [10:09] <sgalineau> tabatkins: I don't recall any objections; IE already does something close to this
# [10:09] * fantasai no, they're effectively properties
# [10:09] <sgalineau> RESOLVED: proposed issue-1 edits are approved
# [10:10] * fantasai that cascade and inherit just like regular properties, and are therefore scoped to a particular element
# [10:11] <sgalineau> tabatkins: that's it for now; one issue left we need to discuss later.
# [10:11] <sgalineau> fantasai: and then we'll make diffs and move to LC
# [10:11] <sgalineau> Topic: Color module
# [10:11] <sgalineau> tabatkins: a few weeks ago we approved to take my new Color draft
# [10:11] <sgalineau> tabatkins: this is a quick yay/nay on features we'll move to the ED
# [10:12] <sgalineau> glazou: Chris might have input on this but he's not here yet
# [10:13] <projector> http://tabatkins.github.io/specs/css-color/Overview.html
# [10:13] <sgalineau> tabatkins: http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
# [10:14] <sgalineau> tabatkins: I could use help defining what device-cmyk() means
# [10:14] <sgalineau> howcome: if you want CMYK to go into a PDF this is what you use
# [10:14] <sgalineau> simonsapin: is this supported on screen?
# [10:15] <sgalineau> howcome: no. the way people are using it this is just an addition.
# [10:15] <sgalineau> bert: how do you know it's PDF output or not?
# [10:15] <sgalineau> howcome: you just have two declarations. browsers will ignore it.
# [10:15] <sgalineau> tabatkins: I hope we could define it for screen
# [10:15] * zcorpan_ fantasai: you mean the scope is all stylesheets that apply to a particular document?
# [10:15] * fantasai thinks we need ChrisL here
# [10:16] <sgalineau> tabatkins: when do we do this translation?
# [10:16] * fantasai yes, the scope is all stylesheets that apply to a particular document, but it's also scoped by element
# [10:16] * glazou pinged ChrisL, he's arriving
# [10:16] <sgalineau> szilles: the normal meaning is that you don't transform it in any way; you don't translate to the screen because it wasn't set up for that
# [10:16] * zcorpan_ ok
# [10:17] <sgalineau> tabatkins: so you can't interpolate this with other colors
# [10:17] <sgalineau> krit: blending and filter used a unified RGB color space; how do you translate to that color space?
# [10:17] <sgalineau> tabatkins: in those cases I think we can just do a trivial transform; there will be some loss but that cannot be avoided
# [10:18] <sgalineau> tabatkins: i think we should treat device-cmyk as a specific color type that only interpolates with itself.
# [10:18] <sgalineau> tabatkins: and if you use CMYK on a screen I'd like to still be able to show it
# [10:18] <sgalineau> tabatkins: this will take care of blending and compositing
# [10:20] <sgalineau> szilles: PDF predates ICC; there were no profiles. I'm not convinced adobe would advocate using device-cmyk since you're no longer portable...
# [10:22] <sgalineau> ....
# [10:25] <sgalineau> (back and forth, followed by drawing on whiteboard about resolving the color of an overlay scenario)
# [10:26] <sgalineau> (unminutable exchange follows)
# [10:26] <Rossen_> (unminutable design discussion that is)
# [10:27] <fantasai> Håkon: you just dump all the colors into PDF, and the PDF readers figure it out
# [10:27] <fantasai> tantek: But we are a PDF reader. How do we composit this?
# [10:27] <krit> http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf PDF spec
# [10:27] <fantasai> howcome: It's in the PDF spec
# [10:27] <tantek> um I didn't say that
# [10:27] <fantasai> s/tantek/Tab
# [10:27] <tantek> thank you
# [10:27] <fantasai> TabAtkins: ... sending straight to printer
# [10:28] <fantasai> howcome: Printer knows how to draw cmyk
# [10:28] <fantasai> TabAtkins: But it doesn't know how to composit
# [10:28] <fantasai> ScribeNick: fantasai
# [10:28] <fantasai> koji: ... compositing cmyk is different from rgb
# [10:28] * Quits: jet (~junglecode@public.cloak) (jet)
# [10:28] <fantasai> TabAtkins: If you need a cmyk color for interpolating or compositing, or whatever, calc closest rgb color, and use that
# [10:29] <fantasai> dbaron: Then you are presuming non-dvice-specific cmyk
# [10:29] <fantasai> TabAtkins: There's a simplistic one we can use, yes
# [10:29] <fantasai> howcome mumbles
# [10:29] <dbaron> so if we have a formula for non-device-specific cmyk, why would we not want to use that?
# [10:29] <fantasai> howcome: Sometimes you do want two different colors
# [10:29] <fantasai> Florian: that's what media queries are for
# [10:30] * Joins: jet (~junglecode@public.cloak)
# [10:30] <fantasai> Discussion of device-cmyk taking an optional fifth param, which is a fallback rgb color
# [10:31] <fantasai> howcome prefers browsers don't recognize device-cmky
# [10:31] <fantasai> plinss: Wnat to be able to load into browser and print and get the right color
# [10:31] <fantasai> TabAtkins: all of our color math is specified in rgb space
# [10:31] <fantasai> Florian: We need author of doc to not mix colors
# [10:31] <fantasai> TabAtkins: Or to give us a profile , so we can translate properly
# [10:32] <fantasai> someting about not knowing the actual color until it's sent to the printer
# [10:32] <fantasai> Florian: 5th fallback param seems way to go for me
# [10:33] <fantasai> TabAtkins: Want to make sure that, from impl perspective, use cmyk for doc but when compositing with rgb, have
# [10:33] * Joins: koji (~koji@public.cloak)
# [10:33] <fantasai> ???
# [10:33] <fantasai> plinss: Wanting to use fallback color from cmyk() on pixel by pixel basis, when compositing
# [10:33] <fantasai> Florian/Tab note that have to do this when compsiting images anyway
# [10:34] <fantasai> SteveZ: There are rules in PDF for device-cmyk to rgb and vice versa
# [10:34] <fantasai> SteveZ: one suggestion is that you convert device-cmyk to device-rgb, and then treat it as if it were sRGBA
# [10:34] <fantasai> SteveZ: That's a fairly simple thing
# [10:34] <fantasai> SteveZ: Won't give you "right" answer, but it's well-defined, and solves all the problems, without having to do fallback or sometihng like that
# [10:35] <fantasai> SteveZ: Should highlight what's happening
# [10:35] <fantasai> fantasai: Let me see if I understand what you're talking about
# [10:35] <fantasai> fantasai: So you, Tab, were saying that ....
# [10:36] <fantasai> fantasai: If you have a document where everything is opaque, some things in cmyk and some in rgb
# [10:36] <fantasai> fantasai: no problem with sending to printer
# [10:36] <fantasai> TabAtkins: Right
# [10:36] <fantasai> fantasai: So you send to printer cmyk colors and rgb colors
# [10:36] <fantasai> TabAtkins: Yes
# [10:36] <fantasai> fantasai: If you have compositing, you do what?
# [10:37] <fantasai> TabAtkins: For pixels that are being composited, if any of the argumjents are cmyk, turn them into rgb fallback
# [10:37] <fantasai> SteveZ: My suggesiton was to use the PDF rules to turn cmyk to rgb
# [10:38] <fantasai> plinss: Say you have one element, device-cmyk, another element on top of it, partly covered and using rgba
# [10:38] <fantasai> plinss: Don't want the clear parts of the element to be using a different color than the parts of the element that are over the cmyk elekment
# [10:38] <fantasai> plinss: ...
# [10:38] <fantasai> plinss: If you have 1% opacity, don't want to jump into new color space
# [10:39] <fantasai> plinss: If you have one element next to other element, vs. just barely overlapping, also don't want slightly different colors
# [10:40] <fantasai> peter says something important
# [10:40] <fantasai> florian: Being ugly at this point isn't that important; the author messed up. If they don't want it to be ugly, specify colors right
# [10:41] <fantasai> plinss: Just don't want [discontinuities mentioned above]
# [10:41] <fantasai> fantasai: Can you just tain the entire doc if using device-cmyk?
# [10:41] <fantasai> TabAtkins: Would also have to taint it if there is any use of opacity or compsiting...
# [10:42] * leaverou is now known as leaverou_away
# [10:42] <fantasai> TabAtkins: Anything other than entirely opaque
# [10:42] <fantasai> florian: PDF printing already has a pre-print checker, so maybe it's ok
# [10:43] <SteveZ> In http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
# [10:43] <fantasai> dbaron: This doesn't feel like a feature we want in browsers
# [10:43] <fantasai> dbaron: I feel like we should specify it in a way that the print processors can have it
# [10:43] <fantasai> dbaron: In some restricted set of cases
# [10:43] <fantasai> dbaron: Do AH implement things like opacity and blending?
# [10:43] <SteveZ> Section 10.3 describes the rules for converting among device color spaces
# [10:43] <fantasai> howcome: I don't know
# [10:43] <fantasai> howcome: I believe they support opacity
# [10:44] <fantasai> howcome: Print processors, it's easy, they just toss to PDF
# [10:44] <fantasai> howcome: They always print to PDF
# [10:44] <fantasai> TabAtkins: Chrome *is* a PDF viewer
# [10:44] <fantasai> fantasai: Then go to what PDF spec ays
# [10:45] <fantasai> koji: Says that if PDF file has device-cmyk() then it must have mapping, so that you can do interpolation
# [10:45] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [10:45] <fantasai> TabAtkins: Coudl we do that? Assume some default ICC profile, possibly implementation-defined, possibly by inspecting device, but also have a way of specifying specific profile
# [10:45] <fantasai> SteveZ: I would like to go ask color guys at Adobe
# [10:46] * sgalineau seems we used the entire Color module time on device-cmyk(); should we spend some time deciding which new features move to the new ED?
# [10:46] <fantasai> fantasai: So plan should be, copy cmyk text from gcpm, add an issue explaining the problem
# [10:46] <fantasai> +ChrisL
# [10:46] * Zakim wonders where ChrisL is
# [10:46] <fantasai> ChrisL: Sorry to be late, but you're all wrong.
# [10:47] <fantasai> [...]
# [10:47] <fantasai> ChrisL: If it's in device-cmkyk and you want rgb, you do classic ? with absolutely zero idnication that it will be what you want
# [10:47] <fantasai> SteveZ: ...
# [10:47] <fantasai> TabAtkins: So we assume a probably UA-dependent translation rule
# [10:48] <fantasai> TabAtkins: provide way to give an explicit mapping
# [10:48] <fantasai> TabAtkins: and then treat device-cmyk as plain color for all purposes, because we have a mapping
# [10:48] <fantasai> TabAtkins: Default translation should be specified
# [10:48] <fantasai> SteveZ: It's a page and a half in the PDF spec. Just point to it
# [10:49] <fantasai> dbaron: Want to go back that we don't want this in specs
# [10:49] <fantasai> s/specs/browsers/
# [10:49] <fantasai> SteveZ: Why not?
# [10:49] <fantasai> SimonSapin: 2 issues, first one is whether it's supported at all in browsers or more generally, on screen
# [10:49] <fantasai> SimonSapin: 2nd issue is, when we are printing, how does cmyk interact with rgb when we do interpolation , gradient,s compsiting, etc.
# [10:50] <fantasai> ChrisL: depends on whether device-cmyk or ?? standard cmyk
# [10:50] <projector> s/??/ICC-profile/
# [10:50] <fantasai> ChrisL: If you have an ICC profile you know how to convert it to the profile connection space
# [10:51] <fantasai> ChrisL: The profile connection space is either CIE-xyz or CIE-lab
# [10:51] <dbaron> ChrisL: the profile connection space is either CIE XYZ or CIE LAB
# [10:51] <fantasai> ChrisL: Both of these have property that there's no damage, effectively
# [10:51] <florian> s/LAB/Lab/
# [10:51] <fantasai> TabAtkins: They have no gamma, so can put any other space into it
# [10:51] <fantasai> ChrisL: Having done that, you then have to transform it down to sRGB just to do interpolation, because that's the only color space you have
# [10:52] <fantasai> ChrisL: SVG2 had ability to specify interpolation color space
# [10:52] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [10:52] <fantasai> ChrisL: So if you had graident with stops in [lists various prifles], no problem, do your interpolation, then spit out the result into the output color space
# [10:52] <fantasai> s/interpolation/interpolation in the profile color space/
# [10:53] <fantasai> s/color space/connection space/
# [10:53] <fantasai> SimonSapin: What you just explained is all with ICC profiles.
# [10:53] <fantasai> SimonSapin: But the feature in GCPM is device-cmyk()
# [10:53] <fantasai> ChrisL: Means we can come up with a fallback rendering on screen
# [10:54] <fantasai> ChrisL: Could use this in print
# [10:54] <fantasai> Florian: That's the issue here
# [10:54] <dbaron> Florian: this is what we were discussing before ChrisL arrived
# [10:54] <fantasai> Florian: When it's about gradients or animations / transitions, can decide not to interpolate. But for compsiting doesn't have an option. Can't return an error, have to draw something.
# [10:55] <fantasai> ChrisL: As side effect of all that, use exact same method for [...?]
# [10:55] <fantasai> ChrisL: Don't have to say, oh, this is RGBY, whatdo I do with that.
# [10:55] <fantasai> ChrisL: So, shoudl we discuss...
# [10:55] <fantasai> ChrisL: SVG2 has a chapter on this
# [10:56] <fantasai> ChrisL: Would much rather see this in CSS
# [10:56] <dbaron> ChrisL: would rather see this in CSS rather than SVG
# [10:56] <fantasai> ChrisL: Previously, dbaron was concerned that it was a lot of syntax for helping photographers
# [10:57] <fantasai> dbaron: What's "this"?
# [10:57] <fantasai> ChrisL: All of the color chapter in SVG2
# [10:57] <fantasai> dbaron: Don't remember exactly what was in there. Some of it was about prioritization
# [10:58] <fantasai> [we were trying to ship css3-color]
# [10:58] <fantasai> ChrisL: would prefer to put this in CSS4 color, and have the discussion there
# [10:58] <fantasai> ChrisL: Don't want to put things in there and then ... ?
# [10:58] <fantasai> ChrisL: as long as doesn't get screwed up, fine
# [10:59] <fantasai> howcome: Works perfectly right now.
# [10:59] <fantasai> krit: Current implementations in browser it doesn't make sense to differ between SVG colors vs. CSS colors because unified there anyway
# [10:59] <fantasai> dbaron: I agree that it makes more sense in CSS
# [11:00] <fantasai> TabAtkins: OK, resolution, do we want to try for the full gamut of colors right now? Or say that we do simple thing for device-cmyk and just make sure we're compat with full extent
# [11:00] <dbaron> https://svgwg.org/svg2-draft/color.html
# [11:00] <fantasai> ChrisL: People who want CMYK will ignore that it's device-cspecific-cmyk, and forget that they don't get what they really wanted
# [11:00] * glazou should have brought his own http://commons.wikimedia.org/wiki/File:Bicorne_hat_Ecole_Polytechnique.jpg apparently, this place goes too napoleonian
# [11:01] <fantasai> ChrisL: we should give peopel what they really want
# [11:01] <fantasai> ChrisL: They can use common conversion softwares
# [11:01] * dbaron notes that 50 minutes ago tab was going to list some items, and we're now still working on item 1
# [11:01] * Joins: teoli (~teoli@public.cloak)
# [11:01] <fantasai> ...
# [11:01] * Bert :-) at glazou
# [11:01] * Quits: jet (~junglecode@public.cloak) (jet)
# [11:01] <fantasai>
# [11:02] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [11:02] <fantasai> RESOLVED: add ChrisL as co-editor on css4-color
# [11:02] * astearns the list was postponed for ChrisL's arrival - the last 50 minutes were a sideline
# [11:03] <fantasai> AREOLVED: pull in SVG2 color section into CSS4 color
# [11:03] <fantasai> s/AREOLVED/RESOLVED/
# [11:04] <Bert> (I think we should have rendering intent, yes, but why color profiles? That's just adding complexity without functionality.)
# [11:05] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:14] * Quits: tobie (tobie@public.cloak) (Ping timeout: 180 seconds)
# [11:19] * Joins: Rossen_ (~Rossen@public.cloak)
# [11:22] <fantasai> TabAtkins: Going to go through changes I've intorudced in css4-color, give a short description of each, then want show of hands for "yes or no", whether wnat it in the draft
# [11:23] <fantasai> TabAtkins: Want to get a feel for what-all we should do at this level
# [11:23] <fantasai> TabAtkins: Will do arbitrary order
# [11:23] <fantasai> #4 - hex with alpha
# [11:23] <leif> http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
# [11:24] <fantasai> TabAtkins: right now to add alpha you have to convert to rgba()
# [11:24] * Joins: liam (liam@public.cloak)
# [11:24] <fantasai> dbaron: I'm a little iffy about the first four, though nmore the others than this one,
# [11:24] <fantasai> dbaron: Because once you add multiple syntactic ways of doing the same thing, whn preivously only some of them worked,
# [11:24] <fantasai> dbaron: laying a transitional period trap for authors
# [11:25] <fantasai> dbaron: Things will work in the browsers they develop in, but not others
# [11:25] <fantasai> dbaron: when could have been backwards-compatible
# [11:25] <fantasai> ChrisL: I see your point, but don't think it'll be too long of a transitional period
# [11:25] <fantasai> Florian: But what aobut e.g. iphone 3S
# [11:26] <fantasai> dbaron: I'm ok with them, but hesitant for that reason
# [11:26] <fantasai> SteveZ: Other problem is serializing
# [11:26] <fantasai> TabAtkins: That's a general problem
# [11:26] <fantasai> dbaron: I think in general we should serialize to the most broadly-compatible syntax
# [11:26] <fantasai> ChrisL: Disagree, because number has finer granularity
# [11:27] <fantasai> TabAtkins: But you can convert to percentage, which has that granularity
# [11:27] * leaverou_away is now known as leaverou
# [11:27] * Joins: tobie (tobie@public.cloak)
# [11:27] <fantasai> ChrisL: Does that mean that if you provide hsl using angle units, and then serialize it, you'll get back something that was some other syntax?
# [11:27] <fantasai> TabAtkins: yes
# [11:27] <fantasai> TabAtkins: Should be defined already, or we need to define it
# [11:28] <fantasai> TabAtkins: In order of these things, the only ones are Feel strongly about
# [11:28] <fantasai> TabAtkins: 4 because common request (hex colors)
# [11:28] <fantasai> TabAtkins: and #1 because of script-based color manipulation. forget to round, get weird results -- fails to parse sometimes, sometimes not
# [11:28] <fantasai> TabAtkins: Other two are less important, just like them for consistency
# [11:28] <fantasai> TabAtkins: But if compat period pain is sufficinetly large vs benefit, I'm ok with leaving those out
# [11:29] <fantasai> TabAtkins: On that note, can we get some votes?
# [11:29] <fantasai> #1 - number inside rgb/rgba functions
# [11:29] <fantasai> bunch of raised hands for yes, none for no
# [11:30] <fantasai> RESOLVED: rgb() and rgba() will accent <number> rather than <integer>
# [11:30] * Joins: jet (~junglecode@public.cloak)
# [11:30] <fantasai> #2 - hgs() and hgsla() now accept <ang.le> in place of <number> for hues
# [11:30] <fantasai> s/bunch/
# [11:31] <fantasai> s/bunch/most/
# [11:31] <fantasai> bunch of raised hands for yes, none for no
# [11:31] <fantasai> RESOLVED: Allow <angle> in place of <number> for hues
# [11:32] <fantasai> #3 - All uses of <alpha-value> now accept <percentage> as well as <number>
# [11:33] <fantasai> RESOLVED: Accept <percentage> as <alpha-value>
# [11:33] <fantasai> #4- rgba hex colors
# [11:33] <fantasai> RESOLVED: Accept rgba hex colors
# [11:33] <fantasai> zcorpan asks about compat impact
# [11:34] <fantasai> TabAtkins: Did compat research 3 years ago, compat issues are with HTML, not in CSS
# [11:34] <fantasai> zcorpan: If it's been researched and conclusion is that it's safe, then I'm fine
# [11:36] <dbaron> It looks like there was about half a no for #4.
# [11:36] <glazou> that half a no is mine
# [11:36] <fantasai> TabAtkins: another one .. allowing rgb/hsl to take optional 4th argument so don't have to switch to rgba/hsla
# [11:37] <fantasai> #6 - give rgb/hsl ability to take 4th argument
# [11:37] <fantasai> ChrisL: We wanted the function name to represent the arguments
# [11:37] <fantasai> 4-ish yes
# [11:37] <fantasai> 5-ish no
# [11:37] <fantasai> TabAtkins: Ok, I'll leave it out
# [11:37] <fantasai> RESOLVED: No change to number of arguments to rgb/hsl
# [11:37] <fantasai> Discussing now, at #5
# [11:38] <fantasai> 'color-correction' property
# [11:38] <fantasai> ChrisL: hate it
# [11:38] <fantasai> ChrisL: This was somewhat more relvant when Apple had slightly differnet gamma than everyon eelse
# [11:38] <fantasai> ChrisL: If you known what the color means, throwing it at the screen is reasonable to do if your device has smaller gamut than sRGB
# [11:38] <fantasai> ChrisL: once Apple changed to match everyone else, less of a problem
# [11:38] <fantasai> ChrisL:...
# [11:39] * fantasai missed that
# [11:39] <dbaron> s/.../but if you have an AdobeRGB monitor you get really garish colors if the browser just throws sRGB at the screen/
# [11:39] * leaverou is now known as leaverou_away
# [11:40] <fantasai> dbaron: Are browsers currently displaying colors correctly?
# [11:40] <fantasai> ChrisL: Yes, as long as ... ICC profiles
# [11:40] <fantasai> dbaron: You're saying we do it right for images. Do the CSS colors match the images
# [11:40] <fantasai> ChrisL: no
# [11:40] <fantasai> dbaron: Right, and that's the problem this was designed to give a migration path for
# [11:40] <fantasai> ChrisL: It's the wrong way to solve the compatibility issue
# [11:41] <fantasai> TabAtkins: This only applies to untagged images. If you have a color space specified, then you use that.
# [11:41] <fantasai> TabAtkins: It's only untagged images and CSS colors, because theyr'e essentially untagged
# [11:41] <fantasai> ChrisL: CSS colors do have a profile, you just don't have to specify it
# [11:41] <fantasai> dbaron: They're supposed to be sRGB, but not how it has been implemented correctly
# [11:41] <fantasai> dbaron: ... plugins...
# [11:41] <fantasai> dbaron: But that's improved more recently
# [11:42] <fantasai> ChrisL: yes, e.g. flash is color-managed now
# [11:42] <fantasai> dbaron: How do we get flash and css and images to match across devices with different color profiles/
# [11:42] <fantasai> dbaron: The problem is that a lot of web pages expect colors to match flash
# [11:43] <fantasai> dbaron: but if we make CSS colors sRGB, tand flash is not, then get lines in pages where should be seamless
# [11:43] <fantasai> ChrisL: ...
# [11:43] <fantasai> dbaron: I agree with your desired end shtate, but don't understand how to get there from here, without users being mad at their brosers
# [11:44] <fantasai> ChrisL: Theyr'e getting what they want without that property, so how is adding itgoing to change it?
# [11:44] <fantasai> dbaron: They're not getting consistent color across devices
# [11:44] <fantasai> dbaron: This lets authors at least opt-in to saying they want the correct behavior
# [11:44] <fantasai> ChrisL: ...
# [11:45] <fantasai> dbaron: The behavior you're talking about, that CSS is color-managed, is not reality right now.
# [11:45] * Joins: koji (~koji@public.cloak)
# [11:45] <fantasai> TabAtkins: Spec says colors are in sRGB, but in practice they're not.
# [11:45] <fantasai> TabAtkins: Things match because they're handled the same
# [11:46] <fantasai> TabAtkins: This property codifies that default is not color managed
# [11:46] <fantasai> TabAtkins: But allows people to opt into the spec behavior
# [11:46] <fantasai> dbaron: Would like to change default behavior eventually, but need to solve plugin problem.
# [11:46] <fantasai> dbaron: Want API for browser (not content) to tell flash how to color-manage
# [11:46] * fantasai needs dbaron to fix that last statement probably
# [11:47] <fantasai> ChrisL: you're saying that colors match seamlessly already
# [11:47] <fantasai> ChrisL: author can tell Flash to treat colors as sRGB to match sRGB of CSS
# [11:47] <fantasai> dbaron: If someone has the resources to take on adding something to NPAPI, so we can tell plugins to do that, that would be great
# [11:47] <fantasai> dbaron: But barring that, this is an alternative solution
# [11:47] <fantasai> ChrisL: Doesn't seem that hard.
# [11:48] <fantasai> Jet: Not going to happen. People at Adobe that could do this have other things to do
# [11:48] <fantasai> Jet: 2 ppl who can do it that I know, don't work on that anymore
# [11:48] <fantasai> SteveZ: My estimate was that it would be difficult because it takes both sides to make the change: browsers have to ask, and flash has to respond
# [11:49] <fantasai> TabAtkins: At least on our side, it's both sides, because we have our own implementation of flash in Chrome
# [11:49] <fantasai> SteveZ: At least with Google, relationship has been pretty good, but that's only one of the players that has to do it
# [11:49] <fantasai> SteveZ: One comment is that, basically, area of plugins is sensitive, and people don't like playing in that area for various and sundry reasons, more political than technical perhaps
# [11:50] <fantasai> SteveZ: My initial gut feeling is agreeing with Jet, sounds like a good technical solution, but suspect the gods are not in favor of it
# [11:50] * glazou we should move on
# [11:50] <fantasai> ChrisL: We might do better if we ask
# [11:50] <fantasai> SteveZ: If all of the browser vendors asked for it, that would significantly increase the chances of it happening
# [11:50] * glazou we need to move on to charter renewal discussion
# [11:50] <fantasai> TabAtkins: Kills the coordination issue
# [11:51] <fantasai> TabAtkins: So, to wrap up. Yay or nay for having it in the draft. Can always cut out later, add appropriately scary issues around it
# [11:51] <fantasai> SteveZ: I'm ok to put in draft, but issue should describe the problem and say that this is *a* possible solution, but there may be others.
# [11:52] <fantasai> dbaron: When you copied my text, did you copy the introduction bits? Becaue that did try to explain the problem.
# [11:52] <fantasai> krit: Is this mainly for flash, or other content that could benefit?
# [11:53] <fantasai> TabAtkins: In other words, is this mostly a browsers vs. Flash issue?
# [11:53] <fantasai> krit: So, do we really want to add a property that will be deprecated in 2-3 years?
# [11:53] <fantasai> dbaron: I don't know
# [11:53] <fantasai> TabAtkins: Ok, so big issue about this.
# [11:54] <fantasai> RESOLVED: Add 'color-correction' property to Colors 4 draft, with issue about the problem it's trying to solve and consideration that it might not be the right solution.
# [11:54] <fantasai> Bert: I'm not ok with putting in this property
# [11:54] <fantasai> Bert: The property just says "dwim", and shouldn't have to do that.
# [11:54] <fantasai> Bert: The problem is in the implementations.
# [11:54] <fantasai> Florian: Property says which of things I could mean I mean
# [11:56] <fantasai> Liam is also not pleased.
# [11:56] <fantasai> Liam: Lots of changes here in OS support, too
# [11:58] <fantasai> Bert wants the issue to be very conspiciuous
# [11:58] <fantasai> Topic: Charter
# [11:58] <Bert> http://wiki.csswg.org/planning/charter-2013
# [11:59] <dbaron> I disagree with the "what people expect to see in the charter".
# [12:01] <fantasai> Florian: It's easy to say as an editor that will make progress, hard to say def will make it to transition to next status
# [12:01] <dbaron> I don't think this exercise is useful.
# [12:01] <fantasai> Bert: This was starting point for discussion
# [12:01] <fantasai> fantasai: What are we trying to come up with to put in the charter?
# [12:02] <fantasai> Bert: most charter's say how long it'll take to get x to y status
# [12:02] <astearns> dbaron: do you have an alternative exercise in mind for preparing our charter?
# [12:02] <dbaron> astearns, not listing fake deadlines for specs?
# [12:02] <fantasai> Bert: Our charter has traditionally just listed what status we expect to have at the end of the charter period
# [12:02] <florian> q+
# [12:02] * Zakim sees michou, florian on the speaker queue
# [12:03] <glazou> q+ ChrisL
# [12:03] * Zakim sees michou, florian, ChrisL on the speaker queue
# [12:03] <michou> q-
# [12:03] * Zakim sees florian, ChrisL on the speaker queue
# [12:03] <glazou> ack ChrisL
# [12:03] * Zakim sees florian on the speaker queue
# [12:03] <fantasai> fantasai: I think we should just go with the format we used last time
# [12:03] <fantasai> ChrisL: I did a team-internal study on why specs were late
# [12:03] <glazou> q+
# [12:03] * Zakim sees florian, glazou on the speaker queue
# [12:04] <fantasai> ChrisL: And found out that it was largely because people were pressured to put deadlines of 6- months to 2 years
# [12:04] <fantasai> ChrisL: tbecause of afraid ocharter will be rejected
# [12:04] <fantasai> ChrisL: if they gave the real answer
# [12:04] <fantasai> glazou: We have 2 AB members in the room
# [12:04] <fantasai> glazou: Want to say something
# [12:04] <fantasai> glazou: CSSWG is the oldest WG, rechartered every 2-3 yers
# [12:05] <fantasai> glazou: I think system of chartering and rechartering is wrong for such a group
# [12:05] <fantasai> glazou: Charter's are great for group that is to do a specific thing and then close
# [12:05] <fantasai> glazou: But we don't do that, we start things that go one, and star tmore things that contineua fter
# [12:05] <fantasai> glazou: We spend a lot of time on chartering and rechartering
# [12:06] <fantasai> glazou: So I'm ready to take an action, this is something I'm saying ot AB members, want to send message to AC forum describing the issue
# [12:06] <fantasai> glazou: And asking if W3C staff would be willing to find a better solution
# [12:06] <fantasai> SteveZ: 3 answers
# [12:06] <fantasai> SteveZ: It's already under AB agenda under title Super-groups
# [12:06] <fantasai> SteveZ: that is, groups iwht multiple work items progressing largely independently. E.g. webapps has similar concerns
# [12:07] <fantasai> SteveZ: We don't have a good solution t problem yet
# [12:07] <fantasai> SteveZ: The problem you just described is recognized and on the agenda
# [12:07] <fantasai> glazou: Do you think email describing issue can helP?
# [12:07] <fantasai> Tantek, Steve: yes
# [12:07] <fantasai> SteveZ: Fly in the ointment is basically the patent policy
# [12:07] <fantasai> SteveZ: That's because what's on the charte ris what ppl are comitting to potentially make IPR commitments to
# [12:07] <fantasai> SteveZ: So for that reason updating charter on regular basis is not a bad thing, I think.
# [12:07] <fantasai> SteveZ: It's every 2 years
# [12:07] <fantasai> SteveZ: Yes, takes a lot of time, but not all that frequent.
# [12:08] <fantasai> SteveZ: But forces us to do the evaulation, whcihwe maybe ought to be doing more frequently, of are we making the progress we thought we'd make 2 years ago, and if not, why not
# [12:08] <fantasai> SteveZ: Useful excercise in that respect
# [12:08] <fantasai> SteveZ: Most companies do it every eyar
# [12:08] <fantasai> Florian: I think putting dates on things is sometimes useful.
# [12:08] <fantasai> florian: But if we do it for everything, even when not useful, wil confuse things
# [12:09] <fantasai> Florian: For exampl,e, if we had charter that said IE 10 will releas by date X, and want Flexbox must be done before that, useful to say so in charter
# [12:09] <glazou> q+
# [12:09] * Zakim sees florian, glazou on the speaker queue
# [12:09] <glazou> ack florian
# [12:09] * Zakim sees glazou on the speaker queue
# [12:09] <fantasai> Florian: Useufl to say we want to put in date because the date is important,
# [12:09] <florian> ack florian
# [12:09] * Zakim sees glazou on the speaker queue
# [12:09] <fantasai> Florian: But if there's no reason for the date to be important, then shouldn't put it down.
# [12:10] <fantasai> tantek: Would it help to send an email, short answer is yes. If you're ok with it, would also ask to CC www-archive, because I think this is areasonable discusison to stay public
# [12:10] <fantasai> tantek: On specifics of what youraised, I think you'll find as someone who also likes less process and less bureacracy, would agree with mos tof what you said.
# [12:10] <fantasai> tantek: Act of rechartering, for CSSWG, here are list of things we want t owork on, with approximate prieority for next N years, I think that's useful.
# [12:11] <fantasai> tantek: I thin that helps communicate to outside world what WG considers improtant, and gives outside ability to communicate back if they disagree
# [12:11] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
# [12:11] * Joins: darobin (rberjon@public.cloak)
# [12:11] <fantasai> tantek: so I think that's useful
# [12:11] <fantasai> tantek: Sometimes we may wnat to update that more often than just every -23 years
# [12:12] <astearns> s/-23/2-3/
# [12:12] <fantasai> gtantek: About the dates of delivery, I think evidence has shown that any prediction is futile, have yet to sany of them hit by anyaone
# [12:12] <fantasai> tante: So I will counter florian's assertion about dates
# [12:12] <glazou> s/tante/tantek
# [12:12] <fantasai> tantek: with saying that if any editor wnats to promis a date by which they will deliver a certain draft level, welcome to do so
# [12:12] <fantasai> tantek: But to ask the WG as a whole to do so, is ridiculous and bordering on dishonest
# [12:13] <fantasai> tantek: based on how none of that has ever worked
# [12:13] <fantasai> tantek: But if there are editors who feel confident in their ability to predict deadlines, go for it
# [12:13] <fantasai> Florian: not sure we're actually disagreeing
# [12:13] <sgalineau> was a *promise* requested? or an *estimate*? those are very different things
# [12:13] <fantasai> glazou: I agree entirely
# [12:13] <fantasai> glazou: I'm making this dicussion diverge a bit to meta-problem
# [12:13] <fantasai> glazou i really feel we have an issue. This is 3rd time we are rechartering
# [12:13] <fantasai> glazou: Every time it took a few months
# [12:13] <fantasai> glazou: Once took 6 months
# [12:13] <fantasai> glazou: Sucks our time
# [12:14] <fantasai> glazou: Since AB works on that, I didn't know that
# [12:14] <fantasai> glazou: Could we serve an experiment?
# [12:14] <fantasai> glazou: If you're looking for an example if we can make an example, coudl the CSSWG be that example?
# [12:14] <fantasai> glazou: And could we write a charter that lasts a long time, and be amendable in a very simpler way
# [12:14] <fantasai> glazou: Amendabel by note
# [12:14] <Rossen_> s/coudl/could/
# [12:14] <fantasai> glazou: I agree that the deliverable sections and milestones sections, we never meet them, they are crazy
# [12:14] <fantasai> glazou: The potentialy expected deliverable,s and milestones are just [[
# [12:15] <fantasai> glazou: We can reach the CR status, CR and rec is in between impelmenters an writers ouof tests suite, not fully in our hands
# [12:15] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [12:15] <fantasai> glazou: If the AB is interested, for this rechartering, in anotehr way of, doing a charter and managing a working group, even with the patnets issues and everything
# [12:15] <fantasai> glazou: I woild really be glad
# [12:15] <fantasai> tantek: I think that's somehwat in your hands. AB is meeting soson
# [12:16] <glazou> ack glazou
# [12:16] * Zakim sees no one on the speaker queue
# [12:16] <glazou> q+ SteveZ florian
# [12:16] * Zakim sees SteveZ, florian on the speaker queue
# [12:16] <tantek> tantek: and make a proposal per email as said earlier
# [12:16] <fantasai> ChrisL: Another thing that used to happen, the AC would worry about how many groups work working at one time
# [12:16] <fantasai> ChrisL: So they would charter group to do specific thing, an dcease to exit
# [12:16] <fantasai> ChrisL: Then we had idea of adding 6 moths to the end to do maintenance work
# [12:17] <fantasai> ChrisL; then we also found down later that if you closed down a wg, and then reopened to do second version later, you lost all the patent commitements
# [12:17] <fantasai> ChrisL: didn't work for short WGs so much
# [12:17] <glazou> ack ChrisL
# [12:17] * Zakim sees SteveZ, florian on the speaker queue
# [12:17] <fantasai> ChrisL: MathWG oscillates between doing something, and then sits there for 2-3 years so it doens't go away
# [12:17] <fantasai> ChrisL: whether multiple specs or one, the assumption should be that to keep all of the IP commitments alive, the group must not close
# [12:17] <glazou> q+ hober
# [12:17] * Zakim sees SteveZ, florian, hober on the speaker queue
# [12:17] <glazou> ack SteveZ
# [12:17] * Zakim sees florian, hober on the speaker queue
# [12:17] <fantasai> SteveZ: Daniel, your comments you hit on the key point, which is management
# [12:18] <fantasai> SteveZ: of the wg
# [12:18] <fantasai> SteveZ: There's 2 organizations at least that care about that, one is W3C Team, and other is AC
# [12:18] <fantasai> SteveZ: I agree with Tantek's comentns and Florian's comment,s that falue of date sin the short term and not the long toerm
# [12:18] <fantasai> SteveZ: But those were what the team was trying to use to see if progress is being made
# [12:18] <fantasai> SteveZ: So any proposal to eliminate them has to come up with a way of indiciting progres
# [12:19] <fantasai> glazou: Yes, I understand fully
# [12:19] <fantasai> glazou: It's a way of simplyfing things, not eliminating control
# [12:19] <glazou> ack florian
# [12:19] * Zakim sees hober on the speaker queue
# [12:19] <fantasai> Florian: I think I was disagreeing a lot less with Tantek than he thought.
# [12:19] * liam q+ to separate possible procedural changes in the future and the next rechartering, and to note the charter does not commit dates
# [12:19] * Zakim sees hober, liam on the speaker queue
# [12:19] <fantasai> florian: If we have a commitment for a date, and I expec this to be almost never or never happen, useful to state
# [12:20] <fantasai> florian: E.g. in Flexbox case, there was sense of time period
# [12:20] <fantasai> florian: If gorup not commited to that time, then it works ot put that date
# [12:20] * sgalineau animations is only two years behind my first CR estimate *cough*
# [12:20] <fantasai> tantek: I think time urgency should be driven by implementers
# [12:20] <fantasai> hober: So, Chris described previous model of spinnning up and shutting down groups, evolved into hybrid of hibernating rejufinating groups
# [12:20] * dbaron q+ to say that it's worth discussing relative priority of specs, but agree the deadlines are silly
# [12:20] * Zakim sees hober, liam, dbaron on the speaker queue
# [12:20] <fantasai> hober: For core platform work, that model is fiction
# [12:20] <glazou> ack hober
# [12:20] * Zakim sees liam, dbaron on the speaker queue
# [12:20] <fantasai> hober: We have to be conitnuously working on core platform
# [12:21] <fantasai> hober: Steve described effort of rechartering as like annual reviews in a company
# [12:21] <fantasai> hober: I think it's useful to have annual review
# [12:21] <fantasai> hober: Would like to decouple that from rechartering
# [12:21] <fantasai> hober: HTML, CSS, WebPapps need indefinite charters
# [12:21] <fantasai> hober: Said going from CR to REC not in WG hand
# [12:21] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [12:22] <fantasai> hober: Now that we have core testing effort happening at W3C, I think one suggestion we can make at AB/AC is to make these CR transitions to be joint effor tof testing effor tnad that WG
# [12:22] <fantasai> hober: It's partially out of our hands
# [12:22] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [12:22] <fantasai> hober: let's acknowledge that
# [12:22] <fantasai> plinss: Having been in core testing group, they really don't give a shit about advancing specs along REC track.
# [12:23] <fantasai> plinss: The folks involved in web platform testing effort are not interested in advancing REC. Just interested in improving quality in general.
# [12:23] <fantasai> plinss: There is a very small subset that does care about moving to REC. Not my experience that that has any core priority.
# [12:23] * sgalineau Core Testing Group is the Honey Badger
# [12:23] <fantasai> plinss: "If we can do both great, but we're not going to worry about."
# [12:23] <glazou> q+
# [12:23] * Zakim sees liam, dbaron, glazou on the speaker queue
# [12:24] <zcorpan_> q+
# [12:24] * Zakim sees liam, dbaron, glazou, zcorpan_ on the speaker queue
# [12:24] <fantasai> plinss: That's kept me form committing to working with their infrastructure, because if I say "we need this to advance specs to rec" they say "we dont' care about that"
# [12:24] <fantasai> hober: Going from CR to REC shoudl be joint effort, and apparently feedback from testing effort is not interested in that
# [12:25] <fantasai> hober: Unitalteral option is that it stillk is a joint effort, and just make our primary goal reaching CR.
# [12:25] <glazou> ack liam
# [12:25] <Zakim> liam, you wanted to separate possible procedural changes in the future and the next rechartering, and to note the charter does not commit dates
# [12:25] * Zakim sees dbaron, glazou, zcorpan_ on the speaker queue
# [12:25] <fantasai> Liam: Any change to W3C chartering process is not overnight, will tae year or two. So be prepared to do current recharting as perivously
# [12:26] <fantasai> Liam: However, common misconception among WGs, including Team people, is that dates in charter are a commitment. They're not. Just have to document deviations in charter will be documented on homepage
# [12:26] <fantasai> glazou: Kind of thing in W3C Proces sthat nobody reads/cares about
# [12:26] <dbaron> ack dbaron
# [12:26] <Zakim> dbaron, you wanted to say that it's worth discussing relative priority of specs, but agree the deadlines are silly
# [12:26] * Zakim sees glazou, zcorpan_ on the speaker queue
# [12:26] * astearns so we charter with 2yr dates, then we immediately document that those dates are meaningless
# [12:27] <fantasai> dbaron: i think it's worth discussing relative priorities of specs, and don't think it's worth discussing dates
# [12:27] <fantasai> dbaron: If we need to put dates, someone should just make them up
# [12:27] <glazou> ack glazou
# [12:27] * Zakim sees zcorpan_ on the speaker queue
# [12:27] <tantek> Zakim, q?
# [12:27] <Zakim> I see zcorpan_ on the speaker queue
# [12:27] <fantasai> dbaron: I hope that it doesn't, and can just be left out
# [12:27] <fantasai> plinss suggests 12-sided dice
# [12:27] * sgalineau forgot to bring his scheduling dice
# [12:27] <fantasai> glazou: Wrt changing process, I'm happy to just ask for a charter extension. if experiment in 6 months is feasible, willing to try that
# [12:27] <fantasai> glazou: Every time we recharter, has been long and painful effort.
# [12:28] <fantasai> glazou: If there's a better way to do it, I'm willing to try
# [12:28] <glazou> ack zcorpan_
# [12:28] * Zakim sees no one on the speaker queue
# [12:28] <fantasai> zcorpan: Different people have different goals. Some people wnat to advance to REC, and some people wnat to find as many bugs in browser sand get them fixed.
# [12:28] <fantasai> zcorpan_: The testcases in those two goals, have different incentives for writing tests
# [12:28] <glazou> q+ chrisl
# [12:28] * Zakim sees chrisl on the speaker queue
# [12:29] <fantasai> zcorpan_: REC people look at t a test and incentive is that it not finds bugs because it blocks the spec
# [12:29] <glazou> ack chrisl
# [12:29] * Zakim sees no one on the speaker queue
# [12:29] <glazou> q+ glazou
# [12:29] * Zakim sees glazou on the speaker queue
# [12:29] <fantasai> ChrisL; Anothe difference is that platform tests tend to test interactions among tests, whereas REC tests focus on single spec. Deifnite need for interactions
# [12:29] <fantasai> ChrisL: We also need interaction tests within this group
# [12:30] <fantasai> ChrisL: We're not testing that, bu tit's important
# [12:30] <fantasai> ChrisL: thta could show us problems in the specs, that you could only see in combination of things
# [12:30] <florian> q+
# [12:30] * Zakim sees glazou, florian on the speaker queue
# [12:30] <fantasai> glazou: So I think we're agreed that first of our priorirites in rechartering is defining list of priorities
# [12:30] <fantasai> glazou: Figure out what we want to work on. MIlestone section is lower priority, work on list of documents first.
# [12:30] <glazou> qack glazou florian
# [12:31] <glazou> ack glazou florian
# [12:31] <glazou> grr
# [12:31] <glazou> ack glazou
# [12:31] * Zakim sees florian on the speaker queue
# [12:31] <glazou> ack glazou
# [12:31] * Zakim sees florian on the speaker queue
# [12:31] <glazou> q+ tabtek
# [12:31] * Zakim sees florian, tabtek on the speaker queue
# [12:31] <glazou> ack florian
# [12:31] * Zakim sees tabtek on the speaker queue
# [12:31] <fantasai> florian: Topic of tests, I think behavior zcorpan talks about is something we did
# [12:31] <fantasai> plinss: I always describe our testing as 2-phas. Spec testing and conformance testing
# [12:32] <fantasai> plinss: no reaosn why we shouldn't build both test suites in parallel
# [12:32] <fantasai> Florian: If you go for one goal, not going fo other
# [12:32] <fantasai> plinss: Want to buld both test suites in parallel
# [12:32] <fantasai> plinss: Say these are aour spec tests, and these are our conformance tests
# [12:32] <glazou> ack tabtek
# [12:32] * Zakim sees no one on the speaker queue
# [12:32] <fantasai> tantek: I agree with prioritizing the prioritizing, in general
# [12:33] <fantasai> tantek: But I think if something is not important to us, we should dorp it regardless of what's required by process and charter
# [12:33] <fantasai> tantek: Drop sections of charte rthat we don't care about
# [12:33] * hober thinks we could say we expect all specs to hit REC on 30 February
# [12:33] <fantasai> tantek: and move forward with that
# [12:33] <fantasai> tantek: make that proposal, and I'll argue for that before AB
# [12:34] <fantasai> glazou: History of WG has shown that we're realy bad at estimating time for a spec, but we eventually finish it
# [12:34] <fantasai> glazou: So there are usually specs on the wg radar, stay on radar ountil they're done.
# [12:34] <fantasai> SteveZ: Requirement is expected milestones, emaning we don't expect any, then we don't need to record any
# [12:35] <fantasai> ChrisL: One reaosn for this scrutiny because some groups, including in the past this one, have spent 10 years not producing any RECs
# [12:35] <fantasai> ChrisL: Since then have been producing things regularly
# [12:35] <dbaron> The group wasn't "sleeping".
# [12:35] <tantek> q+ to say if it's only "expected milestones" then allow individual editors of documents to offer "expected milestones" for their drafts, and nothing "as a group"
# [12:35] * Zakim sees tantek on the speaker queue
# [12:35] <fantasai> ChrisL: So we can point to that track record.
# [12:35] <fantasai> dbaron: The group wasn't sleeping
# [12:35] <fantasai> ChrisL: from outside, couldn't tell that it was doing anything
# [12:35] <fantasai> glazou: WEb designers community was really mad at us, because we *seemed* to be doing nothing.
# [12:35] <fantasai> ChrisL: Doing a lot of detailed work on CSS2.1
# [12:36] <fantasai> ChrisL: But from management POV, seemd like we weren't producing anything
# [12:36] <fantasai> and this kids, is why not to create monolithing unmmaintainable specs :p
# [12:36] <fantasai>
# [12:39] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [12:42] * Quits: tobie (tobie@public.cloak)
# [12:47] * Quits: jet (~junglecode@public.cloak) (jet)
# [12:47] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [12:48] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [12:48] * Joins: astearns (~astearns@public.cloak)
# [12:49] * Joins: ian (~ian@public.cloak)
# [12:55] * Quits: astearns (~astearns@public.cloak) (Ping timeout: 180 seconds)
# [12:59] * Joins: astearns (~astearns@public.cloak)
# [13:00] * Joins: darktears (~darktears@public.cloak)
# [13:06] * Joins: tobie (tobie@public.cloak)
# [13:06] * Quits: tobie (tobie@public.cloak)
# [13:20] * Joins: jet (~junglecode@public.cloak)
# [13:23] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [13:26] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [13:28] <israelh> q?
# [13:28] * Zakim sees tantek on the speaker queue
# [13:29] * Quits: ian (~ian@public.cloak) (Ping timeout: 180 seconds)
# [13:32] * Quits: jet (~junglecode@public.cloak) (jet)
# [13:35] * Joins: koji (~koji@public.cloak)
# [13:35] <tantek> q?
# [13:35] * Zakim sees tantek on the speaker queue
# [13:35] <fantasai> glazou: Discussion diverged a bit from original goal, but meta-discussion probably is over.
# [13:35] <fantasai> glazou: We need to reach a list of priorities
# [13:36] <fantasai> glazou: Still have option of doing what we did few years ago, asking vendors to send list of priorities
# [13:36] <fantasai> fantasai: Did a poll recently, no?
# [13:36] <fantasai> glazou: Kindof old
# [13:36] <fantasai> glazou: Or could review list of documents now
# [13:37] * Joins: jet (~junglecode@public.cloak)
# [13:37] <fantasai> fantasai: Don't think it would be too bad to put together a list right now, based on the old data
# [13:37] <fantasai> fantasai: Doesn't seem like there's anything controversial in the group right now
# [13:38] <fantasai> glazou: So maybe we take an action to draw up a list and ask for group's feedback
# [13:38] <fantasai> glazou: So what do we do with milestones section?
# [13:38] <tantek> q?
# [13:38] * Zakim sees tantek on the speaker queue
# [13:38] * Joins: shans__ (~shans_@public.cloak)
# [13:38] <tantek> ack tantek
# [13:38] <Zakim> tantek, you wanted to say if it's only "expected milestones" then allow individual editors of documents to offer "expected milestones" for their drafts, and nothing "as a group"
# [13:38] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
# [13:38] * Zakim sees no one on the speaker queue
# [13:38] <fantasai> fantasai: Suggest we follow Tantek's suggestion and leave them out. Replace with pointer to current-work page.
# [13:38] <fantasai> tantek: Since this group has gotten better at keeping list of priorities for specs, maybe not worth group's time to discuss in person
# [13:39] <fantasai> tantek: Would trust the chairs to take existing list, make any small adjustments as they see needed, and send that to group for review
# [13:39] <fantasai> tantek: Think it doesn' need to be discussed f2f, fairly uncontroversial and doubt we'll see much controversy
# [13:39] <fantasai> tantek: So let's move forward with that optimistically
# [13:39] <fantasai> glazou: Other opinions? Or +1? or -1?
# [13:40] <dbaron> +1
# [13:40] <fantasai> glazou: Ok, we'll do that.
# [13:40] <florian> +1
# [13:40] <fantasai> glazou: Related is EPUB interest group
# [13:40] <fantasai> Bert: Think less important than list of priorities
# [13:40] <fantasai> Bert: But need to write something in liaison section.
# [13:40] <fantasai> Bert: Do we want to have any closer cooperation with this group?
# [13:41] <fantasai> glazou: Anyone from interest group that is member of this group?
# [13:41] <fantasai> Bert: Hachete
# [13:41] <fantasai> Bert: Peter
# [13:41] <fantasai> Bert: Bloomberg
# [13:41] <fantasai> Bert: Don't think anyone in room, aside from Peter
# [13:41] <fantasai> fantasai: I think we can figure out logistics of it later, not necessary to put in charter
# [13:42] <fantasai> fantasai: Just put that we will have liaison
# [13:42] * Joins: ChrisL (clilley@public.cloak)
# [13:42] <fantasai> ACTION Peter, glazou: List priorities in charter, submit to WG for review and approval, then submit to staff contact for proposed charter
# [13:42] * trackbot is creating a new ACTION.
# [13:42] <trackbot> Error finding 'Peter,'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [13:42] <fantasai> ACTION glazou: Email AB wrt rechartering woes
# [13:42] * trackbot is creating a new ACTION.
# [13:42] * RRSAgent records action 2
# [13:42] <trackbot> Created ACTION-584 - Email ab wrt rechartering woes [on Daniel Glazman - due 2013-09-20].
# [13:42] <fantasai> and CC www-archive
# [13:43] <fantasai> glazou: Ok, we still need jdaggett for Text
# [13:43] <fantasai> Topic: CSS Ruby
# [13:43] <dbaron> ScribeNick: dbaron
# [13:43] <dbaron> http://dev.w3.org/csswg/css-ruby/
# [13:44] <dbaron> fantasai: koji and I went through entire document. problem with previous ruby draft was had properties but didn't describe layout model.
# [13:44] <dbaron> previous: http://www.w3.org/TR/css3-ruby/
# [13:44] <dbaron> fantasai: previous draft has nice pictures
# [13:44] <dbaron> fantasai: previous lacked box generation rules, etc.
# [13:44] <dbaron> fantasai: we created 2 sections: the ruby formatting model which describes ruby-specific display props, anon boxes, ???, pairing with bases, whitespace, layout, styling, linebreaking, etc.
# [13:45] <dbaron> fantasai: and a handful of cnotrols: ruby-position and ruby-align from old draft, ruby-merge is new for Jukugo
# [13:45] <dbaron> ...ruby
# [13:45] <dbaron> fantasai: and removed some controls that seemed more obscure and defined default or left up to UA
# [13:45] <dbaron> fantasai: and added default style sheet for HTML
# [13:45] <dbaron> fantasai: There's an old XHTML module for complex ruby layout, css-ruby was based on that
# [13:46] <dbaron> fantasai: HTML5 introduced a new ruby model with less markup, only handled basic use cases
# [13:46] <dbaron> fantasai: ruby extension spec being worked on by Robin Berjon, in coord. with fantasai and i18n wg, to address use cases to handle various requirements
# [13:46] <dbaron> fantasai: this draft is written to be able to handle all the ruby markups so far proposed for HTML5
# [13:46] <dbaron> fantasai: and can handle most of the stuff in complex ruby as well
# [13:46] <dbaron> fantasai: there's a bunch of changes we made from previous ruby stuff
# [13:47] <dbaron> fantasai: [summarizes] http://dev.w3.org/csswg/css-ruby/#changes
# [13:48] <dbaron> ... (within summary) changed values of ruby-position to match values of text-emphasis-position
# [13:48] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [13:48] * darobin ping me if you need me for any specific question
# [13:48] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:49] <dbaron> changes section should say that those keywords being changed are values of ruby-align
# [13:49] <dbaron> fantasai: ruby-merge is for jukugo ruby
# [13:49] <dbaron> fantasai: separate: annotation centered across each base
# [13:50] <dbaron> fantasai: collapse: center all the annotations / bases together, but still in the markup for line breaking
# [13:50] <dbaron> fantasai: auto allows UA to do what it wants
# [13:50] <dbaron> fantasai: reason for auto value is that jukugo ruby in jlreq and JIS X 4051 is more complicated than either of these options, want to allow UAs to do that, or something else intelligent
# [13:50] <dbaron> fantasai: initial value is separate
# [13:51] <dbaron> SteveZ: why call it auto?
# [13:51] <dbaron> fantasai: do you have a better name?
# [13:51] <dbaron> ChrisL: that's the usual keyword for "magic thing"
# [13:51] <dbaron> SteveZ: usually it's the default
# [13:51] <dbaron> SteveZ: concerned at 2 levels: (1) inconsistent implementation of 'auto' value, which will make it useless and (2) I think using auto in that sense is not the normal kind of magic
# [13:52] <dbaron> SteveZ: the normal kind of magic is "do what most people would want without having to say anything"
# [13:52] <dbaron> fantasai: we want some way for the author to get the behavior that's hard to dsecribe
# [13:52] <dbaron> fantasai: I don't mind making that the initial value and having separate be an acceptable behavior for 'auto'
# [13:52] <dbaron> SteveZ: I think separate is what most people want most of the tiem
# [13:53] <dbaron> SteveZ: I'm looking for a little more in the way of constraints on the implementation, but I think I understand the difficulty of a full description of jukugo
# [13:53] <dbaron> SteveZ: but seems to me there are some constraints you can talk about that an implementation should meet
# [13:54] <dbaron> fantasai: we gave 2 examples for what auto might mean: one is the algo in jlreq, another is render as mono-ruby if all ruby fit within advances and switch to group ruby otherwise, which is a similar effect to jlreq but much simpler
# [13:54] <dbaron> SteveZ: if you give a constraint about what you do in the overflow case, saying the intent is to do grouping in case they don't fit, that seems a much more useful specification than "do anything"
# [13:54] <dbaron> fantasai: We can expand the description to explain what's desired
# [13:54] <dbaron> SteveZ: then it won't go into effect unless there's an overflow case
# [13:54] <dbaron> SteveZ: that suggests a name of 'overflow'
# [13:54] * Joins: Rossen_ (~Rossen@public.cloak)
# [13:55] <dbaron> fantasai: 'overflow' not a good name; goal is not to overflow. Can mark name as issue.
# [13:55] <dbaron> fantasai: [back to summarizing changes section]
# [13:55] <dbaron> fantasai: didn't inline value of ruby-position put paretheses?
# [13:55] <dbaron> s/fantasai/SteveZ/
# [13:55] * Joins: plh (plehegar@public.cloak)
# [13:55] <dbaron> fantasai: don't know, wsan't defined
# [13:56] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [13:56] <dbaron> fantasai: [looks at old draft] didn't do anything interesting
# [13:56] <dbaron> SteveZ: display:inline of the before and after to get the parentheses will do it
# [13:56] <dbaron> fantasai: shows UA default style sheet ("Supporting Ruby Layout" section)
# [13:57] <dbaron> fantasai: previous spec said not allowed to break w/i ruby base or annotation, which is fine for some typical cases in Japanese where it's just 1-3 characters, but sometimes used for much larger sections
# [13:57] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [13:57] <dbaron> fantasai: so in line breaking section of spec we talk about breaking between bases, which is going to be the default case
# [13:58] <dbaron> fantasai: we also talk about how to do breaking within the bases and how you do that
# [13:58] <dbaron> florian: can you do that reasonably?
# [13:58] <dbaron> fantasai: have to split annotation and base at same spot -- it's going to be an arbitrary location, valid line breaking opportunities in both base and annotations
# [13:58] <dbaron> ChrisL: could mean you have a word on one line and the explanation on another
# [13:59] <dbaron> fantasai: if you have a semantic correspondence that should be encoded in the markup -- this is for the cases where the unit of semantic correspondence is long enough to need breaking
# [13:59] <dbaron> ChrisL: [inaudible]
# [13:59] <dbaron> florian: if this works, tempting to use for cases where not appropriate, will discourage authors from using proper semantic pairing
# [13:59] <dbaron> fantasai: un/likely since (1) default style sheet forbids this type of breaking and (2) people using ruby should know better
# [14:00] <dbaron> florian, SteveZ: [skepticism about (2) but not (1)]
# [14:00] <dbaron> fantasai: shows 'ruby-position' property
# [14:00] <ChrisL> s/[inaudible]/ok, its fine if two long stretches correspond that you break in the middle. Iws more concerened about when there are multiople short corresponding sections, that they be kept together when breaking/
# [14:00] <dbaron> fantasai: takes values as text-emphasis-position and the inter-character value for bopomofo
# [14:00] <dbaron> fantasai: ruby merge property, which we discussed
# [14:00] <dbaron> fantasai: ruby-align: takes these values from alignment spec
# [14:01] <dbaron> fantasai: [shows pictures in spec]
# [14:01] <dbaron> fantasai: wide cell -- expansion opportunities between CJK characters but not latin, so [?] will effectively center but [?] will space out. Get behavior described in jlreq but don't have to inspect text content.
# [14:01] <dbaron> fantasai: those are the three properties, that's all we think is necessary
# [14:02] <dbaron> SteveZ: does the ruby contribute to line height?
# [14:02] <dbaron> fantasai: yes, I'll explain how in a bit
# [14:02] <dbaron> fantasai: section on anonymous ruby box generation to fill in missing boxes for when not in the markup
# [14:02] <dbaron> fantasai: this describes how which annotation matches to which base
# [14:02] <dbaron> fantasai: interesting one is nested ruby (allowed in HTML5).
# [14:02] * Quits: jet (~junglecode@public.cloak) (jet)
# [14:03] <dbaron> fantasai: since ruby interacts with stuff adjacent to it, you can't just put abox inside another box. Nested ruby basically defines spanning behavior, but tree structure with multiple levels of ruby.
# [14:03] <dbaron> SteveZ: One example where I see wanting nested ruby is example in old spec with University on bottom and daigaku on top
# [14:03] <dbaron> fantasai: it will handle that case and other more pathological cases
# [14:04] <dbaron> steveZ: how to get different positions on different rubys?
# [14:04] * Joins: jet (~junglecode@public.cloak)
# [14:04] <dbaron> fantasai: ruby-position property
# [14:04] <dbaron> fantasai: if 2 on same side, closest to base in markup ends up closest to base in rendering, stacked
# [14:05] <dbaron> fantasai: this section weird, if contents of ruby annotation box identical to base, it gets automatically hidden. To handle Word's furigana. So for accessibility reasons and fallback behavior we hide it.
# [14:05] <dbaron> Bert: is identical defined?
# [14:05] <dbaron> fantasai: there's an issue on that whether it's prior to whitespace collapsing. It's a DOM content string match.
# [14:05] <dbaron> SteveZ: which form of unicode?
# [14:06] <dbaron> fantasai/koji: probably codepoint-by-codepoint should be sufficient
# [14:06] <dbaron> fantasai: I don't know about whether before/after whitespace collapsing, happy totake implementor opinions.
# [14:06] <dbaron> Bert: what if content is the same but markup is different, e.g., a span with a color on it?
# [14:06] <dbaron> fantasai: maybe we should do comparison on text content? Good point.
# [14:07] <dbaron> fantasai: section on trimming whitespace. goal is so you can write ruby with appropriate indentation but have that whitespace break the correct results.
# [14:07] <dbaron> fantasai: typically in Japanese don't want whitespace anywhere but want to indent your code.
# [14:07] <dbaron> fantasai: current impls strip whitespace unilaterilly, this breaks use of ruby markup for non-CJK languages
# [14:08] <dbaron> fantasai: have to look at content, similar to way css3-text transforms linebreaks to whitespace or nothing
# [14:08] <dbaron> fantasai: this is a little more sophisticated than existing implementations
# [14:08] <dbaron> liam: would help if middle of that example doesn't say "However, this markup will:"
# [14:08] <dbaron> fantasai: yes, that needs fixing
# [14:08] <dbaron> liam: you mean the second will display *with* spaces
# [14:09] <dbaron> fantasai: nothing magic other than what's in css3-text. Just saying you trim before/after various ruby containers, and just use same rules as in css3-text.
# [14:09] <dbaron> liam: I understand, spec just needs wording fix.
# [14:09] <dbaron> [SteveZ is trademarking "normal magic" :-) ]
# [14:10] <dbaron> fantasai: Ruby layout section describes layout. How to deal with base vs. annotation being wider. Align. [missed a bunch here]
# [14:10] <dbaron> Bert: Q about that: you determine the width by measuring. No upper limit on how wide ruby can get? Unlike floats which are limited to containing block.
# [14:10] <dbaron> fantasai: you can wrap it, though if you have a really long word or nowrap it will get wider
# [14:10] <dbaron> fantasai: which is just like long words in float
# [14:11] <dbaron> SteveZ: recent posting of long ruby examples. Was one that just fit in the height.
# [14:11] <dbaron> SteveZ: so your qusetion is a reasonable one
# [14:12] <dbaron> fantasai: This one is interesting. In this level, I put in a section that box properties don't apply to base container or annotation container boxes. I put this in because I'm concerned about some implementations and how they store their ruby internally. May not make sense for their implementation architecture to have a concept of a ruby annotation container. Let me explain [on whiteboard].
# [14:12] <dbaron> fantasai: interesting boxes in ruby are the base boxes and the annotation boxes
# [14:12] <dbaron> fantasai: in the CSS model we also have boxes here [around base boxes] and here [arround annotation boxes]
# [14:13] <dbaron> fantasai: couldn't think of a use case for styling them, and I know some implementations build boxes the other way around [draws grouping around each base/annotation pair)
# [14:13] <dbaron> fantasai: so easier to make those boxes not stylable (and thus undetectable), as long as inheritance and pairing works as it should
# [14:13] <dbaron> fantasai: so I said no margins/borders/padding/backgrounds/outlines, both for lack of use cases and to avoid constraining architecture of existing implementations
# [14:13] <dbaron> SteveZ: what about color?
# [14:14] <dbaron> SteveZ: ah, color inherits, it works
# [14:14] <dbaron> fantasai: rt { color: green }
# [14:14] <dbaron> fantasai: can just set it directly on the annotation boxes
# [14:14] <dbaron> fantasai: only need to style that thing is to show bounds of those boxes
# [14:14] <dbaron> SteveZ: [mumble mumble]
# [14:15] <dbaron> fantasai: I'm a little concerned about this restriction, but don't want AH to have to rewrite entire impl, given they're doing column-based apporach.
# [14:15] <dbaron> SteveZ: how did they handle overflow?
# [14:15] <dbaron> SteveZ: no reason you can't relax that in the future?
# [14:15] <dbaron> fantasai :right
# [14:15] <dbaron> SteveZ: main use case seems to be debugging
# [14:15] <dbaron> fantasai: then line breaking section, we looked at that
# [14:16] * Quits: Rossen_ (~Rossen@public.cloak) ("")
# [14:16] <dbaron> fantasai: I left bidi as an issue, none of previous specs talk about it, but need to say what happens for bidi text inside ruby container.
# [14:16] <dbaron> fantasai: a bunch of proposals in comments in the source document, but for now leaving as an open issue
# [14:16] <dbaron> SteveZ: so if I have ruby annotations on bidi text, is that obvious what to do?
# [14:16] <dbaron> fantasai: I think reordering should be controlled by bases and annotations controlled by bases
# [14:16] <dbaron> SteveZ: unless jukugo
# [14:17] <dbaron> fantasai: problem is spanning annotations. Need to make sure spanning annotations don't get broken up, since bidi reordering can make something that was contiguous be noncontiguous.
# [14:18] <dbaron> fantasai: can we allow bidi reordering within ruby container, but only allow reordering within a region with a spanning annotation and not outside them. Could describe as embedding or something like that, but not entirely sure what model to use to describe that.
# [14:18] <dbaron> fantasai: constraint is each ruby base and each spanning annotation needs to remain contiguous
# [14:18] <dbaron> fantasai: this section describes how line-height interacts with ruby
# [14:18] <dbaron> fantasai: ensures that if all lines have equal spacing and equal amounts/positioning of ruby annotation, there's enough room to avoid overlap, but ruby annotations might extend outside line box
# [14:19] <dbaron> fantasai: if line height varies, could get overlap; responsibility of author to avoid
# [14:19] <dbaron> fantasai: in the simple cases the line is at least as tall as ruby plus text, but still centered in line box as normal. Ruby doesn't affect position of base text w.r.t. bounds of line box.
# [14:19] <dbaron> SteveZ: the ruby itself is not affecting the line height? author has to set line-height to handle ruby?
# [14:20] <dbaron> Rossen: it will affect it if line-height is 1em and base+text is 1.5em; in that case line-height will extend to be 1.5em
# [14:20] <dbaron> Rossen: but layout of base still centered in middle and ruby text will be pushed out, half inside line and half bleeding into previous
# [14:21] <dbaron> fantasai: [reads relevant text] "Therefore, ordinarily, ruby annotation containers ... , none of the ruby containers would overlap."
# [14:22] <dbaron> fantasai: [draws] say my line height was 1, then add leading.
# [14:22] <dbaron> fantasai: so if we can detect the author's line spacing should be sufficient to accomodate ruby, then we don't do anything. If line-height value isn't sufficient to accomodate ruby, we add leading to accomodate ruby.
# [14:22] <dbaron> Rossen: [clarification question, answered]
# [14:23] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [14:24] <dbaron> dbaron: the annotations don't affect line height/positioning at all, except for this correction you do to increase the line height when it's not sufficient
# [14:24] <dbaron> Bert: so this rule of adding leading is based only on the 'line-height' computed value of the base and dosen't take into account the line box which might already be increased?
# [14:24] <dbaron> fantasai: yes
# [14:24] <dbaron> Rossen: I think it should be the line box.
# [14:25] <dbaron> fantasai: You're adding the leading to the ruby container, not to the line
# [14:26] <dbaron> fantasai: so if you have a 2em tall image, the extra leading won't increase the line height
# [14:26] <dbaron> dbaron: but what about on the other side?
# [14:26] <dbaron> fantasai: it only adds leading on the side the ruby is on
# [14:27] <dbaron> dbaron: seems wrong
# [14:27] <dbaron> fantasai: goal is that if author is providing enough line spacing, we don't do anything special for the ruby
# [14:27] * Joins: Rossen_ (~Rossen@public.cloak)
# [14:27] <dbaron> fantasai: but if the author is not providing enough space, e.g., on a mobile device where they want the spacing to be tight unless there's ruby
# [14:28] <dbaron> fantasai: in that case we do want the line-height to adjust to make space for the ruby, just on that line
# [14:28] * Joins: teoli (~teoli@public.cloak)
# [14:28] <dbaron> ChrisL: so if you want consistent line spacing, set enough space to allow for ruby; if you don't and want things tight, you'll get uneven line spacing
# [14:28] <dbaron> SteveZ: in the first case, you don't contribute to line box calculation; in the second case, you do by putting extra leading on top.
# [14:29] <dbaron> fantasai: right, and the way you tell the difference between the cases is we measure the specified line-height on the ruby-container, and if it's not enough, we add more. If it is enough, assume previous line has provided half of our space.
# [14:30] <dbaron> SteveZ: if I'm aligning a line with ruby on it to a line grid, then I'd better ensure the line-height is of the first kind and doesn't trigger extra leading. Because if I trigger extra leading it'll force the alignment down an extra line.
# [14:30] <dbaron> Rossen: I think the general rule is if you have ruby set your line height big enough.
# [14:30] <dbaron> SteveZ: previously there was a property saying whether ruby should be included in line-height calculation or not
# [14:30] <dbaron> fantasai: instead, we're doing something more automatic here
# [14:30] <dbaron> fantasai: plus a note saying line layout module might add more control
# [14:30] <dbaron> fantasai: but this is a good default behavior
# [14:31] <dbaron> SteveZ: I think your automaticness is good, unconvinced yet it's specified in the right way, need to think more.
# [14:31] <dbaron> fantasai: It's possible to get overlap here. e.g., failure to detect previous line doesn't have your line spacing
# [14:32] <dbaron> Rossen: can avoid by baseline-aligning in this case, which you're not going to have if ... . You're essentially increasing line box height to be that of ruby container but still positioning line in middle, [I didn't follow that at all]
# [14:32] <dbaron> fantasai: that's not how it's done in CSS
# [14:32] <dbaron> fantasai: [explains]
# [14:34] <dbaron> Rossen: [explaining again] This was about the case where line-height is 1em. In which case you obviously don't have enough space for ruby container, which needs 1.5em.
# [14:34] <dbaron> Rossen: In this case, 2mins ago you said you might have overlap with previous line.
# [14:35] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [14:35] <dbaron> fantasai: [draws]
# [14:35] <dbaron> dbaron: if you had half the room you needed, you'd just add half?
# [14:35] <dbaron> fantasai: yes, and all to the top
# [14:35] <dbaron> Rossen: [draws]
# [14:36] * Joins: tobie (tobie@public.cloak)
# [14:37] <dbaron> fantasai: alignment with other content on the line is done solely with the base text
# [14:38] <dbaron> dbaron: which value of vertical-align are you talking about?
# [14:39] <dbaron> SteveZ: center alignment is not within the line box,its wrt the baseline
# [14:39] <TabAtkins> dbaron: There ar eonly two values of vertical-align that are relative to tdhe line box, top and bottom.
# [14:39] <TabAtkins> dbaron: I suppose we have some vertical-text version of those?
# [14:39] <TabAtkins> fantasai: No, still "top" and "bottom".
# [14:39] <TabAtkins> dbaron: All the other values are relative to the parent element.
# [14:39] <TabAtkins> dbaron: So the centering you do in vertical text isn't in the linebox, it's centering with respect to some other baseline established by another element.
# [14:40] <TabAtkins> dbaron: And the linebox can be asymmetric around that line.
# [14:40] <TabAtkins> szilles: The deafult alignment of a replaced alignment is to align its bottom to the dominant baseline.
# [14:40] <TabAtkins> szilles: Which means in this case the replaced elem would stick out from the side.
# [14:40] <TabAtkins> Rossen_: And the ruby base by default has alignment on the center.
# [14:40] <TabAtkins> fantasai: The center of the ruby base.
# [14:41] <TabAtkins> fantasai: If you increase one side fo the line box, it doesn't shift with the linebox. It's not centered wrt to the line box.
# [14:41] <TabAtkins> fantasai: That's what dbaron is trying to say.
# [14:41] <TabAtkins> fantasai: Centering the chars is not centering within a container.
# [14:41] <TabAtkins> fantasai: You're taking a bunch of things that have a baseline, which happens to cut through their center, and aligning the baselines.
# [14:41] <TabAtkins> koji: Against what baseline should they be aligned?
# [14:41] <TabAtkins> koji: Against the center of the parent container, this model will serve.
# [14:42] <TabAtkins> fantasai: It won't, because it's not with respect to the size of the glyphs.
# [14:42] <TabAtkins> Rossen_: Really? For vertical text?
# [14:42] <TabAtkins> fantasai: Yes.
# [14:42] * Joins: teoli (~teoli@public.cloak)
# [14:42] <TabAtkins> fantasai: There's nothing in CSS that does centering between two lineboxes.
# [14:42] <dbaron> s/two lineboxes/the two sides of the linebox/
# [14:42] <TabAtkins> szilles: There's a wonderful note by eric meyer that points out how complex the calculation of lineboxes and their relationship with baselines can get.
# [14:43] <TabAtkins> Rossen_: And when you implement it a couple times, you should know exactly how screwed up it is.
# [14:43] <TabAtkins> szilles: And the same is true for center.
# [14:43] <TabAtkins> fantasai: Remember, we're not adding leading to the line. You're adding stuff to the ruby container.
# [14:43] <TabAtkins> fantasai: The center baseline doesn't shift - it's still in the middle of the ruby base.
# [14:43] <TabAtkins> fantasai: The linebox extends as a result of the ruby getting taller.
# [14:44] <dbaron> SteveZ: agree with intent, not convinced that it works
# [14:44] <dbaron> fantasai: I'm pretty convinced it works
# [14:45] <dbaron> Bert: I'm more concerned about case where you don't increase the line-height.
# [14:45] <dbaron> fantasai: yes, then you can get overlap
# [14:45] * Joins: SteveZ (~SteveZ@public.cloak)
# [14:45] <dbaron> fantasai: but we did that because otherwise you have to inspect content before you, which gets complicated. I think this is a reasonable compromise.
# [14:46] <TabAtkins> fantasai: Some complicated cases about changing font-size or leading or using images might not get handled.
# [14:46] <dbaron> fantasai: It might not handle some cases automatically and you have to be careful
# [14:46] <TabAtkins> szilles: I agree with the intent. I'm less convinced that it works.
# [14:46] <TabAtkins> fantasai: I'm pretty convinced that it does.
# [14:46] <TabAtkins> fantasai: If you do things according to the CSS box model, it should work. If you're doing something slightly different as a shortcut, it might not work.
# [14:46] <TabAtkins> Bert: What about when you have a heading and a paragragh. No margin below the heading. First line of paragraph has some ruby on top.
# [14:46] <TabAtkins> Bert: There's a risk that the ruby overlaps the heading.
# [14:47] * Quits: jet (~junglecode@public.cloak) (jet)
# [14:47] <TabAtkins> fantasai: The mitigating factor there is that you're generally designing a page with X amount of gap between lines in a paragraph, you'll generally have at least X between paragraph and heading already.
# [14:47] <TabAtkins> fantasai: If you dont' have that, it's probably ugly anyway.
# [14:47] <TabAtkins> Bert: About line-breaking.
# [14:47] <TabAtkins> Bert: It says you get a break if the ruby is ???, ???
# [14:48] <TabAtkins> Bert: Figure 4, there's a break opporutnity inside the annotation.
# [14:48] <TabAtkins> Bert: Part of the ruby annoatation is on one line, some on the next.
# [14:48] <TabAtkins> Bert: But it also says that the annotation can be longer than the base.
# [14:48] * Joins: jdaggett (~jdaggett@public.cloak)
# [14:48] <TabAtkins> Bert: So maybe an annotation on one line with empty space, then on the next line is all the base with the rest of the annotation.
# [14:48] <TabAtkins> fantasai: No, you can't have that.
# [14:48] <TabAtkins> koji: Situation is one base character, and a large unbreakable annotation.
# [14:49] <TabAtkins> fantasai: Okay, yes, in that case you can get annotation on a line by itself, if you explicitly opt into annotation breaking.
# [14:49] * Joins: jet (~junglecode@public.cloak)
# [14:49] <TabAtkins> fantasai: I dunno what to do there.
# [14:49] <TabAtkins> TabAtkins: Shift the whole element to the next line?
# [14:50] <TabAtkins> fantasai: In TExt 4, we'll probably have a value that say "suppress wrapping, unless there's no other opportunity on this line".
# [14:50] <TabAtkins> fantasai: And we'll probably shift ruby's default behavior to that.
# [14:50] <TabAtkins> fantasai: I'd like to publish a WD for what's on the site right now, to replace the ancient incompatible /TR version.
# [14:50] <dbaron> +1
# [14:51] <TabAtkins> Bert: There was a more complex case where the ruby spans into an earlier or later characters...
# [14:51] <TabAtkins> Bert: Overhang.
# [14:51] <TabAtkins> Bert: It's fine to be without, but do you ahve an idea how it would be handled?
# [14:51] <TabAtkins> fantasai: The default behavior is to allow a little bit of overhang.
# [14:51] <TabAtkins> fantasai: Currently it's UA defined; in the future we'll probably add a control.
# [14:52] <TabAtkins> fantasai: There's some detail about what character is next, which affeccts whether you can overhang, and we didn't wnat to tackle this.
# [14:52] <TabAtkins> fantasai: Current spec says that overhanging by a quarter-em is generally safe.
# [14:53] <TabAtkins> koji: Most ruby is 1/3 size, so if you overhang by at most 1/3 em you're generally safe.
# [14:53] <TabAtkins> koji: But in general overhang is complex, so we dont' want to do it in level 1.
# [14:53] <TabAtkins> fantasai: I'm going to take an action item to clarify the intention of the 'auto' keyword for ruby-merge.
# [14:54] <TabAtkins> fantasai: The reason we went with auto is that the simple implementation is to automatically choose between separate or collapse.
# [14:54] <TabAtkins> fantasai: And easiest way to do that is auto.
# [14:54] <TabAtkins> ChrisL: Can you do the clarification before publishing?
# [14:54] <TabAtkins> fantasai: I can do it in like 15 minutes or so.
# [14:54] <TabAtkins> ChrisL: Oh, so it's not really the kind of thing that needs review before getting publishing?
# [14:54] <TabAtkins> fantasai: No.
# [14:54] <TabAtkins> ChrisL: Ok.
# [14:55] * Joins: kawabata (~kawabata@public.cloak)
# [14:55] * dbaron hopes the backseat is good for ChrisL's back :-)
# [14:55] <TabAtkins> RESOLVED: Publish fantasai's Ruby draft as WD.
# [14:55] * ChrisL its better than the chairs, yes
# [14:55] * Quits: jet (~junglecode@public.cloak) (jet)
# [14:55] * ChrisL where chairs means the hard upright chairs not the people
# [14:55] * Joins: jet (~junglecode@public.cloak)
# [14:56] * TabAtkins I imagine Peter and Daniel aren't great for your back either, though.
# [14:56] * Joins: florian1 (~Adium@public.cloak)
# [14:56] * Quits: jet (~junglecode@public.cloak) (jet)
# [14:56] * Quits: florian (~Adium@public.cloak) (Client closed connection)
# [14:56] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:56] * Joins: ChrisL (clilley@public.cloak)
# [14:57] * Bert wonders if he can use ruby to make a that neither increases the line box nor overlaps the previous line...
# [14:57] <TabAtkins> [agenda discussion]
# [14:57] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [14:57] * Joins: shans__ (~shans_@public.cloak)
# [14:58] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:58] * Joins: ChrisL (clilley@public.cloak)
# [14:59] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:59] * Joins: ChrisL (clilley@public.cloak)
# [15:00] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:00] * Joins: ChrisL (clilley@public.cloak)
# [15:01] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:01] * Joins: ChrisL (clilley@public.cloak)
# [15:04] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:04] * Joins: ChrisL (clilley@public.cloak)
# [15:05] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [15:09] * Quits: tantek (~tantek@public.cloak) (tantek)
# [15:09] <TabAtkins> Topic: Text
# [15:09] <TabAtkins> fantasai: letter-spacing.
# [15:10] <TabAtkins> fantasai: CSS2.1 says that if you have non-normal letter-spacing, you can't justify between grapheme clusters, only in space characters.
# [15:10] <TabAtkins> fantasai: This is problematic in cjk, because they don't use spaces.
# [15:10] <TabAtkins> fantasai: We have several problesm with the current spec.
# [15:10] <dbaron> http://dev.w3.org/csswg/css-text/#letter-spacing and http://lists.w3.org/Archives/Public/www-style/2013May/0280.html
# [15:10] <TabAtkins> fantasai: One is nobody implements it.
# [15:10] <TabAtkins> fantasai: If you set letter-spacing to 0 or something else, in latin text, yes, you don't get any space. In cjk, no.
# [15:11] * Joins: tantek (~tantek@public.cloak)
# [15:11] <TabAtkins> fantasai: So the text currently thinks "0" and "normal" are the same thing.
# [15:11] <TabAtkins> fantasai: In word-spacing, "normal" *is* equal to 0.
# [15:11] <TabAtkins> fantasai: Those are the problems.
# [15:12] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [15:12] <TabAtkins> Bert: Piont 3 (word-spacing) is an unfortuntae mistake, but unfixable.
# [15:12] <TabAtkins> Bert: I don't think that word-spacing and letter-spacing necessarily need to inform each other.
# [15:12] <TabAtkins> Bert: line-height also has "normal", and we don't compare them.
# [15:12] <dbaron> fantasai^: Reason not to change: existing spec.
# [15:13] <TabAtkins> Bert: When you say "nobody implements it", you mean "..."?
# [15:13] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22width%3A%20200px%3B%20letter-spacing%3A%200%3B%20text-align%3A%20justify%22%3ELorem%20ipsum%20dolor%20sit%20amet%20blah%20blah%20blah%20blah%20blah%20blah%20ah%20blah%20aoeu%20thicuoindeu%20onuech%20ueonh%3C%2Fp%3E
# [15:13] <TabAtkins> fantasai: Implementations don't restrict cjk justification.
# [15:13] <dbaron> never mind my url
# [15:14] <TabAtkins> Bert: ONe change could be to change th emeaning of the existing values.
# [15:14] <TabAtkins> Bert: We could alternately add a value.
# [15:14] * Joins: ChrisL (clilley@public.cloak)
# [15:14] <TabAtkins> fantasai: That makes it unreasonably complicated for authors in a cjk environ. They have to set justification, and also set letter-spacing to something appropriate.
# [15:14] <TabAtkins> Bert: Not necessarily letter-spacing, just text-justify. They do that already.
# [15:15] <TabAtkins> fantasai: No, "auto" (default value) just works. There's a less common justification mode for cjk which they can opt into, but it normally just works.
# [15:15] <TabAtkins> szilles: Restrict letter-spacing for a subset of scripts, and have a cjk-spacing or ideograph-spacing for their separate controls?
# [15:16] <TabAtkins> fantasai: Doesn't work. I believe there's alreayd content with letter-spacing at a positive value that expect spacing on cjk.
# [15:16] <TabAtkins> Bert: Why do people set it to 0?
# [15:16] <TabAtkins> fantasai: Because they think it's the right value, the default value. It's unobservably different if you're not justifying.
# [15:16] <TabAtkins> Bert: I think I liked steve's proposal.
# [15:17] <TabAtkins> fantasai: letter-spacing right now applies to cjk, and it must continue to do so.
# [15:17] <TabAtkins> Bert: It's not that it doesn't apply. It's just that letter-spacing:0 lets you justify between cjk.
# [15:18] <TabAtkins> fantasai: Okay, so proposal is that letter-spacing never restricts justification for cjk, but non-"normal" values restrict justification for latin and similar scripts.
# [15:18] <TabAtkins> Bert: How to define "similar scripts"?
# [15:18] <TabAtkins> fantasai: Dunno.
# [15:19] <TabAtkins> liam: If you have a passage of english text with a short passage of chinese, and have justification turned on, those characters coudl be spread apart?
# [15:19] <TabAtkins> fantasai: Yes.
# [15:19] <TabAtkins> fantasai: Spaces get priority over inter-cjk, though.
# [15:19] <TabAtkins> szilles: One way to distinguish language categories would be if they use a word space.
# [15:19] <TabAtkins> fantasai: So thai would be with chinese, but korean would be with latin?
# [15:20] <TabAtkins> szilles: Yes. If you have spaces, no need to do anything else.
# [15:21] <TabAtkins> koji: "word space" in unicode is one of the non-script-specific characters, so that doesn't tell us anything.
# [15:21] <TabAtkins> koji: We'd need to have a script-based property for this.
# [15:22] <TabAtkins> szilles: My concern is that there may be languages that use a script with word space, and another language that uses the same script without spaces.
# [15:22] <TabAtkins> fantasai: This seems overcomplicated. Already, "normal" and "0" just seem confusing for authors.
# [15:22] <TabAtkins> Bert: The fact that there are two values implies that they're different.
# [15:22] <TabAtkins> fantasai: A lot of people probably dont' even realize there's a "normal" value, and the fact that it looks the same as "0" normally doesn't help.
# [15:23] <TabAtkins> fantasai: I think having sccript-specific behavior tied to "nromal" vs "0" is also confusing.
# [15:23] <TabAtkins> Bert: The best solution is to have some other feature to turn on flexible letter-spacing.
# [15:23] <TabAtkins> fantasai: Things should work by default, and you're proposing that justifcation doesn't work by default for cjk.
# [15:23] <TabAtkins> Bert: The spec already doesn't work for cjk.
# [15:23] <TabAtkins> Bert: So don't break latin, just add something for cjk.
# [15:24] <TabAtkins> fantasai: We're not getting anywhere, so I'm giving up for now.
# [15:24] <TabAtkins> szilles: Well, we at least came up with several possible solutions.
# [15:24] <TabAtkins> Topic: text-align
# [15:25] * Joins: ian (~ian@public.cloak)
# [15:25] <TabAtkins> dbaron: Can we get a report of which impls actually have a normal vs 0 distinction right now?
# [15:25] <TabAtkins> fantasai: That's the issue - none of them do.
# [15:25] <TabAtkins> fantasai: If we make this change to the spec we're bringing it in line with impls.
# [15:26] <dbaron> dbaron: I couldn't find a CJK testcase where an implementation does inter-letter spacing for CJK justification
# [15:27] <TabAtkins> fantasai: You have to set [lang] correctly...
# [15:28] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2521
# [15:28] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22width%3A%20207px%3B%20background%3A%20lime%3B%20letter-spacing%3A%200%3B%20text-align%3A%20justify%22%20lang%3D%22zh%22%3E%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7
# [15:28] <dbaron> %A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6
# [15:29] <TabAtkins> dbaron: I can't get Chrome to do any inter-character justification even with [lang]
# [15:29] <TabAtkins> fantasai: I think Chrome needs you to set text-justify to something else.
# [15:30] <TabAtkins> fantasai: Even if we change text-justify, the spec says that "0" means you can't justify between letters. So we still need to change something.
# [15:31] <TabAtkins> koji: I think what STeve is askign for is to have a way to disable letter justifycation.
# [15:31] <TabAtkins> szilles: To have a way of tracking which languages use inter-letter justification.
# [15:31] <TabAtkins> koji: We want today's behavior to not change, correct?
# [15:31] <TabAtkins> szilles: Close. I'm okay with...
# [15:32] <liam> s/askign/asking/
# [15:32] <TabAtkins> fantasai: I think what makes the most sense is to make normal compute to 0, as it does with word-spacing.
# [15:32] <liam> s/justifycation/justification/
# [15:32] <TabAtkins> fantasai: And if we want a way to turn off inter-letter spacing, but that in text-justify.
# [15:32] <TabAtkins> dbaron: I think using "letter-spacing:0" to prevent inter-letter justification is not intuitive.
# [15:33] <TabAtkins> Bert: I think it's perfect. We don't need an extra property.
# [15:33] <astearns> +1 on dbaron's statement
# [15:33] <TabAtkins> szilles: We're trying to come up with a solution that matches today, is reasonable to explain, and gives me the ability to do tracking and allow justification using letter spacing.
# [15:34] <TabAtkins> dbaron: I think we have a set of justification controls that I believe can do this already.
# [15:34] <TabAtkins> dbaron: And we have something that is not intuitive in the spec, that doesn't match impls, and that we'd like to get rid of. I don't see what the problem is.
# [15:34] <TabAtkins> szilles: Evidence seems to say it does match impls...?
# [15:34] <TabAtkins> szilles: Except for 0.
# [15:34] <TabAtkins> dbaron: That's what we're talking about.
# [15:35] <TabAtkins> dbaron: 0 vs normal
# [15:35] <TabAtkins> Bert: The problem is that once I set a letter-spacing value, it shouldn't do inter-letter justification.
# [15:35] <TabAtkins> Bert: It's nice that if you set it to 0, it also means no spacing.
# [15:38] <TabAtkins> fantasai: So proposal is that if you set letter-spacing to a <length>, any length, you can still justify. (Plus a control on text-justify that prevent sjustification.)
# [15:38] <TabAtkins> dbaron: But the spec currently says that setting a <length> should disable justification. The impls that do perform inter-character justification don't follow the spec, and *do* allow jsutification.
# [15:39] <TabAtkins> szilles: So right now we have one property doing both tracking and justification control...
# [15:39] <TabAtkins> fantasai: What I'd like to see is that letter-spacing has no effect on justification.
# [15:39] <TabAtkins> fantasai: If you want to disable justification, use text-justify.
# [15:39] <TabAtkins> szilles: So letter-spacing becomes tracking only.
# [15:39] <TabAtkins> szilles: And "normal" and "0" are the same.
# [15:39] <TabAtkins> Bert: Then we have a redundant value.
# [15:40] <TabAtkins> szilles: That's okay.
# [15:41] <TabAtkins> Bert: I dont' want to change it in the cases where it currently works.
# [15:41] <TabAtkins> dbaron: We *have* found that some brwosers do cjk inter-character justification, and they violate the spec (doing it anyway, regardless of letter-spacing). They don't do inter-character for latin, so your case still works.
# [15:42] <TabAtkins> fantasai: So my proposal is that text-justify has "auto", "inter-word", and "distribute".
# [15:42] <TabAtkins> szilles: None of those do what japanese does.
# [15:42] <TabAtkins> szilles: jl-req has a big table that does different things based on the letters.
# [15:42] <TabAtkins> fantasai: That's "auto".
# [15:42] <TabAtkins> dbaron: Does it vary based on tracking?
# [15:42] <TabAtkins> szilles: I dont' think it talks about tracking.
# [15:43] <TabAtkins> fantasai: "auto" explicitly does that jl-req stuff.
# [15:43] <dbaron> steveZ: fine, then I'm happy
# [15:43] <TabAtkins> ChrisL: So is "auto" testable?
# [15:44] <TabAtkins> fantasai: Still no. jl-req is an informative ref.
# [15:44] <TabAtkins> szilles: This is something where we want impls to compete for better quality.
# [15:44] <jdaggett> hmm, 'auto' as currently define *may* do JLREQ stuff
# [15:44] <TabAtkins> fantasai: And there's a simple auto algorithm that they can do instead.
# [15:44] <jdaggett> there's no normative requirement for such behavior
# [15:44] * TabAtkins jdaggett, yes, that's what we're saying.
# [15:45] <TabAtkins> ChrisL: So there's no way to explicitly say "use jl-req"?
# [15:45] <TabAtkins> fantasai: No. Japanese people have been kind and obsessive enough to write down a very good algorithm, but *nobody else* does that
# [15:46] <TabAtkins> szilles: Japan has house styles that vary the jl-req table.
# [15:46] * dbaron wonders how this is related to the normal vs. 0 issue
# [15:46] <TabAtkins> szilles: InDesign lets you control those things.
# [15:46] <ChrisL> and no way to say 'I implement jlreq but want the fast one instead'
# [15:47] <dbaron> SteveZ: I'm fine with this.
# [15:47] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [15:47] <TabAtkins> liam: I wanted to make sure this didn't exclude arabic kashida justification.
# [15:47] <TabAtkins> fantasai: We had a specific value, but killed it. "auto" allows that, and the spec has an example.
# [15:47] * dbaron wonders how this is related to the normal vs. 0 issue
# [15:48] <TabAtkins> liam: Also, when doing copyfitting, you often have multiple things you want to list which controls what things are allowed to vary. Maybe have multiple values here?
# [15:48] <TabAtkins> fantasai: I want to address that in the future. This doesn't block it.
# [15:48] * Joins: kawabata (~kawabata@public.cloak)
# [15:49] <TabAtkins> [straw poll, the yay carries]
# [15:49] <dbaron> ~15 in favor, Bert against
# [15:49] <TabAtkins> Bert: I dont' understand why you change an 18-year old spec.
# [15:49] * Joins: teoli (~teoli@public.cloak)
# [15:49] <TabAtkins> plinss: To match implementations, none of which amtch the spec.
# [15:50] * dbaron jdaggett can you join the Vidyo?
# [15:51] <TabAtkins> RESOLVED: letter-spacing: <length> doesn't restrict justification. text-justify:inter-word; disables inter-letter justification.
# [15:51] <TabAtkins> fantasai: word-spacing:normal computes to 0. For consistency, I say we do the same thing with letter-spacing.
# [15:52] <TabAtkins> Bert: I don't think there's a strong consistency argument.
# [15:52] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:52] * Joins: ChrisL (clilley@public.cloak)
# [15:52] <TabAtkins> TabAtkins: I think word-spacing and letter-spacing are reasonable to tie in consistency arguments.
# [15:52] <TabAtkins> fantasai: Also, this means the computed vaue is just alength, which helps.
# [15:52] <TabAtkins> RESOLVED: letter-spacing:normal; computes to 0.
# [15:53] <TabAtkins> fantasai: A new compication with ??? was found by koji.
# [15:54] <TabAtkins> fantasai: <tcy>text</spa></tcy>
# [15:54] <TabAtkins> fantasai: Koji and I were discussing this,a nd right now when we evaluate how much text to turn into a tcy run, we go across the entire contents of the element.
# [15:54] <TabAtkins> fantasai: Whether or not you turn it into tcy depends on whether there's an element boundary in it.
# [15:54] <TabAtkins> fantasai: If there's a boundary, we give up.
# [15:55] <TabAtkins> glenn: Remember that TCY is a japanese word, while t-c-h is a property name. Consistency?
# [15:55] <TabAtkins> fantasai: Koji and I were thinking of changing this, so that we just split up the text into runs between boundaries, then evaluate tcy on that.d
# [15:55] * liam tcbv (this can't be vertical
# [15:56] <TabAtkins> fantasai: So if I set tch:all here, I'll take the whole text run and turn it into tcy.
# [15:56] <TabAtkins> fantasai: <tcy>a<q>bc</q></tcy>
# [15:56] <TabAtkins> fantasai: Here, "a" becomes a tcy (turning upright), and "by" becomes a tcy.
# [15:56] <TabAtkins> Rendered like:
# [15:56] <TabAtkins> a
# [15:56] <TabAtkins> bc
# [15:56] <TabAtkins> szilles: This isn't extensible.
# [15:57] <TabAtkins> fantasai: Right, not extensible to including markup in the future.
# [15:57] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [15:57] <TabAtkins> fantasai: But it's simple (no lookahead), and makes the contents of the tcy only ever be plain text.
# [15:57] <TabAtkins> fantasai: An implication of changing this is that if I have "digits" as the value...
# [15:57] * Joins: kawabata` (~user@public.cloak)
# [15:57] <TabAtkins> fantasai: <tcy>123<q>45</q></tcy>
# [15:57] <dbaron> we can just s/TCY/縦中横/
# [15:58] <TabAtkins> fantasai: The first one wouldn't tcy, the second would. You'd get:
# [15:58] <TabAtkins> 1
# [15:58] <TabAtkins> 2
# [15:58] <TabAtkins> 3
# [15:58] <TabAtkins> 45
# [15:58] <TabAtkins> (with 1/2/3 being rotated)
# [15:59] <TabAtkins> szilles: I don't see what this solves.
# [15:59] <TabAtkins> koji: I think extensibility to markup should be a new value for the tch property in the future.
# [15:59] <TabAtkins> szilles: There's more likelihood of accidental markup than pruposeful markup, and this one is affected by that accidenetal markup.
# [16:00] <TabAtkins> koji: Today it'll fail entirely with accidental markup.
# [16:00] <TabAtkins> szilles: Right, and that's probably a good thing.
# [16:00] <TabAtkins> szilles: You're assuming that the <q> has a meaning in those examples, meaningfully breaking it into 3 units.
# [16:00] <dbaron> s/~15 in favor/~10 in favor/, probably
# [16:01] <TabAtkins> fantasai: Current spec gives up when you see the <q> boundary.
# [16:01] <TabAtkins> szilles: Right. Probably a better default.
# [16:01] <TabAtkins> rossen: The other option was to, if it's all inline, to take it as a single tcy run.
# [16:01] <TabAtkins> rossen: So it'll still fail on blocks
# [16:01] <TabAtkins> rossen: Which I think is reasonable.
# [16:02] <TabAtkins> rossen: I think "all" is pretty explicit and means "I want this whole thing to be combined".
# [16:02] <TabAtkins> rossen: Presumably I know what I'm doing.
# [16:02] <TabAtkins> fantasai: What happens if I have <tcy digits>1234abc</tcy>?
# [16:02] <TabAtkins> fantasai: 1234 is expected to form a tcy.
# [16:03] <TabAtkins> fantasai: But that's combining/breaking in an element.
# [16:03] <TabAtkins> TabAtkins: That's similar to bidi fragments, no? This is a problem we already solve.
# [16:03] <TabAtkins> TabAtkins: (not saying it's a sane problem)
# [16:04] <TabAtkins> koji: We have impls for 2 years, and we found these issues just a few months ago. We already have lots of content using it.
# [16:04] <TabAtkins> koji: So we need something compatible with existing content.
# [16:05] <TabAtkins> rossen: Option C would still work in existing content. TCY together everything that's inline.
# [16:05] <TabAtkins> koji: Can we come up with some spec text?
# [16:05] <TabAtkins> rossen: Yeah.
# [16:06] <TabAtkins> szilles: We already have a notion of "inline content" in the grammar, so the spec can just say that th eocntents must be inline content.
# [16:06] <TabAtkins> koji: ???
# [16:07] <TabAtkins> szilles: You're basically converting a float of max-contnet width, but doing some other things - turning off some variants, etc., maybe do some kernings.
# [16:07] <TabAtkins> szilles: You'll have to specify all that anyway to be consistent with impls.
# [16:07] <TabAtkins> szilles: And if it doesn't fit in an em, scale until it does.
# [16:07] <TabAtkins> szilles: Clearly not ideal, but I'm not sure we have much of a choice.
# [16:08] <TabAtkins> dbaron: I think we do have the choice to do simpler things that don't work in every edge case.
# [16:08] <TabAtkins> szilles: What do you buy? You're using code you already have.
# [16:08] <TabAtkins> dbaron: That's not always simple.
# [16:08] <TabAtkins> fantasai: Rossen and I were discussin gproblems with fragmenting the inlines.
# [16:09] <TabAtkins> fantasai: For example, if you have lgocial properties that you want to cascade and resolve, you can't do that if part of the element is horizontal and some is vertical.
# [16:09] <TabAtkins> fantasai: rossen suggested that you start forming tcy, and if there's an unclosed element at the end, you give up.
# [16:10] <dbaron> fantasai: here you end up with a single fragment that has 2 different writing modes, that's worse than bidi
# [16:11] <TabAtkins> TabAtkins: [doesn't understand why this is different from what happens in bidi fragments, but whatever]
# [16:13] <TabAtkins> [discussion of details]
# [16:13] <Bert> (Does <tcy digits2>abc12de</></> makes "12" horizontal)
# [16:13] <TabAtkins> (given their current suggestion, no - that's two unclosed elements.)
# [16:13] <TabAtkins> (given the earlier suggestion of just using fragments, yes, it would)
# [16:14] <TabAtkins> [more board scribbling and mumbling, too small, fast, and confusing to minute]
# [16:17] * fantasai wonders where jdaggett is
# [16:17] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [16:18] <TabAtkins> fantasai: We did decide we had an issue about "digits" having to check outside its boundaries, to make sure that a run of digits within the element isn't contiguous with a larger run of digits starting outside.
# [16:19] <TabAtkins> israelh: In "abc<tcy>def</tcy>", what would happen?
# [16:20] <TabAtkins> israelh: I mean <tcy>abc</tcy>.
# [16:20] <TabAtkins> rossen: It woudl work - the span would both open and close within the run.
# [16:21] <TabAtkins> fantasai: We were hoping to keep this relatively simple, which is why we had a non-inherited property.
# [16:21] * Quits: kawabata` (~user@public.cloak) (Client closed connection)
# [16:21] <TabAtkins> fantasai: Now it's getting more and more complicated.
# [16:21] <TabAtkins> dbaron: It feels like this is already the complicated appendage to the spec, which is now getting more complex.
# [16:22] <TabAtkins> dbaron: We agreed to stick on this complicated appendage because it was considered essential for some use-cases...
# [16:22] <TabAtkins> dbaron: But do we really need to address every tcy case in this level?
# [16:22] <TabAtkins> szilles: Figuring out which subset to address is where we seem to go aground.
# [16:22] <TabAtkins> fantasai: We started with just plain text...
# [16:22] <TabAtkins> dbaron: And then you said it wasn't enough.
# [16:22] <TabAtkins> koji: I'm fine with plain text with inherited values.
# [16:22] * Joins: jet (~junglecode@public.cloak)
# [16:23] <TabAtkins> koji: But what I just said gives bad results for the a/bc case.
# [16:23] <TabAtkins> israelh: Do you see things like i^12, or whatever?
# [16:23] <dbaron> koji: I see people doing H_2O or CO_2 using horizontal writing mode in an inline-block
# [16:24] <TabAtkins> koji: I do see that, or "CO_2", etc. but you can just use writing-modes and inline-blcok for that.
# [16:24] <TabAtkins> szilles: If I put properties on an inline, do you turn it off?
# [16:24] <TabAtkins> fantasai: You inherit the all, and it takes effect on the inner span, not the outer.
# [16:24] <TabAtkins> szilles: That's no extensible.
# [16:25] <TabAtkins> fantasai: Right. You can use inline-block to do *anything* in tcy, it just doesn't do automatic compression.
# [16:25] <TabAtkins> TabAtkins: Until we do copyfitting, which'll address that.
# [16:25] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [16:25] * Joins: ChrisL (clilley@public.cloak)
# [16:25] <TabAtkins> fantasai: The other solution going forward that koji said, is a new display value "character", which does try to do compression, dots, etc.
# [16:25] <TabAtkins> fantasai: That would let us do everything you want to do with this property.
# [16:26] * Quits: tantek (~tantek@public.cloak) (tantek)
# [16:26] * Quits: ian (~ian@public.cloak) (Ping timeout: 180 seconds)
# [16:26] <TabAtkins> fantasai: This lets us do all the use-cases so far. You can even do CO_2 if you use the unicode subscripts.
# [16:26] <TabAtkins> fantasai: You can use inline-blocks for anything else, and in the future we can get even better.
# [16:26] * Joins: ian (~ian@public.cloak)
# [16:26] <TabAtkins> szilles: I don't like the fact that it's not extendable.
# [16:27] <TabAtkins> koji: We intended to do that. But designing for as simple as possible right now, and don't exclude expansion in the future.
# [16:27] * Joins: kawabata2 (~user@public.cloak)
# [16:27] <TabAtkins> fantasai: ...so new design is inherited property.
# [16:28] <TabAtkins> fantasai: Consistency argument is that "digits" takes a run and looks for continguous characters of a given type.
# [16:28] <TabAtkins> "digits" or "all".
# [16:28] <TabAtkins> fantasai: But only on a text run.
# [16:28] <TabAtkins> fantasai: Consistent.
# [16:28] <TabAtkins> fantasai: "all" is just like digits, but with any character.
# [16:29] <TabAtkins> szilles: It really isn't like that at all. For digits, you dont' need explicit markup; this needs explicit markup.
# [16:29] <TabAtkins> rossen: Right, you normally want to avoid markup. "all" just fills in the holes for things like CO_2.
# [16:30] * Quits: ian (~ian@public.cloak) (Client closed connection)
# [16:30] * Joins: ian (~ian@public.cloak)
# [16:30] <TabAtkins> israelh: To the extent that we keep it consistent with what we ahve right now, it'll be easier to understand. If we go beyond that...
# [16:30] <TabAtkins> israelh: ???
# [16:31] <TabAtkins> israelh: When we go beyond what we can compress in a single line, we've already established that it fails. So it's okay to fail, from an authoring perspective.
# [16:32] <TabAtkins> rossen: So I think we converged to 2 choices.
# [16:32] <TabAtkins> rossen: 1 is to keep inheriting. Break when you see element boundaries.
# [16:32] <TabAtkins> rossen: This'll make most cases that koji says work, and the "digit" value work.
# [16:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [16:33] <dbaron> [howcome just left; Tantek left a few minutes ago]
# [16:33] <TabAtkins> rossen: Simpler to implement, maybe a little more confusing to understand. Potentially not extendable.
# [16:33] <TabAtkins> rossen: 2 is to go for more elaborate combining whee we allow crossing element boundaries.
# [16:33] * Joins: koji (~koji@public.cloak)
# [16:33] <TabAtkins> rossen: But then we need more smarts to think about if there are unclosed elements, etc.
# [16:34] <TabAtkins> rossen: Likely harder to implement. Potentially more understandable to users.
# [16:34] <TabAtkins> rossen: But I"m sure with enough mucking around we can always create some element combinations that fail us.
# [16:35] <TabAtkins> rossen: So it's simple rimplementation but maybe some rarer cases not working, or more complex implementation with some exotic cases working, but we dont' even know if it's the right "working".
# [16:36] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [16:36] <dbaron> fantasai: (1) text-only, inherits
# [16:36] <dbaron> dbaron: are there still multiple variants of (1) ?
# [16:37] <dbaron> fantasai: I have one in my head that I think is good.
# [16:37] <dbaron> fantasai: (2) only inline content (previously C)
# [16:37] * Joins: shepazu (schepers@public.cloak)
# [16:37] <dbaron> fantasai: And (1) is A+D
# [16:38] <TabAtkins> 6 for 1
# [16:38] <dbaron> (fantasai, Rossen, Koji, Florian, dbaron, Tab)
# [16:38] <TabAtkins> 6 for option 1, that is
# [16:38] <dbaron> 2 for option 2 (Israel, SteveZ)
# [16:39] <dbaron> Bert abstains, can't make up his mind
# [16:39] <hober> and many, many abstentions
# [16:39] <dbaron> fantasai: Koji and I will spec up A+D and we'll come back to the group.
# [16:39] <dbaron>
# [16:46] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [16:46] * Joins: darktears (~darktears@public.cloak)
# [16:46] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [16:56] * Joins: koji (~koji@public.cloak)
# [16:59] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [17:03] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [17:04] * Quits: kawabata2 (~user@public.cloak) (Client closed connection)
# [17:04] * Joins: cabanier1 (~cabanier@public.cloak)
# [17:04] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [17:04] * Joins: astearns (~astearns@public.cloak)
# [17:06] <fantasai> RESOLVED: drop digits 1
# [17:06] <fantasai> Topic: Animations
# [17:07] <fantasai> plinss: What's the status with jd?
# [17:07] <fantasai> plinss: We'll return to text if jdaggett appears
# [17:07] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:08] <fantasai> Shane: At F2F in Tokyo, I offered to get back to group wrt implementation progress that we made on the new T&A cascade that we resolved on
# [17:08] <fantasai> dbaron: just got it into the spec this week, though some bugs in that
# [17:08] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [17:08] <fantasai> shane: We don't have any problem with it, don't seem to be any major issues.
# [17:08] <fantasai> Shane: Some questions, though
# [17:08] <fantasai> Shane: One part of implementation that was sub-optimal
# [17:09] <fantasai> Shane: The issue is we've said that when you specify a transition on a property that is inherited and the inherited value is changing due to transitioning, child transition should not start
# [17:09] <fantasai> dbaron: I thought we resolved the opposite
# [17:09] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 180 seconds)
# [17:09] <fantasai> dbaron: My understanding was that we resolved...
# [17:10] <fantasai> dbaron: Resolution I have is
# [17:10] <dbaron> in minutes at http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html
# [17:10] * Joins: ChrisL (clilley@public.cloak)
# [17:10] <dbaron> A, C, D, E from http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html with modified part B
# [17:10] <fantasai> dbaron: Resolved to accept A, C, D, and E from this with a modified part B
# [17:10] <fantasai> dbaron: That's the edits I tried to make this past weekend
# [17:11] <fantasai> dbaron: Part D, I guess, is where I said that, although it falls out of the way I specified part A, or something else
# [17:11] <fantasai> dbaron: Idea there was that if you have an inherited property that's inheriting through a tree and you have multiple places in that tree
# [17:12] <fantasai> dbaron: that specify transitions
# [17:12] <fantasai> dbaron: then you will get all of the transitions
# [17:12] <fantasai> dbaron: It may produce undesirable results, but it's what you asked for
# [17:12] <fantasai> Shane: We're happy with that approach, a lot easier to implement that than suppress child transitions
# [17:12] <fantasai> dbaron: One conclusion from that discussion was to give up on suppressing transitions there
# [17:13] <fantasai> krit: If you have inherit from ?, though tit was already specified from beginnning that we resolved values before staring animations or transitions
# [17:13] <fantasai> krit: We resovled all the inheritance values before we start the transition, so you don't have 'inherit' keyword
# [17:13] <fantasai> dbaron: 'inherit' isn't a computed value, so that's not a problem
# [17:14] <fantasai> Shane: List of 5 questions, don't have to go through those now
# [17:14] <fantasai> dbaron: Anything likely to benefit from discussion
# [17:14] <fantasai> Shane: ??? something events ???
# [17:14] <fantasai> dbaron: When transition events fire?
# [17:15] <fantasai> dbaron: I don't know that we have a resolution on it, but I think it's important that the script that runs as a result of TransitionEnd event run before the Refresh that would have the "no transition running anymore" style data
# [17:15] <fantasai> dbaron: don't do a screen refresh
# [17:15] <fantasai> dbaron: Can't avoid scrip tgetting access to styles
# [17:15] <krit> s/??? something events ???/When do we fire events? Are events asynchronous?/
# [17:15] <fantasai> dbaron: But really want to avoid screen refresh between update to style data and sending TransitionEnd event
# [17:15] <fantasai> Shane: Does a transition end on the screen refrsh that first ...
# [17:15] <fantasai> dbaron: Asking > or >=?
# [17:15] <fantasai> dbaron: I don't think we've actually defined that
# [17:16] <fantasai> Shane: Couple that question with timing statement you just made, then if you were to say that TransitionEnd on the first frame in which the final property value has been displayed, and the transition effect mus tahppenbefroe the next round
# [17:16] <fantasai> dbaron: Final property value is tricky with step transition functions
# [17:16] <fantasai> dbaron: Could we say perhaps that, talk about that hypotehtical transition you'd have if your timing funciton was step-end?
# [17:16] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:17] <fantasai> dbaron: Makes a change only at end of transition
# [17:17] * Joins: ChrisL (clilley@public.cloak)
# [17:17] <fantasai> dbaron: Think that in Gecko we will fire the TransitionEnd event essentially while we're doing the style updates
# [17:17] <fantasai> dbaron: in order to do the refresh for that value
# [17:17] <fantasai> dbaron: If you have a step-end() timing function, and have TransitionEnd on it, and use TransitionEnd to set it to some other value, think you should never see the end value of that transition. I would hope
# [17:18] <fantasai> Shane: No, I think you should
# [17:18] <fantasai> Shane: Otherwise, taking the step-end, if you chain based on TransitionEnd, you'll never see any value until the last transition ends
# [17:18] <fantasai> dbaron: I was using "see" too loosely...
# [17:18] <fantasai> dbaron: We would fire the TransitionEnd event at a point where the script will see the end value, but we haven't yet repainted the screen for that value
# [17:19] <fantasai> dbaron: So if you make another style change right hten, it'll take effect before we do any repaints. Not 100% sure about that
# [17:19] <fantasai> krit: Might be desired in this cas
# [17:19] <fantasai> Shane: If you want to time two animations... to be perfectly smooth, then you... I guess it also ties into whether we consider transitions end-exclusive or not
# [17:19] <fantasai> dbaron: Spec is not very clear on this stuff
# [17:19] <fantasai> dbaron: Not entirely sure on this stuff. Not sure we should make it clear for this version or not.
# [17:20] <fantasai> dbaron: If we figure out something we can agree on
# [17:20] <fantasai> dbaron: Worht writingsome tests for this stuff and seeing what happens
# [17:20] <fantasai> Shane: We would be quit ehappy to not tie these questions down now and wait until WebAnimations spec has been reviewed, and then in the next level of CSS Transitions and Animations, adopt whatever conventions Web Animations has provided
# [17:20] <fantasai> dbaron: I'm certainly ok with waiting
# [17:21] <fantasai> dbaron: Don't necessarily want to commit to waiting for web Animations
# [17:21] <fantasai> hober: right
# [17:21] <fantasai> dbaron: Not all that concerned that this will be a critical issue for interop
# [17:21] <fantasai> Shane: ...
# [17:21] <fantasai> dbaron: It's probably worth seeing how itneroperable things are
# [17:21] <fantasai> dbaron: Definitely had mental model of what boundary conditions are
# [17:21] <fantasai> dbaron: dont' know if that agrees with your model, and spec doesn't have a model
# [17:22] <fantasai> Shane: Web Animations model is ... that a sample only belongs to one animation or another ...
# [17:22] <fantasai> dbaron: That is the model I used in implementing CSS Animations, I abelive.
# [17:22] <fantasai> dbaron: For repeating animations.. though not entirely I think
# [17:23] <fantasai> dbaron: Think what I did for repeating animations, I considered all the repetition cycles, if right at boundary, would use start state of next repetition than end state of lastanimations
# [17:23] <fantasai> dbaron: But for last cycle, would still use value from animation
# [17:23] <fantasai> dbaron: Don't remember if there was a good reason for that
# [17:23] <fantasai> dbaron: Essentially what I did for animations, it included both end points
# [17:23] <fantasai> dbaron: Picked second iteration over first
# [17:23] <fantasai> Shane: Given that model, when do the events fire?
# [17:23] <fantasai> dbaron: At the boundary point
# [17:24] <fantasai> Shane: After style has bene calculated, but before screen refresh?
# [17:24] <fantasai> dbaron: In Gecko only fire events as part of our refresh cycle
# [17:24] <fantasai> dbaron: It would fire after style cacl
# [17:24] <fantasai> dbaron: Would need to look more closely at code to see what changes would take effect in observer
# [17:24] <fantasai> Shane: Does that mean another style updat ecould be trigered?
# [17:25] <fantasai> krit: Looking at SVG animations, it is always end-exclusive.
# [17:25] <fantasai> dbaron: Ok, I will make note to myself to see what happens if we make ours end-excluseive completely, and see what that breaks
# [17:25] <fantasai> krit: A little concerned about that approach
# [17:25] <fantasai> s/krit/Shane/
# [17:25] <fantasai> Shane: If an event fires such that ...
# [17:25] <fantasai> Shane: interrupted, then we can't really do chaining properly
# [17:26] <fantasai> dbaron: if an event fires when?
# [17:26] <fantasai> Shane: ...
# [17:26] <fantasai> Shane: step-end
# [17:26] <fantasai> Shane: no change, no change, no change, then jump
# [17:26] * Joins: dino (~dino@public.cloak)
# [17:26] <fantasai> Shane: nevermind
# [17:26] * hober waves to dino
# [17:27] * dino waves from Texas!
# [17:27] * Joins: florian (~Adium@public.cloak)
# [17:27] * Quits: florian1 (~Adium@public.cloak) (Client closed connection)
# [17:27] * glazou texas ?!?
# [17:27] * dino Texas forever.
# [17:28] <TabAtkins> Shane: We currently coalesnce iteration events if there are multiple between frames.
# [17:28] * Joins: koji_ (~koji@public.cloak)
# [17:28] <TabAtkins> Shane: You okay with that behavior?
# [17:29] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [17:29] <krit> ScribeNick: krit
# [17:29] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [17:29] <krit> dbaron: as implementer I would not really care
# [17:29] <krit> dbaron: maybe we can discuss over email
# [17:29] <krit> shans: sure
# [17:30] <krit> shans: one other thing
# [17:30] <krit> shans: provide a negative animation delay and pause
# [17:30] * Joins: michou (~mibalan@public.cloak)
# [17:30] <krit> shans: so that we can hit particular points and test these
# [17:30] <krit> shans: I think we can build a nice conformance suite
# [17:30] <krit> shans: think Gecko passes our test suite
# [17:31] <krit> shans: is there anything missing that we should test?
# [17:33] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [17:33] <dbaron> Topic: text
# [17:33] <dbaron> fantasai: text-align and text-align-last; last issue on text-combine-horizontal (if we have a better name)
# [17:33] <dbaron> ScribeNick: dbaron
# [17:34] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [17:34] <dbaron> fantasai: issue is interaction of text-align and text-align-last, and whether one should be a shorthand of the othe
# [17:34] <dbaron> Bert: and whether there should be a text-align-first
# [17:34] * Quits: florian (~Adium@public.cloak) (Client closed connection)
# [17:34] * Joins: michou (~mibalan@public.cloak)
# [17:34] <dbaron> fantasai: or could just have 2 properties (text-align-all and text-align-last) and all can take 2 values to say what the first line should do, but I don't have a strong opinion on that
# [17:34] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [17:34] <dbaron> fantasai: I think we've discussed this a couple of times, don't have a super good answer.
# [17:35] * astearns just realizes the legal cannabis shops may be ready in time for the Seattle conference
# [17:35] <dbaron> fantasai: the main difference in behavior is if you set 'text-align: justify; text-align-last: justify' and then later in the cascade want a particular paragraph to be 'text-align: center', the last line will stilll end up being justified.
# [17:36] <dbaron> fantasai: Then could do what IE does, text-align-last only takes effect when have text-align:justify
# [17:36] <dbaron> fantasai: if you go from center back to justify, then the first text-align-last is still taking effect. Do you want that, or do you want these text-align declarations to clear out the first one?
# [17:36] <dbaron> fantasai: That's the main interaction issue.
# [17:37] <dbaron> fantasai: There's also -- jdaggett wanted to be able to specify text-align: justify-all and have that just work instead of having text-align-last
# [17:37] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [17:37] * Joins: yamamoto_ (~yamamoto@public.cloak)
# [17:37] <dbaron> fantasai: but for back compat we still need text-align-last
# [17:37] <dbaron> fantasai: so if we want to make this work we need it connected -- a shorthand
# [17:37] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [17:37] <ChrisL> zakim, enough with the hand fetish already
# [17:37] <Zakim> I don't understand 'enough with the hand fetish already', ChrisL
# [17:37] * Quits: koji_ (~koji@public.cloak) (Ping timeout: 180 seconds)
# [17:37] * Joins: krit1 (~krit@public.cloak)
# [17:37] <dbaron> fantasai: last consideration: somebody on the mailing list wanted to say last line alignment matches the rest, without caring what it is
# [17:38] * Quits: krit (~krit@public.cloak) (Ping timeout: 180 seconds)
# [17:38] <dbaron> fantasai: if you want justify-all to work it needs to be a shorthand; if you want ability to explicitly defer last to match others, it needs to not be a shorthand
# [17:38] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [17:38] <dbaron> Bert: if we have just one property, just text-align, and no text-align-last
# [17:38] <ChrisL> zakim, who is here?
# [17:38] <Zakim> sorry, ChrisL, I don't know what conference this is
# [17:38] <Zakim> On IRC I see krit1, yamamoto_, michou, dino, ChrisL, Rossen_, astearns, cabanier1, darktears, ian, jet, teoli, shans__, tobie, plh, darobin, liam, leif, oyvind, glazou, dbaron,
# [17:38] <Zakim> ... Zakim, projector, GPHemsley, krijnh, gsnedders, dauwhe, RRSAgent, renoirb
# [17:38] * Joins: koji (~koji@public.cloak)
# [17:38] <ChrisL> zakim, bye
# [17:38] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [17:38] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:38] * Joins: ChrisL (clilley@public.cloak)
# [17:39] <dbaron> fantasai: we have back compat issue because people are using text-align-last. In IE6, and old CR.
# [17:39] <dbaron> Rossen: at least
# [17:39] * Joins: kawabata (~user@public.cloak)
# [17:39] <dbaron> fantasai: We know MS is going to continue to implement text-align-last, but seems like we're not going to have the shorthand option.
# [17:39] <dbaron> fantasai: ... if we want to be compatible with ???
# [17:39] <dbaron> fantasai: Have 2 implementations, Microsoft and Mozilla.
# [17:39] <dbaron> Bert: Seems like what IE is doing is the best, just honoring last when text-align is justify
# [17:40] <dbaron> Rossen: what word also supports
# [17:40] <dbaron> ChrisL: Put it in the "Applies To" line
# [17:40] <dbaron> fantasai: thought word used something else
# [17:40] <dbaron> Alan, Rossen: Word gives you the option, only applies to the last line if justified
# [17:40] <ChrisL> applies to the last line of elements where text-align has the value justify
# [17:41] <dbaron> fantasai: considerations are: cascading behavior - both solutions handle 'text-align: center' overriding -- but if elsewhere set text-align:justify does it resurrect the old text-align-last?
# [17:42] <dbaron> fantasai: Can't have justify-all value vs. can't have value for matching the rest
# [17:42] <dbaron> fantasai: and expectation of shorthand behavior from property names
# [17:42] <dbaron> fantasai: Comments?
# [17:42] <dbaron> Tab: no opinion
# [17:43] <dbaron> fantasai: if we add first line justification, then it would probably be a keyword on text-align
# [17:43] * ChrisL suspects room energy has passed below the required minimal levels
# [17:43] <glazou> <csswg type="brain-speed: slow;"/>
# [17:43] <astearns> I'm for option B - text-align-last only applies if text-align is justify
# [17:43] <dbaron> fantasai: if text-align-last is not shorthanded we probably wouldn't do a text-align-first property because it would have horrible cascading (and if we had a shorthand they should both be in the shorthand)
# [17:44] <dbaron> fantasai: Bert and jdaggett prefer not having text-align-last and just using text-align for everything
# [17:44] <dbaron> fantasai: that would have been better
# [17:44] <dbaron> peterl: can we deprecate text-align-last?
# [17:44] <dbaron> Bert: maybe I'm inconsistent, but in this case...
# [17:45] <dbaron> Bert: but I don't think we should do that; it's been in a CR. One of those mistakes we make once in a while.
# [17:45] <dbaron> peterl: I'm not saying take out of spec; leave it in spec and mark as deprecated.
# [17:45] * Joins: cabanier (~cabanier@public.cloak)
# [17:45] * Quits: cabanier1 (~cabanier@public.cloak) (Client closed connection)
# [17:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [17:46] <dbaron> ?: have a use case for ??? ?
# [17:46] <Bert> s/???/text-align-last with anything else than text-align: justify/
# [17:47] <dbaron> fantasai: I don't have a strong opinion right now, although before I was pretty convinced we should do the shorthanding.
# [17:48] <dbaron> peterl: I'm not happy about the legacy issue, but that's life.
# [17:48] <dbaron> alan: Since we don't have a ??? use case for doing the right thing, but we don't have anything ???. Leave it as it is with MS's behavior until somebody gives us a reason to make a change?
# [17:48] <dbaron> peterl: Will need to change if we want text-align-first, would make sense to have shorthand.
# [17:48] <dbaron> Alan: planning to do that now?
# [17:48] <dbaron> peterl: no, but should at some point
# [17:49] * Joins: cabanier (~cabanier@public.cloak)
# [17:49] <dbaron> [nobody seems to feel strongly]
# [17:49] <dbaron> ?: defer to jdaggett?
# [17:50] <dbaron> Rossen: when we discussed this a couple months back, the query we did over roughly 2 million documents came back with ... something between 3-5% used text-align-last.
# [17:50] * Joins: kawabata` (~user@public.cloak)
# [17:50] <dbaron> peterl: any tests for value of the property, or just presence?
# [17:51] <dbaron> Rossen: I don't remember how I wrote the query... maybe checking for value other than inherit.
# [17:51] <dbaron> peterl: so included some cases where value had no real effect
# [17:51] <dbaron> Rossen: I think so.
# [17:51] <dbaron> Rossen: wanted to see if <1%
# [17:52] <dbaron> peterl: but could also potentially drop if most were setting to initial value or something that has no effect
# [17:52] <dbaron> peterl: if no strong opinions, leave as is?
# [17:52] <dbaron> dbaron: how is it?
# [17:52] <dbaron> fantasai: spec says totally independent properties
# [17:52] <dbaron> peterl: what does Gecko do
# [17:52] <dbaron> fantasai: completely independent
# [17:52] <dbaron> fantasai: AntennaHouse also implements
# [17:53] * Joins: astearns_ (~astearns@public.cloak)
# [17:53] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [17:53] <dbaron> fantasai: Spec the IE behavior, and if somebody prefers shorthand they can raise an LC comment and explain why.
# [17:54] <dbaron> RESOLVED: spec the dependence of text-align-last on text-align:justify and mark issue for feedback on shorthanding vs. not
# [17:54] * oyvind re animations tests, there are some old ones in opera incoming/ that I didn't get around to inserting the spec reference links into yet
# [17:54] <dbaron> fantasai: I'm out of issues on css3-text.
# [17:55] <dbaron> Bert: can we add the poetry behavior keywords to text-align: first-left first-right
# [17:55] * Quits: oyvind (~oyvinds@public.cloak) ("gtg")
# [17:55] <dbaron> fantasai: A little concerned about doing that ... I'd do it as start-first.
# [17:55] <dbaron> Bert: Too difficult for users.
# [17:55] <dbaron> fantasai: Always correct.
# [17:56] <dbaron> fantasai: The only use case is start-first
# [17:56] <dbaron> fantasai: I think it's obvious
# [17:56] <dbaron> Bert: those are words only people in the WG understand.
# [17:56] <dbaron> Bert: maybe 'poetry', not 'start end'
# [17:57] <dbaron> Koji: If people don't understand 'start end' then we need to discuss
# [17:57] <dbaron> Florian: ... Beating them looks hard.
# [17:57] <dbaron> Bert: I'm not sure if it's only based on the direction. If that's indeed the case than a single keyword would be enough.
# [17:57] <dbaron> fantasai: Actually, 2 things I want to drop from the spec currently:
# [17:57] <dbaron> fantasai: (1) 'text-align: start end'
# [17:58] <dbaron> fantasai: (2) word-spacing can take up to 3 values defining minimum optimum maximum; don't have any implementations and would prefer to drop and figure out justification limits in level 4
# [17:58] <dbaron> Bert: do we want to have limits or do we want to allow other algorithms as well?
# [17:58] <dbaron> Bert: I'm ok with dropping it, not sure we should add it back in afterwards.
# [17:58] <dbaron> fantasai: I think we should drop it until we have a clear idea what we want for that.
# [17:58] <dbaron> Koji: seems like consensus to drop
# [17:59] <dbaron> RESOLVED: drop minimum/optimum/maximum values for word-spacing
# [17:59] <dbaron> Bert: not sure about dropping 'start end' value from text-align
# [17:59] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:59] * Joins: ChrisL (clilley@public.cloak)
# [18:00] <dbaron> fantasai: Main reason I want to drop is not because I don't want to handle poetry case, but because I want to figure out clearest syntax.
# [18:00] <dbaron> fantasai: This is just putting two keywords, not super-obvious what that means.
# [18:00] <dbaron> fantasai: maybe it makes sense to have some other keyword to express that
# [18:00] <dbaron> Bert: I'd like it to be a single keyword, not two keywords.
# [18:00] <dbaron> Bert: 'poetry' would work for me
# [18:00] * Joins: lmclister (~lmclister@public.cloak)
# [18:00] <dbaron> fantasai: I think that's too specific; I might use it for code
# [18:00] <dbaron> [discussion]
# [18:01] <dbaron> fantasai: Poetry in general not aligned like that.
# [18:01] <dbaron> peterl: Maybe research to see if there's a name for that?
# [18:01] <dbaron> fantasai: Want to drop largely because don't have good syntax for it that's obvious.
# [18:01] <dbaron> Bert: two-sided, continuation?
# [18:02] <dbaron> Alan: any implementations?
# [18:02] <dbaron> fantasai: no
# [18:02] <dbaron> Alan: I think we should drop it.
# [18:02] <dbaron> Peterl: trying to go to last call soon
# [18:02] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [18:02] <dbaron> fantasai: unless there are objections
# [18:02] * Joins: ChrisL (clilley@public.cloak)
# [18:02] <dbaron> peterl: not alone a reason to drop because not implemented -- could mark at risk
# [18:02] <Bert> (I think alan was talking about min and max on word-spacing, wasn't he?)
# [18:03] <dbaron> Alan: to play devil's advocate, ...
# [18:03] <dbaron> peterl: keep in, put issue about naming, mark at risk?
# [18:03] <astearns_> bert: I was talking about dropping the poetry thing
# [18:03] <dbaron> fantasai: "this needs to be renamed at last call or it gets dropped"
# [18:03] <dbaron> Bert: At some point I want the feature that inserts an > on every line but the first.
# [18:04] <dbaron> fantasai: I want to check with jdaggett, and check with him on text-align stuff.
# [18:04] <dbaron> fantasai: so I will make edits and do the write-up and if people here are happy w/ it we can go to LC unless jdaggett wants more changes
# [18:04] <Bert> (left square bracket is actually more likely than angle bracket)
# [18:04] <dbaron> RESOLVED: keep 'text-align: start end' in, add an issue about naming, and mark it at risk
# [18:05] * Quits: kawabata` (~user@public.cloak) ("ERC Version 5.3 (IRC client for Emacs)")
# [18:05] <dbaron> peterl: do we want to resolve for LC now, or wait for edits and jdaggett's feedback?
# [18:05] <dbaron> fantasai: Would prefer resolution, even if it takes another cycle, so we can publish if things are ok.
# [18:06] * Joins: bata (~kawabata@public.cloak)
# [18:06] <dbaron> RESOLVED: take css3-text to last call pending resolving issues from jdaggett
# [18:08] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:08] <dbaron> fantasai: open issues on writing modes?
# [18:08] <dbaron> Koji: text-combine-horizontal naming only
# [18:09] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [18:09] * Joins: ChrisL (clilley@public.cloak)
# [18:09] <dbaron> fantasai: Plan is for writing modes to go to last call once we have all the edits done.
# [18:09] <dbaron> Topic: writing modes
# [18:09] <dbaron> peterl: any concerns with that?
# [18:09] <dbaron> florian: maybe not the last last call?
# [18:10] <dbaron> hober: but we want the feedback, thus ok with doing it now
# [18:11] <dbaron> peterl: are people comfortable going to LC without seeing edits?
# [18:11] <dbaron> RESOLVED: css3-writing-modes to Last Call when edits agreed in this meeting are completed
# [18:11] <dbaron> fantasai: I'll post to www-style with the edits so people can look and give a week or so, and then publish.
# [18:11] <dbaron> peterl: Meeting closed.
# [18:11] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:12] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [18:12] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [18:12] * Joins: ChrisL (clilley@public.cloak)
# [18:12] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [18:13] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:13] * Quits: astearns_ (~astearns@public.cloak) (Client closed connection)
# [18:14] * Quits: yamamoto_ (~yamamoto@public.cloak) ("Page closed")
# [18:14] * Quits: dino (~dino@public.cloak) (dino)
# [18:16] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [18:17] * Quits: michou (~mibalan@public.cloak) ("Leaving.")
# [18:18] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [18:19] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [18:20] * Quits: projector (~projector@public.cloak) ("Page closed")
# [18:23] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [18:26] <Zakim> projector, you asked to be reminded at this time to go home
# [18:34] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
# [18:48] * Joins: rhauck (~Adium@public.cloak)
# [18:53] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [18:55] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:55] * Quits: Rossen_ (~Rossen@public.cloak) ("")
# [19:00] * Quits: kawabata (~user@public.cloak) (Ping timeout: 180 seconds)
# [19:00] * Quits: bata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [19:04] * Joins: shans__ (~shans_@public.cloak)
# [19:06] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [19:08] * Joins: myakura (~myakura@public.cloak)
# [19:11] * Quits: ian (~ian@public.cloak) (Client closed connection)
# [19:12] * Quits: tobie (tobie@public.cloak)
# [19:16] * Joins: cabanier (~cabanier@public.cloak)
# [19:26] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [19:29] * Joins: glazou (~glazou@public.cloak)
# [19:35] * Quits: glazou (~glazou@public.cloak) (glazou)
# [19:39] * Joins: jet (~junglecode@public.cloak)
# [19:59] * Joins: liam (liam@public.cloak)
# [20:01] * Quits: jet (~junglecode@public.cloak) (jet)
# [20:12] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [20:15] * Joins: teoli (~teoli@public.cloak)
# [20:30] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [20:36] * Quits: lmclister (~lmclister@public.cloak) ("")
# [20:57] * Joins: teoli (~teoli@public.cloak)
# [21:03] * Joins: lmclister (~lmclister@public.cloak)
# [21:21] * Joins: tobie (tobie@public.cloak)
# [21:23] * Quits: tobie (tobie@public.cloak)
# [21:47] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [21:50] * Joins: krit (~krit@public.cloak)
# [21:59] * Joins: krit1 (~krit@public.cloak)
# [22:04] * Quits: krit (~krit@public.cloak) (Ping timeout: 180 seconds)
# [22:10] * Joins: leif (~lastorset@public.cloak)
# [22:18] * Joins: leif1 (~lastorset@public.cloak)
# [22:18] * Quits: krit1 (~krit@public.cloak) (Client closed connection)
# [22:19] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [22:26] * Joins: krit (~krit@public.cloak)
# [22:31] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [22:31] * Joins: leif (~lastorset@public.cloak)
# [22:39] * Joins: leif1 (~lastorset@public.cloak)
# [22:39] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [22:39] * Joins: rhauck1 (~Adium@public.cloak)
# [22:41] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [22:41] * Joins: leif (~lastorset@public.cloak)
# [22:45] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [22:46] * Joins: leif1 (~lastorset@public.cloak)
# [22:47] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [22:48] * Quits: darktears (~darktears@public.cloak) ("Linkinus - http://linkinus.com")
# [22:56] * Joins: shans__ (~shans_@public.cloak)
# [22:59] * Joins: leif (~lastorset@public.cloak)
# [22:59] * Quits: leif1 (~lastorset@public.cloak) (Client closed connection)
# [23:02] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:04] * Joins: teoli (~teoli@public.cloak)
# [23:04] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [23:09] * Joins: teoli_ (~teoli@public.cloak)
# [23:09] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:13] * Joins: jet (~junglecode@public.cloak)
# [23:14] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:16] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [23:22] * Joins: tobie (tobie@public.cloak)
# [23:23] * Parts: leif (~lastorset@public.cloak) (leif)
# [23:45] * Quits: jet (~junglecode@public.cloak) (jet)
# Session Close: Sat Sep 14 00:00:00 2013

The end :)