/irc-logs / w3c / #css / 2014-05-21 / end

Options:

  1. # Session Start: Wed May 21 00:00:00 2014
  2. # Session Ident: #css
  3. # [00:03] * Joins: rhauck (~Adium@public.cloak)
  4. # [00:23] * Joins: dauwhe (~dauwhe@public.cloak)
  5. # [00:28] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  6. # [00:58] * Joins: rhauck1 (~Adium@public.cloak)
  7. # [01:03] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
  8. # [01:36] * Joins: jdaggett (~jdaggett@public.cloak)
  9. # [01:43] * Joins: Shinsuke (~Shinsuke@public.cloak)
  10. # [01:45] * Quits: tantek (~tantek@public.cloak) (tantek)
  11. # [01:52] * Joins: dauwhe (~dauwhe@public.cloak)
  12. # [01:54] * Joins: dwim (~uid10661@public.cloak)
  13. # [01:56] * Joins: dael (~dael@public.cloak)
  14. # [01:59] * Quits: lmclister (~lmclister@public.cloak) ("")
  15. # [02:00] * Joins: SteveZ (~SteveZ@public.cloak)
  16. # [02:01] * Joins: shans_ (~shans@public.cloak)
  17. # [02:01] * Joins: glazou (~glazou@public.cloak)
  18. # [02:02] <glazou> https://attendee.gotowebinar.com/register/5412617925660825345
  19. # [02:02] * plinss changes topic to 'http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345'
  20. # [02:02] * plinss changes topic to 'http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345'
  21. # [02:04] * Joins: andrey (~andrey@public.cloak)
  22. # [02:04] * Joins: murakami (~murakami@public.cloak)
  23. # [02:06] * Joins: jh_hong (~jh_hong@public.cloak)
  24. # [02:15] * Joins: dbaron (~dbaron@public.cloak)
  25. # [02:15] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
  26. # [02:15] <dael> glaz: Let's start
  27. # [02:15] * liam mutes too (thanks for unmuting)
  28. # [02:16] <dael> glaz: WE have krit calling in and the first is CSS masking
  29. # [02:16] * Joins: clilley (~clilley@public.cloak)
  30. # [02:16] <krit> http://dev.w3.org/fxtf/css-masking-1/#masking
  31. # [02:16] <dael> krit: CSS Masking had some changes since last WD one was that we now have posistion masking support
  32. # [02:16] <krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite
  33. # [02:16] <dael> krit: To make this possible it was an issue how to combine diff mask layers and I introduced mask composite prop
  34. # [02:17] * Joins: abinader (~sid21713@public.cloak)
  35. # [02:17] <dael> krit: Which is using composite operators to make it easier to use instead of using whole composite mode
  36. # [02:17] <dael> krit: The mask-source-type which needed to be renamed to mask-type
  37. # [02:17] <dael> krit: Therefore it all needs to be renamed since webkit and Blink are shipping
  38. # [02:17] <dael> krit: I've called it mask-operation
  39. # [02:18] <dael> krit: mask-type is mask-operation and mask-box-type is mask-box-operation
  40. # [02:18] <dael> krit: No change requests in 2 weeks, so is it possible to pub a new LC?
  41. # [02:18] <dael> krit: It might be last LC
  42. # [02:18] <dael> glaz: Thoughts?
  43. # [02:18] <dael> fantasai: Thre was one issue that was raised with layers about grouping the operations and combining the images and the reason we defered we didn't know how to do syntax to do properties.
  44. # [02:19] * Joins: Rossen_ (~Rossen@public.cloak)
  45. # [02:19] <dael> fantasai: [missed]
  46. # [02:20] <dael> krit: Grouping isn't important at the moment but is interesting. We can think about that at backgrounds and borders, but for now I think we're fine with not having grouping
  47. # [02:20] <dael> krit: We can introduce it in backgrounds and borders.
  48. # [02:20] <dael> TabAtkins: I'm fine with that. Whatever solution is in B&B will be fine
  49. # [02:20] <dael> fantasai: If we do an expression language that will be different from ones that map.
  50. # [02:20] <dael> TabAtkins: And in the future we can have both.
  51. # [02:20] <dael> krit: Any other requests or can we go to LC?
  52. # [02:21] <dael> glaz: Comments?
  53. # [02:21] * Joins: adenilson (~anonymous@public.cloak)
  54. # [02:21] <dael> glaz: TabAtkins is fine, I'm fine, clilley, Rossen_
  55. # [02:21] <dael> RESOLVED: LC for CSS Masking
  56. # [02:21] <dael> clilley: Can you get the doc ready today so I can req pub on thursday?
  57. # [02:21] <dael> krit: Next week?
  58. # [02:21] <dael> clilley: This week
  59. # [02:21] <dael> krit: Sure.
  60. # [02:21] <dael> krit: Do you think you can get it on Thursday?
  61. # [02:22] <dael> clilley: Yeah. As long as it's ready we can pub on Thursday.
  62. # [02:22] <dael> krit: Yeah
  63. # [02:22] <dael> fantasai: What was the mask type change?
  64. # [02:22] <fantasai> fantasai: is it in the ED yet?
  65. # [02:22] <dael> krit: For some reason it wasn't input. I looked online and all that's missing is the change from mask-source-type
  66. # [02:22] * Joins: plh (~plh@public.cloak)
  67. # [02:22] <dael> krit: And the mask-mode
  68. # [02:22] <dael> krit: And mask-box-layout
  69. # [02:23] <dael> krit: I'm not sure if I put it on the wrong branch, but it needs to be changed first
  70. # [02:23] <dael> fantasai: Is there a clearer name than mask-mode?
  71. # [02:23] <dael> TabAtkins: That's what we used in SVG and I can't come up with better.
  72. # [02:23] <dael> fantasai: Okay.
  73. # [02:23] <dael> fantasai: Where is it in SVG?
  74. # [02:23] <dael> TabAtkins: Mask element
  75. # [02:23] <dael> clilley: So you can't rename it
  76. # [02:23] <dael> fantasai: I'm happy if it matches something
  77. # [02:24] <dael> fantasai: It's otherwise very vague but...
  78. # [02:24] <dael> krit: So you're fine with mask-mode?
  79. # [02:24] <dael> fantasai: If it matches SVG yes
  80. # [02:24] <dael> krit: There isn't in mask-mode, it was interduced in SVG
  81. # [02:24] <dael> TabAtkins: There's an attribute. There's a same named thing so there's consisstancy
  82. # [02:24] <dael> krit: We use mode quite often. That's true.
  83. # [02:25] <dael> krit: Any better suggestions or is it fine?
  84. # [02:25] <dael> fantasai: Were is mode? I was looking at masking module
  85. # [02:25] <krit> http://dev.w3.org/fxtf/filters/
  86. # [02:25] <dael> krit: It is in the spec linked above. There's a lot of use of mode.
  87. # [02:25] <dael> krit: Composate operator
  88. # [02:25] <dael> fantasai: If it means the same thing, but it doesn't?
  89. # [02:26] <dael> fantasai: It's used for blending, not mask interpretation.
  90. # [02:26] <dael> krit: True.
  91. # [02:26] <dael> fantasai: And Masking will need blend modes at some point?
  92. # [02:26] <dael> krit: No.
  93. # [02:26] <dael> clilley: He's arguing we use mode for that sort of thing
  94. # [02:26] <dael> fantasai: Are we going to add blending modes to masking?
  95. # [02:26] <dael> krit: For background it's called background-blend-mode so it's explicit
  96. # [02:26] <dael> astearns: If we do we can call them blenders.
  97. # [02:27] <dael> TabAtkins: Which is clear at that point.
  98. # [02:27] <astearns> s/blenders/blendmodes/
  99. # [02:27] <dael> fantasai: The blend mode is clear.
  100. # [02:27] * astearns though I do like blenders
  101. # [02:27] <dael> fantasai: Okay. I'm not happy it matches something else, but I don't have a better idea.
  102. # [02:27] <dael> fantasai: If it concept matched that would be awesome
  103. # [02:27] <dael> clilley: Do we have a better name or can we move on?
  104. # [02:27] <dael> fantasai: We can move on
  105. # [02:28] <dael> krit: The next one?
  106. # [02:28] <dael> glaz: That's all for masking? Okay.
  107. # [02:28] <dael> Topic: Geometry Interfaces
  108. # [02:28] <krit> http://dev.w3.org/fxtf/geometry/
  109. # [02:28] <dael> krit: We worked on the geometry interface with is the dom-point dom-matrix etc that we had in different pub before.
  110. # [02:28] <fantasai> s/awesome/matching a different concept is less awesome/
  111. # [02:29] <dael> krit: They had been in CSSOM view and this is combination of the interface that we actually use in OM and SVG
  112. # [02:29] <dael> krit: There have been some slight changes to DomMatrix.
  113. # [02:29] <krit> http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity
  114. # [02:29] * fantasai doesn't like "mode" or "type" in property names because they're semantic no-ops
  115. # [02:29] <dael> krit: There had been long discussions on the ML and I added ident to the dom matrix interface that checks if the matrix is an identity transformer
  116. # [02:29] <dael> krit: There are some issue
  117. # [02:29] <krit> http://dev.w3.org/fxtf/geometry/#issue-5712ca41
  118. # [02:30] <dael> krit: One is for the DOMMatrix constructor. One issue I'd like to resolve is issue 2 (link)
  119. # [02:30] <dael> krit: This is where DOM Matrix takes a string that can be a translater.
  120. # [02:30] * fantasai the only thing they express is "i take an enumerated type"
  121. # [02:30] <glazou> krit: your document lacks a normative reference to WebIDL please
  122. # [02:30] <dael> krit: The translation y ou can use in CSS can be passed into the string because you can pass the start and generate the DOM Matrix
  123. # [02:30] * Quits: plh (~plh@public.cloak) ("Page closed")
  124. # [02:30] <dael> krit: SCG uses the transform attr and it has less restrictions. It doesn't req units
  125. # [02:31] <dbaron> s/SCG/SVG/
  126. # [02:31] <dael> krit: In SVG we have the transform attr and it has less rest. It doesn't req unit and it has white spaces between function name and the breaks.
  127. # [02:31] <dael> krit: I would suggest that we allow transform attr syntax here.
  128. # [02:31] <dael> krit: It allows CSS syntax and SVG syntax
  129. # [02:32] <TabAtkins> s/breaks/braces/
  130. # [02:32] <dael> krit: The SVG syntax wll be along for a long time and use of SVG syntax would allow CSS syntax to work. The SVG group wanted approval from CSS
  131. # [02:32] <dael> TabAtkins: I'm fine with unitless, but I don't like the let's have it be an ident plus paran
  132. # [02:32] * Joins: plh (~plh@public.cloak)
  133. # [02:32] <dael> TabAtkins: It's a strange artifact and doesn't nee to be maintained
  134. # [02:32] <dael> krit: I haven't seen it but it's in theory allowed
  135. # [02:33] <dael> TabAtkins: I don't think we need to spread that aspect further, but unitless if fine
  136. # [02:33] <dael> krit: We would need a third syntax. It creats a string from trnasform and passes to Matrix
  137. # [02:33] <dael> TabAtkins: And if you're not weirf it'll work
  138. # [02:33] <dael> krit: I don't think that it's a good idea to have a thurd syntax
  139. # [02:34] <dael> TabAtkins: It's only 3rd because it accepts the unitless SG thing when CSS ingeneral doesn't do that. That's the only seperation and I don't think that's sig. difference
  140. # [02:34] <dael> krit: User agents have to impl three diff for very little gain
  141. # [02:34] <dael> krit: It gets you closer to CSS without whitespaces
  142. # [02:34] * fantasai agrees in not having a 3rd syntax
  143. # [02:34] <dael> krit: I'm not sure if that ain is good enough
  144. # [02:34] <dael> TabAtkins: Whenever you do the unitless is that intp as px?
  145. # [02:34] <dael> krit: yes.
  146. # [02:35] <dael> TabAtkins: So it's accepting the wierd or req to use pix, I'm fine with sticking to CSS, but don't see a reason. If we have to do one or another, I want CSS.
  147. # [02:35] <dael> clilley: Unitless doesn't mean px always
  148. # [02:35] <dael> TabAtkins: But it has to be understandable.
  149. # [02:35] * glazou hi SteveZ ; do you want me to unmute you?
  150. # [02:35] <dael> clilley: If I do 0.3 by 0.3 it can be huge.
  151. # [02:35] <dael> krit: If clilley Is talking about user units, it's always 1 px
  152. # [02:35] <dael> clilley: No it's not
  153. # [02:36] <dael> krit: It is
  154. # [02:36] <dael> krit: It means 1px sn't always 1pixel when it's transform
  155. # [02:36] <dael> krit: It depends on what you mean.
  156. # [02:37] <dael> clilley: So 1px can be 3000 divice pixals. Most people if they say the want a 1px font they don't expect huge. Forcing people to write px isn't useful. For a lot of content people that aren't used to scalable, they set to fixed and use px, but that's the only way
  157. # [02:37] <dael> krit: I agree on the behviour. Do we want CSS, SVG, or a mix
  158. # [02:37] <dael> clilley: Does mix mean the superset?
  159. # [02:37] <dael> krit: SVG is the superset
  160. # [02:37] <dael> TabAtkins: CSS syntax that accepts numbers that are interp as px units
  161. # [02:38] <dael> krit: How would you do with having CSS syntax w/o units
  162. # [02:38] <dael> TabAtkins: Have them set numbers that are interp as pixal units.
  163. # [02:38] <dael> krit: Um.
  164. # [02:38] <clilley> s/the only/not the only/
  165. # [02:38] <dael> krit: I hope we can get rid of whitespace in SVG. I didn't see the behviour in use so maybe it's fine, but in this case I'd change SCG transform syntax.
  166. # [02:39] <dael> krit: I'm fine with keeping this issue open unit SVG transform is resolved
  167. # [02:39] <dael> krit: I'd like to pub a FPWD with these issues and we can compare.
  168. # [02:39] <dael> TabAtkins: absolutely publish, yeah.
  169. # [02:39] <dael> glaz: Other op?
  170. # [02:39] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
  171. # [02:39] <dael> RESOLVED: Publish FPWD
  172. # [02:39] <dael> clilley: plh, canw e pub FPWD?
  173. # [02:40] <dael> plh: Yes.
  174. # [02:40] <dael> plinss: I q. In shenshen we got a bunch of feedback that isn't in here. Is that rejected, not considered?
  175. # [02:40] <dbaron> s/feedback/feedback from Alex Russell/
  176. # [02:40] * Joins: koji (~koji@public.cloak)
  177. # [02:40] <dbaron> s/shenshen/Shenzhen/
  178. # [02:40] <dael> krit: So waht about Alex Russell?
  179. # [02:40] <dael> krit: I tried to ping him and he didn't respond?
  180. # [02:41] <dael> clilley: What was the subs. of your ping?
  181. # [02:41] <dael> krit: I summerized the promises we have in CSS WG with the interface and he was suggesting growth instead of new itnerface. I asked him to comment on the ML and summerize his opinion and that from others. He didn't respond or comment on the ML
  182. # [02:41] <dael> plinss: I'll follow up with him.
  183. # [02:41] <dael> krit: I talked with Mozilla and he feels we should have the new interface.
  184. # [02:42] <dael> plinss: Okay
  185. # [02:42] <dael> glaz: So are we done with this topic?
  186. # [02:42] <dael> krit: Yeah.
  187. # [02:42] <dael> Topic: Test Results Script
  188. # [02:43] <dael> clilley: I was winching with our web and communications team where they wanted us to take outthe paragraph markers. We got to leave them, but I compained about taking out this script that gave a nice summary of the test suite
  189. # [02:43] <dael> clilley: Without it the pages aren't as useful and the reaction was surprising positive. I went a few rounds of what we would need to keep this and one was accessability and I proved this doens't interfear with that
  190. # [02:43] <dael> clilley: The next was does this make the doc non archiaval. I said no.
  191. # [02:44] <dael> clilley: And can you jsut inline the results, no because we want it to be in real time.
  192. # [02:44] <dael> clilley: The one sticking point is that the script isn't hosted at w3c.org
  193. # [02:44] <dael> clilley: I said I'd talk about this. Since then someone popped up witha bunch of hand waving where it would let the data live where it does and the script can be on w3c.org
  194. # [02:45] <dael> plinss: It's fine by me, it makes it harder if I update the script, but that's okay.
  195. # [02:45] <dael> clilley: Will you update in a way that breakst he API?
  196. # [02:45] <dael> plinss: I wrote it a long time ago and the API has only had one update since.
  197. # [02:45] <dael> plinss: I intent to get back in in the next few weeks and let me do that and then you can have a fairly stable script
  198. # [02:45] <dael> clilley: Thank you. I think it's very good.
  199. # [02:46] <dael> plinss: It doesn't link to the style sheet. Do you want that piece too and have it live on the w3c server?
  200. # [02:46] <dael> plinss: That's doable
  201. # [02:46] <dael> plh: Do you think about how you do a new ap you need to do the script. Is that painful and do we want to try a new location?
  202. # [02:47] <dael> clilley: All the thing for a pub need to be underneath. I think it's worth pushing on a well known location where it's installed and point there. It also solves the version problem.
  203. # [02:47] <dael> clilley: That's worth pushing for.
  204. # [02:47] <glazou> SteveZ: I unuted you
  205. # [02:47] <glazou> unmuted
  206. # [02:47] <dael> plh: You can still share it across spec.
  207. # [02:47] <dael> plh: As long as you won't ever break it, that would be nice.
  208. # [02:47] <dael> clilley: If it's instearting a style sheet link through the script, that needs to come in before the final offical sheet.
  209. # [02:48] <dael> clilley: So for next step we need to refactor and stabilize?
  210. # [02:48] <dael> plinss: Yeah, let me have another pass to stabilite
  211. # [02:49] <dael> plh: Then we need to deal with bikeshead
  212. # [02:49] <dael> plinss: Yes, bikeshed is making those links.
  213. # [02:49] <dael> plinss: So we'll want to use our on version of the script on the drafts?
  214. # [02:49] <dael> clilley: It seems more efficent if the script is together. If not, let's shift.
  215. # [02:49] <dael> TabAtkins: It's the browser making the requests.
  216. # [02:49] <dael> clilley: Then we'll use the same version for all.
  217. # [02:50] <dael> clilley: Any origan problems if some is on dev and some is on www
  218. # [02:50] <dael> TabAtkins: Shouldn't
  219. # [02:50] <dael> clilley: Okay. The ball is in plinss court.
  220. # [02:50] <dael> plinss: I recall an issue with TR where it doesn't exist?
  221. # [02:50] <dael> clilley: I believe they're serving HPS.
  222. # [02:50] <dael> plh: We don't use it for TR commands.
  223. # [02:51] <dael> plinss: If people are doing the FTP for it it would be shipping wrong
  224. # [02:51] <dael> plh: I don't believe people are.
  225. # [02:51] <dael> plinss: But we can do it on dev
  226. # [02:51] <dael> plh: It's possible people could access it but since the link is related the script will be through HTTPS as well
  227. # [02:51] <dael> plinss: I was think of issues a while ago.
  228. # [02:51] <dael> plh: Testing will be needed
  229. # [02:51] <dael> plinss: Okay. We're fine.
  230. # [02:52] <dael> plh: I tried to access through HTTPS and got redirected
  231. # [02:52] <dael> plinss: And dev isn't doing HTTPS
  232. # [02:52] <dael> plinss: I think bikeshead has a sceme for that. I think we're okay.
  233. # [02:52] <dael> plinss: Okay.
  234. # [02:52] <plinss> s/has a sceme/uses scheme relative urls/
  235. # [02:52] <dael> Topic: Selectors 4
  236. # [02:53] <dael> fantasai: There's been a lot of text changes so I need to review and we'll want another WD with that
  237. # [02:53] <dael> fantasai: I think what we needf rom the WG is opinions on what's this level vs the next. Right now the draft has a cut of what we think goes in this level
  238. # [02:54] <dael> glaz: So nothing to do really
  239. # [02:54] <dael> fantasai: I don't think so
  240. # [02:54] <dbaron> http://dev.w3.org/csswg/selectors4/
  241. # [02:54] <dael> glaz: If you have anything to discuss on 4 now is the time.
  242. # [02:54] <dael> glaz: We need time to review the added text
  243. # [02:54] <dael> TabAtkins: And I have more to rewrite
  244. # [02:54] <dael> glaz: If we close this now it means we've used the morning's agenda. CSS3 text is on this afternoon for SteveZ and Bert
  245. # [02:55] <dael> glaz: We don't have Bert on the call
  246. # [02:55] * clilley "I added a load of new text, can I publish a new WD yesterday" -- Napoleon
  247. # [02:55] <dael> TabAtkins: I had a 5 or 10 minute topic from last night.
  248. # [02:55] * liam thinks Napoleon would just say, "I added a load of new text and I commanded the Rec to be published"
  249. # [02:55] <dael> TabAtkins: At least year's blink con one of the bloomburg guys that does blackberry asked me to prop a value for text overflowt hat does a fade over the edge
  250. # [02:56] <dael> TabAtkins: So when the thing overflows you don't kill characters for an elip.
  251. # [02:56] <dael> TabAtkins: The name they're using is -blackberry-fade.
  252. # [02:56] <dael> TabAtkins: I think text-overflow-fade is good
  253. # [02:56] <dael> hober: Is the fade config?
  254. # [02:56] <dael> TabAtkins: Yeah.
  255. # [02:56] <fantasai> s/text-overflow-fade/text-overflow: fade/
  256. # [02:56] <dael> plinss: My concern is that is there a new paradim next year. Can we do a generic way to handle overflow markers where someone could use a fade.
  257. # [02:56] * Joins: lmclister (~lmclister@public.cloak)
  258. # [02:57] <dael> hober: Link how I do a fade from 0k black to transparent black
  259. # [02:57] <dael> plinss: My point is can we get creative and come up with ::voverflow or something
  260. # [02:57] <dael> clilley: Where the overflow defines and area that you can style.
  261. # [02:57] <dael> plinss: And the default is elipsis
  262. # [02:57] <dael> glaz: Can we just add a value for that effect?
  263. # [02:58] <dael> TabAtkins: If we had a way to config, given that we don't have a way to composite jsut the content there's no way...
  264. # [02:58] <dael> hober: masking?
  265. # [02:58] <dael> fantasai: That get's BG. You just want ttext to fade.
  266. # [02:58] <dael> fantasai: The easiest is a keyword
  267. # [02:58] <dael> plinss: But when we want a diff effect, do we need another kyword
  268. # [02:58] <dael> TabAtkins: Well if it's similar we jsut tack on.
  269. # [02:58] <dael> TabAtkins: The obvious is eventually do a pseudo when it's needed
  270. # [02:59] <clilley> krit mentioned adding an image
  271. # [02:59] <dael> Rossen_: One common req we get becides layout is that people wnat to use it for bubble or whatever have you so we need to be able to attach other behavious
  272. # [02:59] <dael> fantasai: Yeah.
  273. # [02:59] <dael> TabAtkins: and that's true for block overflow
  274. # [02:59] <dael> Rossen_: And if we don't know which period is where the marker is more than just a layout. Evenually we put the power in the designer's hands.
  275. # [02:59] <dael> TabAtkins: I agree.
  276. # [03:00] <dael> hober: I think that's a better long term way
  277. # [03:00] <dael> TabAtkins: None of that solves that there is no was in CSS without new abilities to do a lets fade the content over some fraction
  278. # [03:00] <dael> Rossen_: Well what we talked about
  279. # [03:00] <dael> TabAtkins: We have conceptiual framework, but nothing that can be extended
  280. # [03:00] <dael> krit: Is it poss that instead of one keyword we have the image and that uses mask That give more freedom
  281. # [03:01] <dael> TabAtkins: Are there use cases for fading with an arbitratry image?
  282. # [03:01] <dael> krit: I can image it. there are different ways to indicate and that's platform dependant
  283. # [03:01] <dael> TabAtkins: You mean adding an image, yes.
  284. # [03:01] <dael> clilley: If you use the image and use lumanence.
  285. # [03:01] <dael> TabAtkins: You can't fade the content via the masking of another elemnt
  286. # [03:02] <dael> plinss: It seems we should fix that
  287. # [03:02] <dael> krit: You can fade and mask just the test. if you use text overflow and just use the image it's not an issue
  288. # [03:02] <dael> TabAtkins: Maps instead of displays?
  289. # [03:02] <dael> Rossen_: And you large is your image, krit?
  290. # [03:02] <dael> krit: You have to define that
  291. # [03:03] <dael> Rossen_: In the case of text overflow what you would do when you layout the last word you would have to work your way backwards to fine the elipsis
  292. # [03:03] <dael> Rossen_: Actual size is det. at layout and if you're just doing one generic image, how do you align
  293. # [03:03] <dael> krit: You can define it with gradent.
  294. # [03:03] * liam happy to see a demonstration of CSS aural properties combined with the proposed new feature
  295. # [03:03] <krit> s/You can define it with gradient./How would you define the offset for gradients?/
  296. # [03:04] <dael> TabAtkins: I'm still not clear krit I think you're suggesting we can spec an image instead of a string and have an option for use this image as a mask instead of as an image. Is that correct?
  297. # [03:04] <krit> yes
  298. # [03:04] <dael> krit: Yes
  299. # [03:05] <dael> TabAtkins: That seems weird to me because it feels like jamming a special behaviour in and if we're introducing something more than keyword it should be more general so that you can use an element as the mask of another element
  300. # [03:05] <dael> fantasai: Do we want a pseudo for something like ::content and all you can apply is masking/filters. As a general thing.
  301. # [03:05] <dael> TabAtkins: no, we don't want that b/c...well, it won't solve the overflow b/c you can't tell what side the overflow is on.
  302. # [03:05] <dael> plinss: Yeah, that's orthaganal to the question
  303. # [03:06] <dael> fantasai: Can overflow take 2 values?
  304. # [03:06] <dael> TabAtkins: Yes
  305. # [03:06] * hober can't come up with a ::last-line joke
  306. # [03:06] <dael> fantasai: If we add image we can do that. If we let the image be a mask that solves it
  307. # [03:06] <dael> TabAtkins: But saying you can do that for text overflow, that seems oddly specfic way of generalization.
  308. # [03:06] <dael> TabAtkins: That's an odd place to stop. Either design something that works clearly or design the general facility
  309. # [03:07] <dael> fantasai: I'm in favor of the keyword regardless.
  310. # [03:07] <dael> fantasai: I would suggest we add fade to text-overflow
  311. # [03:07] <dael> fantasai: We'll need a more general solution that has event handling and full styling, but even if we had that it would be awkward for this simple, straigthforward case
  312. # [03:07] <dael> hober: You think a single keyword would be enough for most people's design?
  313. # [03:08] <dael> TabAtkins: For most people, but allowing to passa length wouldn't be a problem
  314. # [03:08] <dael> hober: People who have gone to the effort already are they people that was a level of control
  315. # [03:08] <dael> glaz: The fade length is likely different on a small screen.
  316. # [03:08] <dael> TabAtkins: I've seen some long fades.
  317. # [03:08] <dael> fantasai: So you want to use percentage length
  318. # [03:08] <dael> TabAtkins: percentages and lengths
  319. # [03:09] <dael> glaz: Adding length doesn't really fit. fade should be functional
  320. # [03:09] <dael> TabAtkins: As a keyword and a function it should take a length
  321. # [03:09] <dael> hober: Words for me
  322. # [03:09] <dael> glaz: Me too
  323. # [03:09] <hober> s/Words/Works/
  324. # [03:09] <dael> TabAtkins: We can discuss the greater generalization later
  325. # [03:09] <dael> glaz: I've seen a text overflow with flat text and rounding
  326. # [03:09] <dael> plinss: It's a transform, right?
  327. # [03:09] <dael> glaz: It's a transform.
  328. # [03:10] <dael> plinss: People will want to do transforms. If we give them one we want a lot.
  329. # [03:10] <dael> hober: And if we get feedback it's good.
  330. # [03:10] <dael> plinss: I don't mind the keyword, I want to explain that the keyword creates these things and you can override that by adding these lines of CSS
  331. # [03:10] <dael> hober: And you can describe the pseudo as something you can work toward and get at laters
  332. # [03:11] <dael> plinss: Let's explain in terms of our primitives
  333. # [03:11] <dael> fantasai: I think adding the keyword makes sense and we should work o nthe general solution. And having these use cases will help us get there coreectly.
  334. # [03:11] <dael> TabAtkins: I think it's the inside pseudo hixie tried forever ago
  335. # [03:11] <dael> fantasai: I don't think so.
  336. # [03:12] <dael> fantasai: We could spend the morning trying to figure out this problem. People want control over overflow, they want elipsis in the direction of the block
  337. # [03:12] <dael> fantasai: WE always find that solving it takes time and we have time
  338. # [03:12] <dael> Rossen_: WE can look into use content-outflow
  339. # [03:12] <dael> Rossen_: ::after
  340. # [03:12] <dbaron> s/content-outflow/::after { content: ... }/
  341. # [03:12] <dael> fantasai: I don't think we want to do that
  342. # [03:13] <dael> plinss: How does that interact witht he overflow
  343. # [03:13] <dael> fantasai: It's part of the text alignmenet.
  344. # [03:13] <dael> hober: It's the last part of the content
  345. # [03:13] <fantasai> s/alignment/content/
  346. # [03:13] <dael> plinss: So that you have content after can cause the elipsis
  347. # [03:13] <fantasai> fantasai^: that gets elided
  348. # [03:13] <dael> fantasai: If you haev a long bit of ::after content a lot will get elipsised, but if it's short...
  349. # [03:13] <fantasai> *ellipsized
  350. # [03:14] <dael> dbaron: What needs solvign for block overflow?
  351. # [03:14] <dael> fantasai: 1 is to have the block overflow inline and 2 is to have it after last line
  352. # [03:14] <glazou> ellipsizationnized
  353. # [03:14] <dael> dbaron: I've seen the latter as fades.
  354. # [03:14] <dael> TabAtkins: When in JS it'll be centered on the last line.
  355. # [03:15] <dael> TabAtkins: The other req would be to be able to recieve click events.
  356. # [03:15] <dael> fantasai: We need a way of defining events
  357. # [03:15] <dael> dbaron: In some cases you only want click in some places.
  358. # [03:15] <dael> fantasai: I propose we take a break, get the awesome green board, and start doing examples.
  359. # [03:15] * dauwhe greenboarding is the new bikeshedding
  360. # [03:16] <dael> glaz: I don't think the greenboard will get in the elevator.
  361. # [03:16] <dael> [break = 15min]
  362. # [03:16] * dbaron at least it's not waterboarding
  363. # [03:22] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
  364. # [03:29] * hober dauwhe: OMG WE HAVE TO FIND THIS DUNKIE'S: http://a3.img.mobypicture.com/2378b797a7d4d4a988c73d49fe28e3b3_view.jpg
  365. # [03:30] * liam dauwhe - discussion on arabic drop initials/words/numbers: https://groups.google.com/forum/#!topic/persian-computing/W-Upl6DAEcg
  366. # [03:32] * Joins: jh_hong (~jh_hong@public.cloak)
  367. # [03:34] * Joins: dauwhe_ (~dauwhe@public.cloak)
  368. # [03:34] * dauwhe_ liam: that's great. Those are the first actual examples I've seen. Thanks!
  369. # [03:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  370. # [03:39] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  371. # [03:39] * Joins: myakura (~myakura@public.cloak)
  372. # [03:42] * Joins: tantek (~tantek@public.cloak)
  373. # [03:43] * krit TabAtkins I just noticed that Bikeshed removed <pre> closing text which is leading to bad results
  374. # [03:43] <krit> <div class=example>
  375. # [03:43] <krit> <p>Consider a shape that is clipped by a clipping path applied to an ancestor:</p>
  376. # [03:43] <krit> <pre><code class=html>&lt;g clip-path="circle()">
  377. # [03:43] <krit> &lt;path id="shape" d="M0,0 L10,10, L 20,0 z"/>
  378. # [03:43] <krit> &lt;/g>
  379. # [03:43] <krit> </code></pre>
  380. # [03:43] <krit> <p>The shape is referenced by a <a>'use'</a> element:</p>
  381. # [03:43] <krit> <pre><code class=html>&lt;use xlink:href="#shape"/>
  382. # [03:43] <krit> </code></pre>
  383. # [03:43] <krit> <p>The geometry of the shape is not influenced by the circular clipping path.</p>
  384. # [03:43] <krit> </div>
  385. # [03:43] <krit> oops
  386. # [03:43] <krit> https://www.irccloud.com/pastebin/s2nE2bXp
  387. # [03:44] <krit> gets to
  388. # [03:44] <krit> https://www.irccloud.com/pastebin/CeY6YX28
  389. # [03:44] * krit TabAtkins making the next <p> part of <pre>
  390. # [03:45] <TabAtkins> Hm, shouldn't be doing that. I'll investigate.
  391. # [03:46] * dauwhe_ I think I had a similar issue, where I had to add more line breaks to avoid validity errors
  392. # [03:46] <krit> TabAtkins: It seems not to do it if a </div> follows after </pre>
  393. # [03:50] <TabAtkins> The new Markdown code is still a little bit buggy, sorry.
  394. # [03:52] <krit> https://www.irccloud.com/pastebin/cj4sRSA8
  395. # [03:52] <krit> TabAtkins: that is another error I get from the validator
  396. # [03:54] <TabAtkins> krit: I can't reproduce your first error.
  397. # [03:54] <TabAtkins> That validator issue is easy to diagnose. I think I fixed that yesterday.
  398. # [03:54] <TabAtkins> Have you updated Bikeshed recently?
  399. # [03:55] <krit> TabAtkins: happens in example 3 http://dev.w3.org/fxtf/css-masking-1/#clipping-paths
  400. # [03:55] <krit> TabAtkins: yes
  401. # [03:57] * SteveZ I am leaving webinar. Will be back at 1PM Korean time for Text
  402. # [03:57] <TabAtkins> krit: Huh. I grabbed your source code from Masking and just ran it through bikeshed, and it does the right thing.
  403. # [03:57] <TabAtkins> Got some context around as well, just in case.
  404. # [03:58] <krit> TabAtkins: di you run make, or bikeshed?
  405. # [03:58] <TabAtkins> I looked up Overview.src.html from my browser, found the example, copied out a chunk of it into a test document.
  406. # [03:58] <TabAtkins> Then ran Bikeshed.
  407. # [03:59] * Quits: lmclister (~lmclister@public.cloak) ("")
  408. # [04:01] <krit> TabAtkins: hm, looks like i didn't run latest build
  409. # [04:01] <krit> TabAtkins: issue 1 resolved :)
  410. # [04:01] <TabAtkins> hahaha I KNEW IT
  411. # [04:02] <TabAtkins> The other one looks like an unquoted title, which definitely happened before I fixed the problem.
  412. # [04:02] <TabAtkins> I presume you have title="nonzero value" in your source?
  413. # [04:03] <krit> TabAtkins: <p>The following drawing illustrates the <i value>nonzero</i> rule:</p>
  414. # [04:03] <TabAtkins> Oh! Use <a> like a normal person.
  415. # [04:03] <TabAtkins> I don't do a lot of the fixup on <i>.
  416. # [04:04] <TabAtkins> Support for <i> is pretty much just to appease fantasai
  417. # [04:04] <krit> TabAtkins: just <a> freaks out the SVG preprocessor I still have to use
  418. # [04:04] <liam> to appease fantas<i> ?
  419. # [04:05] <krit> TabAtkins: FATAL ERROR: No 'value' refs found for 'nonzero'.
  420. # [04:05] <krit> TabAtkins: <i value> --> <a value>
  421. # [04:06] <TabAtkins> Yeah, go look at your <dfn>. Bikeshed doesn't know it's a valuedef.
  422. # [04:07] <krit> TabAtkins: so <dfn dfn-value>nonzero</dfn> ?
  423. # [04:07] * liam guessing a productive session on editing is happening & discussion may resume after lunch?
  424. # [04:08] <TabAtkins> Private discussion on how to resolve logical box properties with physical ones between fantasai and rossen.
  425. # [04:08] <TabAtkins> The rest of us are on break.
  426. # [04:08] <liam> tx
  427. # [04:08] <TabAtkins> And me and krit are doing stuff.
  428. # [04:08] <liam> doing = good
  429. # [04:08] <liam> ftf time awesome for that.
  430. # [04:09] <TabAtkins> krit: Either <dfn value for=clip-rule>nonzero</dfn>, or put <dl dfn-type=value dfn-for=clip-rule> and then just plain <dfn>
  431. # [04:09] <TabAtkins> krit: rtfm ^_^
  432. # [04:09] <krit> TabAtkins: fixed now. Thanks!
  433. # [04:12] * Joins: zcorpan (~zcorpan@public.cloak)
  434. # [04:17] * Quits: Henke37c (~Henrik@public.cloak) (Client closed connection)
  435. # [04:19] <dael> Glenn Adams, Rossen Atanassov, Tab Atkins, David Baron, Adenilson Cavalcanti, Dave Cramer, Bruno de Oliveira Abinader, Elika Etemad, Daniel Glazman, Dongwoo Joshua Im, Koji Ishii, Dael Jackson, Philippe Le Hégaret, Chris Lilley, Peter Linss, Shinyu Murakami, Edward O'Connor, Simon Pieters, Andrey Rybka, Alan Stearns, Shane Stephens, Jet Villegas + 5 observers
  436. # [04:20] <dael> Phone: krit, SteveZ, liam, Bert (dael - check at EoD)
  437. # [04:21] * Joins: myakura_ (~myakura@public.cloak)
  438. # [04:27] * Quits: myakura (~myakura@public.cloak) ("Page closed")
  439. # [04:27] * myakura_ is now known as myakura
  440. # [04:32] <zcorpan> plinss: glazou: plh and i added two suggested topics at http://wiki.csswg.org/planning/seoul-2014#wednesday
  441. # [04:34] <dael> fantasai: First is logical properties in general. There's 4 impl. Webkit Microsoft Mozilla and AH and there's no spec.
  442. # [04:34] <glazou> zcorpan: noted
  443. # [04:34] <dael> fantasai: When I wrote it the WG said I wasn't allowed to (4 years ago)
  444. # [04:34] <dael> fantasai: We're proposing the take that spec and resurect it seperatly and publish it as an ED with a FPWD shortly after
  445. # [04:35] <dael> fantasai: Editors would be me and Rossen_ with murakami ghost editing.
  446. # [04:35] * Joins: harayama (~harayama@public.cloak)
  447. # [04:35] <dael> fantasai: Further commetns?
  448. # [04:35] <dael> hober: It's a great idea. do it.
  449. # [04:36] <dael> dbaron: I may have comments when it exists, but I'm happy to have it.
  450. # [04:36] <dael> hober: If you check the UA stylesheet for right and left we clearly need it.
  451. # [04:36] <dael> Rossen_: There's enough web content that it demands having this.
  452. # [04:36] <dael> Rossen_: We don't want to go into technical now.
  453. # [04:37] <dael> RESOLVED: ED of CSS Logical Properties
  454. # [04:37] * Quits: jh_hong (~jh_hong@public.cloak) ("Page closed")
  455. # [04:37] * Joins: lmclister (~lmclister@public.cloak)
  456. # [04:38] <dael> dauwhe_: Should we try and use logical prop when writing specs?
  457. # [04:38] * Joins: jhh (~jhh@public.cloak)
  458. # [04:38] <dael> fantasai: I think all future drafts of layout should have logical and physical spec'ed together.
  459. # [04:38] <dael> Rossen_: There's 2 exceptions, B&B and exclussions. It was demanded that we name all the properties from the start
  460. # [04:38] <dael> hober: So exclussions is only logical
  461. # [04:38] <dael> TabAtkins: Well we didn't have a way to mix.
  462. # [04:39] <dael> hober: So where webkit has phsycial and logical, the shorthand is physical, so are there exclusion shorthands that are logical?
  463. # [04:39] <dael> Rossen_: No. You have wrap-start, wrap-end and it's in the logical way of whatever we decide logical is
  464. # [04:39] <dael> fantasai: And shorthands prob want a keyword to spec that it's logical.
  465. # [04:39] <dael> hober: !logical
  466. # [04:39] <dael> Rossen_: We can have an option
  467. # [04:40] <dael> TabAtkins: Do we want to defer discussion about order for four sides in a marging
  468. # [04:40] <dael> fantasai: The one that starts block-start, line start, block end, line end
  469. # [04:40] <dael> hober: start after end before should be the order
  470. # [04:40] <dael> TabAtkins: Depends on if you're english-specific
  471. # [04:40] <dael> dbaron: What fantasai said matches arabic and hebrew
  472. # [04:41] <dael> fantasai: But that gets you what's on the beginging half of the block to be set first.
  473. # [04:41] <dael> TabAtkins: It's opposite way of the circle for somebody.
  474. # [04:41] * Parts: adenilson (~anonymous@public.cloak) (adenilson)
  475. # [04:41] <dael> fantasai: We have start comes before end so the shorthand should match that
  476. # [04:41] <dael> hober: I was hoping for if I have a margin for lengths that's physical. If I put !logical at the end I don't see something different
  477. # [04:41] <fantasai> s/match that/match that semantic/
  478. # [04:42] <dael> TabAtkins: It won't happen. Either english is wrong and arabic is right or vice verse.
  479. # [04:42] <dael> TabAtkins: And verical modes are completely a mess. We can bless one writing method with being identicial
  480. # [04:42] <dael> TabAtkins: We have precedent with grid positioning.
  481. # [04:42] <dael> TabAtkins: Grid only uses logical
  482. # [04:43] <dael> hober: I'm not conviced, but we can discuss this later.
  483. # [04:43] <dael> zcorpan: I agree with hober that it should be similar to the spirit of the phsyical
  484. # [04:44] <dael> fantasai: But the spirit was lets go forwarda nd if we have four directions, lets go clockwise. If you're talking logical you don't go start to end, you do start,start corner
  485. # [04:44] <dael> hober: In horizontal LR it would be odd if !logical made my margins float.
  486. # [04:44] <dael> TabAtkins: I don't understand why that's valid because if people have a differently directioned language they can argue for a different result
  487. # [04:45] <dael> plinss: One reason it is what it is if you leave things off and repeat you get logical (reasonable) results.
  488. # [04:45] <dael> plinss: That rule is preserved.
  489. # [04:45] <dael> hober: That's regardless of chioce
  490. # [04:45] <dbaron> it's not pure repeating (for the 3 value case)
  491. # [04:45] <dael> Rossen_: Currently most content is in physical.
  492. # [04:45] <dael> Rossen_: If you have a keyword that breaks this half the time...
  493. # [04:46] <dael> TabAtkins: So if someone is an idiot and converts to logical without thinking about it, you're left and right will swap.
  494. # [04:46] <dael> zcorpan: I think people will use the keyword because i'ts cool
  495. # [04:46] * Joins: murakami (~murakami@public.cloak)
  496. # [04:46] * dauwhe_ This would be a bad time for to mention margin-inside and margin-outside ^_^
  497. # [04:46] <dael> hober: If you have existing content and want to make it flip to logical, it should be as easy as possible
  498. # [04:46] <dael> Rossen_: I can see libraries changing.
  499. # [04:46] <plinss> s/rule is preserved/rule should be preserved/
  500. # [04:46] * liam makes dauwhe_ read the XSL-FO spec :-) :-)
  501. # [04:47] <dael> TabAtkins: And the first time a library switches people will see a bug. You're positing a library that forces you into logical
  502. # [04:47] <dael> TabAtkins: They'd assume english and swap the values. You're assuming librabry authors are idiots.
  503. # [04:47] <dael> TabAtkins: There's a different between one person that writes a plug for 100 webpages. Are you write a library and pushing without result?
  504. # [04:48] <dael> clilley: THen people wouldn't use your library
  505. # [04:48] <dael> TabAtkins: You want to make sure the omitting arguements makes sense.
  506. # [04:48] <dael> hober: If you have two values it applies to the start and end. plinss argues we shouldn't do something pathalogical.
  507. # [04:48] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 180 seconds)
  508. # [04:48] <dael> dbaron: The arguement is that the first two arguements 1 shoudl be block and 1 inline
  509. # [04:48] <dael> fantasai: And we're arguing that of the two inlines that start should be first.
  510. # [04:48] <dbaron> s/The arguement/peterl's argument/
  511. # [04:49] <dael> hober: I think the underlying is that the org clockwise was a mistake, but it's one we'll live with forever and I think consistany with that mistake is a good thing.
  512. # [04:49] * dauwhe_ what properties would mirror-universe Spock use to write CSS?
  513. # [04:49] <dael> glaz: Are we done with logical properties?
  514. # [04:49] * Joins: adenilson (~anonymous@public.cloak)
  515. # [04:49] <dael> fantasai: WE can move to background-position x/y
  516. # [04:49] * astearns !logical means clockwise, logical! means anti-clockwise
  517. # [04:50] <dael> dbaron: To be clear, this is the day we have a 1-2 that needs to be 1-2 which means we need to break in the next 10 minutes.
  518. # [04:50] <dael> fantasai: I'll present and we can ruminate over lunch.
  519. # [04:50] * dbaron notes that lunch will not consist of grass
  520. # [04:50] <dael> fantasai: The problem is we have a background position prop which takes two values (for simplicity)
  521. # [04:51] * dauwhe_ only because we're not meeting in Boulder, Colorado
  522. # [04:51] * plinss (hopefully)
  523. # [04:51] <dael> fantasai: That are all keywords. They are top, center, bottom, left, center right. One from each set of 3
  524. # [04:51] * liam wants !deosil and !widdershins
  525. # [04:52] <dael> fantasai: When you throw in logical values you can do this or do inline-start, center, inline-end, and than block-start, center, block-end and pick 2 from each section
  526. # [04:52] * TabAtkins liam: Ah, I was trying to recall what the funky clockwise word was.
  527. # [04:52] <dael> fantasai: And than you have these properties that have been impl of background-position x/y and what do they map to?
  528. # [04:52] * liam :)
  529. # [04:52] <dael> fantasai: What do we assign to these long hands.
  530. # [04:52] * liam "sunwise" as an alternative spelling.
  531. # [04:53] * Quits: jhh (~jhh@public.cloak) (Ping timeout: 180 seconds)
  532. # [04:53] <dael> fantasai: The other case is pick any two keywords from the <position> options and you can have top-start
  533. # [04:53] <dael> fantasai: If you have english it's top left, arabic top-right, and japanese it's where the block starts.
  534. # [04:54] <dael> fantasai: You've already constrained the first dimension, so you just have to pick the second.
  535. # [04:54] <dbaron> case (1) is using only physical (top/center/bottom and left/center/right)
  536. # [04:54] <dbaron> case (2) is using only logical (inline-start/center/inline-end and block-start/center/block-end)
  537. # [04:54] <dael> fantasai: Let's say you have a sun and a fish background, you want the sun to be in the origan, not to be scrolled off so you'd want that in the start corner, but in the top for sure.
  538. # [04:54] <dbaron> case (3) is mixing one value from case (1) with (start/center/end) (note no block- or inline-)
  539. # [04:54] <dael> fantasai: So there's reasons to combine logical and physical.
  540. # [04:55] <dael> fantasai: This world with a combination of logical/physical doesn't map to x and y axis.
  541. # [04:55] <dael> Rossen_: What introduced background-position
  542. # [04:55] <dael> fantasai: inline-block
  543. # [04:55] <dael> TabAtkins: In the same way we'd have alias
  544. # [04:55] <dael> fantasai: But we can't actually accept it as an alias
  545. # [04:55] * sgalineau reading a discussion about logical properties backwards was not my best idea
  546. # [04:55] <dael> TabAtkins: You can alias after you figure out writing modes.
  547. # [04:56] <dael> hober: If you set margin sstart and inspect margin top
  548. # [04:56] <dael> dbaron: So then the long hands let you spec combinations that can't be represented.
  549. # [04:56] <dael> hober: So the margin shorthand if you have something global to the property line, the short hand is all physical or logical, but if you use longhand you can mix.
  550. # [04:57] <dael> dbaron: So in your 3rd case of start-center-end they're values of x and y because they're not spec values of inline-start.
  551. # [04:57] <dael> TabAtkins: That's how I was thinking I would handling the shorthanding.
  552. # [04:57] <dael> dbaron: I don't quite follow the implications
  553. # [04:57] <dael> zcorpan: If you are mixing the phsyical one can get into shorthand fine?
  554. # [04:57] <dael> zcorpan: So if you have top-start than it goes into position-y.
  555. # [04:58] <dael> zcorpan: The problem is if you spec both as logical?
  556. # [04:58] * Joins: jh_hong (~jh_hong@public.cloak)
  557. # [04:58] <dael> fantasai: That's this whole mess and having these properties mapping there's an adidtional problem with all of the other cases with logical prop the initial values are identical
  558. # [04:59] <dael> fantasai: If they all have 0 and there's no conflict. But here with background-position-x/y they'll be top left. That's fine in english, but in other languages it'll be inconsistant
  559. # [04:59] <dael> dbaron: And you need to know which one to use.
  560. # [04:59] <dael> fantasai: And you can't use a cascase because there isn't one.
  561. # [04:59] <dael> TabAtkins: I say spec by fiat
  562. # [04:59] <dael> dbaron: There's another way. If you haev something spec for one, if the winning is background-posistion-y you use that for x, but if the winning is background-inline that wins
  563. # [05:00] <dael> dbaron: It could be 2 but one gets overridden
  564. # [05:00] <dael> hober: But with none?
  565. # [05:00] * plh rrsagent, where am I?
  566. # [05:00] * RRSAgent See http://www.w3.org/2014/05/21-css-irc#T03-00-06
  567. # [05:00] <dael> dbaron: We leave the current defual
  568. # [05:00] <dael> TabAtkins: So if we do fiat physical, if you speck background-position-block and you spec in the direction, ir should work.
  569. # [05:00] <dael> TabAtkins: I'm fine with that.
  570. # [05:00] <dael> dbaron: I'm okay. It's more complex than I was hoping.
  571. # [05:00] <dael> fantasai: Yeah.
  572. # [05:01] <dael> fantasai: It would have been nice to avoid the longhands.
  573. # [05:01] <dael> hober: It would be prob premature to res on res in this way since we haven't tried, but let's agree the initial spec should be this way and we'll alter if needed.
  574. # [05:02] <dael> [whiteboard photo from dbaron]
  575. # [05:02] <dael> [break = lunch]
  576. # [05:07] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  577. # [05:07] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
  578. # [05:07] <dbaron> whiteboard photo: http://lists.w3.org/Archives/Public/www-archive/2014May/att-0008/dsc06433-fantasai-whiteboard.jpg
  579. # [05:08] * Quits: andrey (~andrey@public.cloak) (Ping timeout: 180 seconds)
  580. # [05:09] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
  581. # [05:09] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  582. # [05:10] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
  583. # [05:13] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  584. # [05:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  585. # [05:29] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
  586. # [05:32] * Joins: myakura (~myakura@public.cloak)
  587. # [05:39] * Joins: dauwhe (~dauwhe@public.cloak)
  588. # [05:53] * Joins: andrey (~andrey@public.cloak)
  589. # [05:54] * Joins: dael (~dael@public.cloak)
  590. # [05:55] * Joins: jh_hong (~jh_hong@public.cloak)
  591. # [05:56] * Joins: adenilson (~anonymous@public.cloak)
  592. # [05:59] * SteveZ Steve is here
  593. # [05:59] * fantasai waves
  594. # [05:59] * dauwhe Hello, Steve!
  595. # [05:59] * SteveZ waves back
  596. # [05:59] * liam waves to Steviepoos
  597. # [05:59] * Joins: glazou (~glazou@public.cloak)
  598. # [05:59] <glazou> Bert: yt?
  599. # [05:59] * liam hears the arrival also of the Vogon fleet
  600. # [06:00] <dael> glaz: Let's start even if Bert isn't here.
  601. # [06:00] <dael> glaz: First is CSS 3 Text
  602. # [06:00] * dauwhe Groop, I implore thee, my foonting turlingdromes
  603. # [06:00] <dael> glaz: And we have 5 sub items. First is texxt-align short ending
  604. # [06:00] <dael> fantasai: We discussed this at Paris F2F
  605. # [06:01] <dael> fantasai: We currently have a text-slign property and we have text-align-last prop.
  606. # [06:01] * glazou SteveZ said "woof woof" ; we should save that for the minutes :-D
  607. # [06:01] <dbaron> s/short ending/shorthanding/
  608. # [06:02] <dael> fantasai: They're currently independant and we think that we can make text-align-last a longhand for text-align
  609. # [06:02] <dael> clilley: With making it take an optional 2nd value?
  610. # [06:02] <dael> fantasai: That's one poss.
  611. # [06:02] <dael> fantasai: The case were people use align-last is auto or justify, which means justify the last line b/c it's not be default
  612. # [06:03] <dael> dauwhe: We call this forced justiciation in my work
  613. # [06:03] <dael> fantasai: In Japanese people with set text-align: justify, text-justify: distribute and text-align-last: justify.
  614. # [06:03] <dael> fantasai: We elimated that last step to make it easier
  615. # [06:03] <dael> fantasai: We were going to tie in to have it happen only end justification is happening
  616. # [06:04] * liam compares http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
  617. # [06:04] <dael> clilley: So you mean that you can set text-align-last to justify and only the last line will justify?
  618. # [06:04] <dael> fantasai: Yeah
  619. # [06:04] <dael> fantasai: The prop on the table was to have text-align and text-align-all which would take the other values
  620. # [06:04] <dael> fantasai: We also have where people would want hte first line aligned for poetry or something.
  621. # [06:05] * liam wonders why you can't use :first-line
  622. # [06:05] <dael> fantasai: Currently we have an issue in the spec where we need a name for that and we'll drop it if we can't find a name
  623. # [06:05] <dael> TabAtkins: Can you apply text-align to first line?
  624. # [06:05] * Joins: shans_ (~shans@public.cloak)
  625. # [06:05] <dael> fantasai: I don't know. I think you could.
  626. # [06:05] <dael> TabAtkins: They don't cascade together.
  627. # [06:05] <dael> fantasai: The cascading is a bit of a problem.
  628. # [06:05] <dael> fantasai: I think it is do we want to switch text-align to a short hand and potenitally a text-align-first
  629. # [06:06] <dael> dbaron: I think you had expalined a case where the first and last lines should work differently in cascade terms.
  630. # [06:06] <dael> fantasai: When you set first diff from all you want to make sure you're restting all the alignment in the next declaration
  631. # [06:06] <dael> fantasai: The q was do we want text align as a delcaration.
  632. # [06:06] <dael> fantasai: Should/would that obliterate a privious text-align
  633. # [06:07] <TabAtkins> s/first line/::first-line/
  634. # [06:07] <dael> dbaron: I think it's where -last applies to anything before a break.
  635. # [06:07] <dael> dauwhe: That's something that's tripepd me on text-align-last that it applies after a forced line break
  636. # [06:07] <dael> dbaron: I rememebr there's something not semetric and you convined me they should cascade sperate
  637. # [06:08] <dael> glaz: can we use text align on the first and last line pseudo?
  638. # [06:08] <SteveZ> As I recall, "text-align-last" applies to paragraphs that have only one line
  639. # [06:08] <dael> fantasai: I won't cascade correctly. If you override and want thigns to center, it won't work because the pseudo is more specific.
  640. # [06:08] <dael> fantasai: That's a problem that shows up in various problems since the cascade rests things that are on the pseudo
  641. # [06:08] <dael> TabAtkins: I wouldn't call that killer, but it's a down side
  642. # [06:09] <dael> TabAtkins: Bolding the first line differently happens quite a bit. We use first-line for a lot of things that fall into a similar bucket and we're okay with making those not cascade.
  643. # [06:09] <dael> dbaron: I think text-align-last wouldn't work with a last-line pseudo
  644. # [06:10] <dael> dauwhe: I wish it was the last line. It would solve a lot of my problems.
  645. # [06:10] <dael> dbaron: You want the opposite too
  646. # [06:10] <dael> fantasai: You want a property for both things. No one has brought that up before.
  647. # [06:10] * SteveZ it is hard to hear Dave
  648. # [06:10] * liam fears Dave has been Assimilated
  649. # [06:11] <dael> dauwhe: I can work up examples, but we run into problems where we're trying to force a line break. In inDesign there's a lot of ways to do a line break and you can't do that in CSS because it'll force justify the last line even if it only has two characters
  650. # [06:11] <dael> fantasai: Okay.
  651. # [06:11] * liam notes that cascading is generally less important for people generating print from their own content (!) or for epub
  652. # [06:11] <dael> fantasai: I think I need to work on reloading the previous discussions into my brain. Unless there's something else to point out, I'll do that as we discuss other things
  653. # [06:12] <dael> liam: We added a bunch of stuff for XFL-FO for this. We have a bunch more values there and I'd have to look at how they interact
  654. # [06:12] <dauwhe> s/XFL-FO/XSL-FO/
  655. # [06:12] <dael> glaz: Okay.
  656. # [06:12] <dael> fantasai: most recent prop was text-align and a shorthand for -all and -last where they take the same values except -last takes auto
  657. # [06:12] <liam> [xsl-fo text-align-last has relative | start | center | end | justify | inside | outside | left | right | inherit ]
  658. # [06:13] <liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
  659. # [06:13] <dael> fantasai: The other is that they have the values that are attached to each. S you can set to justify: justify but it reads better.
  660. # [06:13] <dael> fantasai: So in most cases, the authors only need one keyword.
  661. # [06:13] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
  662. # [06:13] * SteveZ who is chopping wood?
  663. # [06:14] <fantasai> s/The other is that they have the values that are attached to each./The text-align shorthand takes one or two keywords, second one setting text-align-last. Alternately a justify-all keyword./
  664. # [06:14] <dael> fantasai: I guess we should go to the next issue while I find old minutes where we discussed
  665. # [06:14] <dael> dbaron: I could be mis rememebring
  666. # [06:15] <dael> fantasai: It was something about when you set text-align-last and you set the rest of it, if you want the rest of it to...um...
  667. # [06:16] <dael> fantasai: If you only have one line it'll be text-align first takes priority, folowed by -last, followed by -therest
  668. # [06:16] <dael> SteveZ: I dont understand how -first takes priority because it would be wrong for western.
  669. # [06:16] <dael> fantasai: If it's not justify.
  670. # [06:16] * hober text-align-most, text-align-middle :)
  671. # [06:16] <dael> SteveZ: Is that why text align-last took priority
  672. # [06:16] <dael> fantasai: I think -first take auto or start becasue there's no use case for antoher value
  673. # [06:16] <dael> SteveZ: What's auto mean?
  674. # [06:17] <dael> fantasai: do same as text-align-all
  675. # [06:17] <dael> SteveZ: There's 4 componets? -all, -first, -last
  676. # [06:17] <dael> fantasai: And the shorthand text-align
  677. # [06:18] <dael> SteveZ: I still think -first doesn't work because -all will want to be, in wetern you want all but the last line just
  678. # [06:18] <dael> fantasai: You leave first as auto
  679. # [06:18] <dael> SteveZ: But if it's priory it's justify
  680. # [06:18] <dauwhe> s/wetern/Western/
  681. # [06:18] <dael> dbaron: Auto says nothing special for the first, keep going
  682. # [06:18] <dael> SteveZ: But you have to decide if the first is just
  683. # [06:18] <dael> fantasai: I see what you're saying. Start takes priority but auto doesn't
  684. # [06:18] <dael> TabAtkins: It's same as start-self.
  685. # [06:19] <dael> astearns: But in western you want to take the text-align value if there's only one line.
  686. # [06:19] <astearns> s/text-align/text-align-last/
  687. # [06:19] <dael> fantasai: dauwhe problem he brough about different behviour form last line vs after a forced break. It means another prop
  688. # [06:19] <dael> fantasai: And if we add that is text-align-last actually the last line, or after breaks.
  689. # [06:19] <dael> koji: Is there a use case?
  690. # [06:20] <dael> dauwhe: The use-case is tied in details of hypenations and justification of text, but we get requests to alter a lot.
  691. # [06:20] <dael> dauwhe: If that happens outside the paramenters, you do a soft return and than that line is justified. That's desireable for us
  692. # [06:20] <dael> dauwhe: We don't want to force that just to the last line usually.
  693. # [06:20] <dael> dbaron: So we need a mech for that. For saying a break should be treated as a non-forced
  694. # [06:21] <liam> +1
  695. # [06:21] <dael> dauwhe: Yeah.
  696. # [06:21] <dael> fantasai: That makes more sense.
  697. # [06:21] <dael> dauwhe: I know it's an oddball use case.
  698. # [06:21] * Joins: Rossen_ (~Rossen@public.cloak)
  699. # [06:21] <SteveZ> I agree that a softbreak should not be treated as a hard break
  700. # [06:21] * Joins: koji (~koji@public.cloak)
  701. # [06:21] <dael> astearns: I think it comes up where people try and use a break and are confused that it's a paragraph break when they want a soft break
  702. # [06:22] <dael> koji: So iss the break feel alrigt?
  703. # [06:22] <dael> dauwhe: It feels liek a different break character
  704. # [06:22] <dael> glenn: Is there a unicode that has that sematic?
  705. # [06:22] <dael> fantasai: There's a soft break that we don't want to get into here.
  706. # [06:22] <dael> dbaron: I'm of the opinion that if we can't rememebr why to seperate, we should combine
  707. # [06:23] <dbaron> I found http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
  708. # [06:23] <dbaron> fantasai is quoting from Minutes 2013-11-12 Tues IV
  709. # [06:23] <dael> fantasai: Minutes from last F2F, we were ambivilent, than we heard from digipub and they said it would be better to go short-hand long-hand
  710. # [06:23] <dael> plinss: Unicode does have a line seperated vs paragraph seperater
  711. # [06:23] <dael> fantasai: I think that's the bidi(?) one
  712. # [06:23] <dael> fantasai: It's similar to soft
  713. # [06:24] <dael> dbaron: If we agree we want that use case to be from a soft-break, we don't need to do that now
  714. # [06:24] <dael> fantasai: So let's agree it'll be solved by a soft-break mechanism.
  715. # [06:24] <dael> koji: There's two issues in text-align I understand
  716. # [06:24] <dael> fantasai: I can defer text-align-first to the next level. We don't have a good shorthand.
  717. # [06:24] <dbaron> s/good shorthand/good way to express it in the shorthand/
  718. # [06:25] <dael> fantasai: I think we need text-align-all and -last with text-align as the shorthand
  719. # [06:25] <dael> fantasai: I think that's what we want to do. We should make that change and than go back to soft-breat
  720. # [06:25] <dael> dbaron: So text-align is a shorthand and takes one or two values
  721. # [06:25] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  722. # [06:25] <dael> fantasai: Or the shorthand justify-all
  723. # [06:25] <dael> SteveZ: So how do I get wester to align all but the last line?
  724. # [06:26] <liam> s/western/western layout/
  725. # [06:26] <dael> fantasai: Justify.
  726. # [06:26] <dbaron> s/Justify/text-align: justify/
  727. # [06:26] <dael> fantasai: Any other comments?
  728. # [06:26] <dael> RESOLVED: text-align as shorthand for text-align-last and text-align-all
  729. # [06:26] <dael> SteveZ: My understanding of french poetry is the first line is left just and the rest if right.
  730. # [06:27] <dael> fantasai: We're def. that to 4
  731. # [06:27] <dael> SteveZ: What I'm curious is if I say text-align: right and than say text-align: na and text-align: start that will work
  732. # [06:27] <dael> fantasai: Yes.
  733. # [06:27] <dael> dbaron: But that's what's defer to level 4
  734. # [06:28] <dael> fantasai: Part of the reason is that's fine in general if the browser supports, but if it doesn't you get all right align and that's not the fallback you want
  735. # [06:28] <dael> fantasai: We want a way to express that in shorthand so that declaration that makes the other lines go right gets thrown out by newer browsers
  736. # [06:28] <dael> s/newer/older
  737. # [06:28] <dael> fantasai: That gives us a migration forward. no one has come up with a good way to express this in the shorthand. We've asked for keywords and no one has come u p with one.
  738. # [06:29] <dael> fantasai: Unless there's a keyword, we're going to drop
  739. # [06:29] <dael> dbaron: It could be a / to seperate the first and the all/last
  740. # [06:29] <dael> fantasai: Maybe.
  741. # [06:29] <dael> dbaron: I'm fine dropping it
  742. # [06:29] <dbaron> s/Maybe./Maybe. ... would not be super-clear./
  743. # [06:29] <dael> RESOLVED: Defer text-align-first to level 4
  744. # [06:30] <fantasai> s/text-align-first/text-align-first and text-align: start-end/
  745. # [06:30] <fantasai> We are in need of an understandable keyword for start-end
  746. # [06:30] <dael> fantasai: And we have to go back to the soft break
  747. # [06:31] <dael> fantasai: Current spec says that text-align-last takes affect after every force break. If we want to say except line seperater we can.
  748. # [06:31] <dael> fantasai: line seperater is intended to be a soft break because it doesn't break to bidi pparagraph
  749. # [06:31] <dael> dauwhe: I found a unicode where line seperater corripond to HTML <break>
  750. # [06:31] <dael> clilley: But understanding of break is often wrong
  751. # [06:32] <dael> fantasai: We did compat and found that <br> is a paragraph seperator
  752. # [06:32] <dael> dauwhe: Can we apply a prop to break itself?
  753. # [06:32] <dael> plinss: Didn't we def break as replaced content?
  754. # [06:32] * Joins: zcorpan (~zcorpan@public.cloak)
  755. # [06:32] <dael> fantasai: my one concern is you have a bidi embedded...if you're doing a hard break it's a semantic break.
  756. # [06:32] <zcorpan> s/<break>/<br>/
  757. # [06:33] <dael> fantasai: If you have a multi-line quote and you might have an embedding and you don't want to break the embedding.
  758. # [06:33] <dbaron> s/quote/quote in poetry/
  759. # [06:33] <fantasai> s/embedding/embedding on the line breaks/
  760. # [06:33] <dael> dauwhe: I'll send out what I've been testing for this unicode character
  761. # [06:33] <dael> fantasai: I'm not sure line-seperator is a good option
  762. # [06:34] <dael> fantasai: I'm not sure it's not either.
  763. # [06:34] <dael> koji: Since most of these cases are for a single line, can we consider changing this to be last-line? The point I'm not sure is if we need the options.
  764. # [06:34] * Joins: yamamoto (~yamamoto@public.cloak)
  765. # [06:34] <dael> koji: I'm not sure if it wants to consider <br> as a line.
  766. # [06:35] <dael> dauwhe: So you might be okay with text-align-last not applying before first line breaks
  767. # [06:35] <dael> koji: From major use cases I'm fine
  768. # [06:35] <dael> fantasai: In Japan if you're just the very last line, if you have more text youw ant to jsutify all those.
  769. # [06:35] * liam hopes fantasai can justify that assertion
  770. # [06:35] <dael> fantasai: You'll find use cases where you want to justify all but the last line, but not the lines that are after a forsced break which isn't hte last line
  771. # [06:36] <dael> fantasai: So having it apply to all is right, though you might want something to restrict and not apply to the last line.
  772. # [06:36] <dael> dauwhe: I feel need to mull this over
  773. # [06:36] <dael> fantasai: WE can leave that there. We need another WD cycle anyway
  774. # [06:36] <dael> plinss: grapheme cluster termonology
  775. # [06:37] <dael> fantasai: So we've alises the term character to grapheme cluster so we can jsut say character
  776. # [06:37] <dael> clilley: And this has a lot of problems where people think that character means different things
  777. # [06:37] <dael> clilley: Logically you can say right is left, but it's still confusing
  778. # [06:38] <dael> fantasai: Character has a lot of means and we picked one definition
  779. # [06:38] * astearns proposes graphtainer
  780. # [06:38] <dael> fantasai: This gets word. i18n said people will be confused and you should use the right term
  781. # [06:38] * dauwhe graphenetainer
  782. # [06:38] <dael> fantasai: Having heard from James Clark about Tai letter spacing vs line break, we have to conclude there's two things we're talking about
  783. # [06:39] <dauwhe> s/Tai/Thai/
  784. # [06:39] <dael> fantasai: one is the grapheme cluster in regards to space and one is to line breaking
  785. # [06:39] <dael> clilley: And which is unicode?
  786. # [06:39] <dael> fantasai: Neither
  787. # [06:39] <dbaron> s/in regards to space/with regards to spacing/
  788. # [06:39] <dael> fantasai: unicode is trying to solve both problems, but targeting line breaking.
  789. # [06:40] <dael> fantasai: In order to do correct line breaking, you'll have to extend to meaning of grapheme cluster
  790. # [06:40] <dael> fantasai: Unicode allows for taloring for this case. They are aiming at the line breaking unit and the def they have is mostly there
  791. # [06:40] * Joins: zcorpan_ (~zcorpan@public.cloak)
  792. # [06:40] <dael> fantasai: Then we have spacing where in some cases it's larger than the grapheme cluster but in Thai it's smaller.
  793. # [06:40] <dael> fantasai: And some of those you have to deconstruct to construct correctly
  794. # [06:40] <liam> "lump"
  795. # [06:40] <dael> fantasai: So now we don't want character or grapheme cluster.
  796. # [06:41] <glazou> "graster"
  797. # [06:41] <dael> fantasai: So. Does anyone have suggestions?
  798. # [06:41] <glazou> "glazter"
  799. # [06:41] <zcorpan_> "mario"
  800. # [06:42] <dael> TabAtkins: At this point we're in the foo/bar territory
  801. # [06:42] <dael> dauwhe: Does first letter make this more complicated?
  802. # [06:42] * liam spray-paints the bike shed with "glyph cluster"
  803. # [06:42] <dael> fantasai: No I think it mostly uses line breaking.
  804. # [06:42] <Shinsuke> koji
  805. # [06:42] * Rossen_ WCHAR
  806. # [06:42] <dael> koji: We could go line-break point as grapheme cluster and define spaceing as something.
  807. # [06:43] * glazou it seems "graster" is trending :-)
  808. # [06:43] <dael> clilley: You could denife a new term so they have to look it up.
  809. # [06:43] <liam> LCBO is where we get da booze eh?
  810. # [06:43] <liam> (there is also the Beer Store)
  811. # [06:43] <dael> clilley: Letter Spacing break oppertunity is LSBO
  812. # [06:43] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  813. # [06:44] <dael> fantasai: So. Unless there are further suggestions we can move on.
  814. # [06:44] * dauwhe new rule: don't talk about CSS text on the last day of a F2F
  815. # [06:44] <dael> SteveZ: One comment. It seems to me the grouping is more important than the breaking aspect
  816. # [06:44] * dbaron suspects hober's friend is w3cmemes
  817. # [06:45] <dael> SteveZ: So I didn't like letter spacing break oppertunity and prefered talking of nature groups
  818. # [06:45] <dael> fantasai: Break opportunity is a break between these "things" and we need a name for the "things"
  819. # [06:45] <dael> fantasai: If you're reading this definition, I wanted a one sentence of what this property does
  820. # [06:45] <dael> SteveZ: How about unitary characters
  821. # [06:46] <dael> koji: You mentioned using HTML?
  822. # [06:46] * glazou if LCBO hosts a CSSWG ftf, can we do some testing ? :-D
  823. # [06:46] <dael> fantasai: It's different. I don't think they mean grapheme cluster
  824. # [06:46] <dael> TabAtkins: It's codepoint or scalor value. On or the other.
  825. # [06:46] <dael> zcorpan_: It's both in HTML. It's scalor if it can be, elsewise it' codepoint.
  826. # [06:47] <dael> TabAtkins: scalori s a subset of codepoint that exlused the lone surregate.
  827. # [06:47] <dbaron> s/scalori s/scalar value is/
  828. # [06:47] <fantasai> visually-perceived character and semantically-perceived character?
  829. # [06:47] <dael> TabAtkins: It's nto relevenet since I'm not talking about code points.
  830. # [06:47] <fantasai> (Unicode calls Grapheme clusters "user-perceived characters")
  831. # [06:47] <dael> zcorpan_: HTML is complicated because it wants scalors and codepoints
  832. # [06:48] * liam not sure that's appropriate for e.g. Hindi
  833. # [06:48] <dael> dbaron: So how about creating CSS charaters
  834. # [06:48] <dbaron> s/CSS charaters/the term "CSS character"/
  835. # [06:48] <dael> hober: CSS character would be confusing witht he ch
  836. # [06:48] <dael> fantasai: I think it's a problem with parsing
  837. # [06:49] <dael> TabAtkins: I changed all references from character to codepoint
  838. # [06:49] <dael> clilley: The reason there was a link to character, is that he thought that he would use an existing definition
  839. # [06:49] <dael> fantasai: He picked a different definition and didn't realize that.
  840. # [06:49] * liam thinks we could have shady characters and shifty characters
  841. # [06:50] <dael> fantasai: Anyways. i'm gonna put up a chart on the whiteboard and over the next break you can add suggestions
  842. # [06:50] <dael> koji: No opposition to CSS characters?
  843. # [06:50] * astearns we could follow terrible html terms and use 'palpable character'
  844. # [06:50] * dbaron thinks the Earl of Gloucester is an important character (in King Lear)
  845. # [06:50] <dael> fantasai: There isn't a dominant one, really. We need two terms.
  846. # [06:50] <zcorpan_> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#unicode-code-point was what i was thinking about. not called "character" though
  847. # [06:50] <zcorpan_> actually it is "character"
  848. # [06:51] <dael> fantasai: What's next?
  849. # [06:51] <clilley> palpatine character? yes emperor
  850. # [06:51] <dael> plinss: Def text-justify: auto
  851. # [06:51] * Joins: murakami_ (~murakami@public.cloak)
  852. # [06:51] * zcorpan_ TabAtkins ^
  853. # [06:52] * TabAtkins zcorpan, Yeah, so it's "code point". ^_^
  854. # [06:52] * clilley wonders if plane 14 language switching codes are 'palpable'
  855. # [06:52] * TabAtkins with some editorial magic that lets him talk about code units and code points interchangeably and have it do what he means.
  856. # [06:53] <dael> [spec text being projected]
  857. # [06:53] <liam> [text-justify - at one point i'd proposed (and the wg accepted) a property to let the user ask for a named justification/line-breaking] algorithm
  858. # [06:53] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
  859. # [06:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013
  860. # [06:54] <dael> fantasai: The issue was...(link above)
  861. # [06:54] <dael> fantasai: I believe this is text-justify: auto being more international one.
  862. # [06:54] <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-57
  863. # [06:54] <dael> koji: 57 where there was feedback that we accepted
  864. # [06:55] <dael> fantasai: The i18n group wanted us to be more explicite about UA doing the right thing in all cases
  865. # [06:55] <dael> fantasai: Current state is that if you don't spec a language tag on your text is uses western justification
  866. # [06:55] <dael> fantasai: This is aproblem for CJK texts because there's no spaces and that we dropped text-justify: interideographic in favor of auto
  867. # [06:56] <dael> fantasai: But there's pages out there that use auto assuming it's work for CJK.
  868. # [06:56] <dael> fantasai: We said where UA if possible sure use the approapriate spacing for the text, but we added a better example.
  869. # [06:56] <dael> fantasai: [reads example 10 text]
  870. # [06:57] <dael> fantasai: That will cause CJK pages that set text-align: justify to start justifying which I hope wouldn't break anything.
  871. # [06:57] <dael> fantasai: We go futher saying if you know the content language you can be more sophisticated.
  872. # [06:57] <dael> clilley: I like that it includes English as a more specific thing. Can you remind me of the letter definition
  873. # [06:58] <dael> fantasai: So it's a grapheme cluster where it's not spaces, not punctuation, not whatever the n catagory way
  874. # [06:58] <dael> fantasai: I want to go oevr this with impl to see if it's okay or if they want more explict text, or if they won't justify CJK without a languge tag...
  875. # [06:58] * zcorpan_ TabAtkins if it were then the html spec would just say "code point" instead of being complicated. but whatever
  876. # [06:59] <dael> clilley: This appears to only be for unrecognized language. So this allows them to do this for any language. So this is only about special languages where you don't have something for it
  877. # [06:59] <dael> fantasai: We want UA to justify with CJK spacing by default
  878. # [06:59] <dael> clilley: And that's testable and I like that.
  879. # [06:59] <dael> fantasai: So I wanted to hear from impl what they think.
  880. # [06:59] * TabAtkins zcorpan_: Nah, the editorial magic is useful. But still, the actual set of things he's referring to are codepoints.
  881. # [06:59] <dael> SteveZ: What happens for languages like arabic which don't put spaces?
  882. # [07:00] <dael> fantasai: What happens is with arabic you put spaces and just at spaces. for Thai if there's a space you just at that space and if there isn't you would expand between clusters
  883. # [07:00] <dael> fantasai: The requires a 2 level justufucation algorithm.
  884. # [07:00] <dael> clilley: So that algorythm is wrong for Thai?
  885. # [07:00] <dael> fantasai: Thai spaces between grapheme clusters.
  886. # [07:00] <dael> fantasai: Word spereators are characters
  887. # [07:01] <dael> SteveZ: So it's letter spacing
  888. # [07:01] <dael> dbaron: This is when there's no language tag. So it would be useful to have more clear req. here.
  889. # [07:01] <dael> dbaron: I think the current text assume the impl knows more about world lang thant hte spec author and that's not usually the case.
  890. # [07:01] <dael> dbaron: It won't be wide knowledge.
  891. # [07:02] <dael> dwim: I did text-justify in Blink and I can do English and Korean, but I don't know arabic and what they pref. More spec. cases are needed.
  892. # [07:03] <dael> fantasai: If you impl primaryily expanding word seperators alsong with secondary expanding, you get there. But if we have an impl that has better knowledge I want them to be able to do that
  893. # [07:03] <dael> clilley: So could choose needs to be changed. This is the minimal. So a test with a nonsense lang is needed.
  894. # [07:03] <dael> dbaron: So it's also useful to say when there's a lang spec.
  895. # [07:03] <dael> fantasai: It's here.
  896. # [07:03] <dael> dbaron: That's not much.
  897. # [07:04] <dael> dbaron: I think the spec is unclear enough it'll be ignored. So if not ignored you should spec.
  898. # [07:04] <dael> clilley: You remove the part that says ex 10 and you make it non-mornative. People with good knowledge of second language, you let them do that with your second sentence
  899. # [07:04] <dael> fantasai: We want the UA to use a universal comprimise, but it can be more specific.
  900. # [07:05] <dael> clilley: So make it normative by saying this is the minimal required. Say from primarily onwards this is the baseline.
  901. # [07:05] * liam q+
  902. # [07:05] <dael> koji: But than what's minimal. Can you swap secondary and primary?
  903. # [07:05] <dael> zcorpan_: You can also say if you have better, give me feedback?
  904. # [07:05] <dael> glenn: I like it as is
  905. # [07:05] <dael> zcorpan_: Is there a problem with spacing between characters in english
  906. # [07:06] <dael> fantasai: Yes. I fyou haev a mix of CJK and other on the line, you want to spec between characters.
  907. # [07:06] <dael> liam: There's a problem in german. Letter spacing is used for emphasis.
  908. # [07:06] <dbaron> s/spec between characters/space between the CJK characters and not the English; you could space between the English as a tertiary measure/
  909. # [07:06] <dael> liam: A year ago I had an action item, I had sent a prop to let the author to name which alg they want for line breaking and that was for CSS 4 text.
  910. # [07:07] <fantasai> dbaron, maybe adding "and should, at minimum, adequately handle both Western and non-Western scripts by default" ?
  911. # [07:07] <dael> liam: I hadn't realized I had that action, I'll rewrite the propsal for advanced linebreaking and some of this could be refered to such a property
  912. # [07:07] <fantasai> [insert example here]
  913. # [07:07] <dael> clilley: It could be useful.
  914. # [07:07] * Joins: Rossen__ (~Rossen@public.cloak)
  915. # [07:08] <dael> liam: Maybe you wen're on he call, but the goal was, when you do a better line-breaking a lot of the research has been print and it goes wrong for screen.
  916. # [07:08] <dael> liam: If you use the line-breaking algoritm and you edit the text, you insert your pointer and type so the dynamic makes you pointer move up and down by a few lines.
  917. # [07:08] <dael> liam: That's not accepable.
  918. # [07:09] <dael> liam: I was going to let you say you plan to edit this and do that shortly before you start the editing. That would tell the user agent you accept the text as is and don't refind line breaking. For print you can optimize just a few lines.
  919. # [07:09] <dael> liam: Than you get something that's slightly better. Being about to say an end is useful for several languages.
  920. # [07:09] <dael> fantasai: Any further comments on this?
  921. # [07:10] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  922. # [07:10] <dael> koji: A comprimise that's not suboptimal for CJK so IE will have some justification issues for quality.
  923. # [07:10] <liam> [ proposal from last March - http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html ]
  924. # [07:11] <dael> koji: You have something optimal for CJK and now we're removed it. If language isn't spec it's suboptimal for CJK.
  925. # [07:11] <dael> fantasai: CJK is secondary anyway because if you have a line with a spac you just the spac. JL rec says that already.
  926. # [07:11] <dael> fantasai: I think it compresses instead of expand.
  927. # [07:11] <dael> koji: Compressing is okay. Expanding... Anyway.
  928. # [07:11] <dael> koji: Since we're talking line breakign changes anyway.
  929. # [07:12] <dael> fantasai: dbaron did you see the IRC text?
  930. # [07:12] * dauwhe high-end typesetters often have rules that you can only reduce letter- and word-spacing to justify text, never increase space.
  931. # [07:12] <dael> dbaron: It's so far from what an impl would write. This spec is sayin do a pile of research.
  932. # [07:12] <dael> clilley: If you want.
  933. # [07:12] <dael> fantasai: I had more spec and people said they don't want more spec.
  934. # [07:12] <dael> clilley: I was pushing for more specific.
  935. # [07:12] <dael> fantasai: I can't please both directions.
  936. # [07:13] <dael> SteveZ: The main comment I wanted to make is whatever you write should be testable and some things I heard didn't sound testable
  937. # [07:13] <dael> fantasai: Auto is to "do the right thing" and we don't say what that is
  938. # [07:13] <dael> SteveZ: Which makes it hard to test and get interop
  939. # [07:13] <dael> fantasai: I'll need 6 montsh research to spec the right thing plus a research budget.
  940. # [07:14] * liam thinks there might be travel advisories against travel to thaland this week, sorry
  941. # [07:14] <dael> fantasai: I can't give yout he alg.
  942. # [07:14] <dael> dbaron: So how should impl?
  943. # [07:14] <dbaron> s/impl/implementors do it/
  944. # [07:14] <dael> Rossen__: So why is it in the spec
  945. # [07:14] <dael> fantasai: Because we need to say a baseline of how to justify.
  946. # [07:15] <dael> fantasai: I don't have the answers and I've been doing this for 10 years. If you want an algorithm, I don't have it.
  947. # [07:15] <dael> fantasai: I don't have actionable requests.
  948. # [07:15] <dael> fantasai: I can answer spec questions, but if you want a step by step algorithm, I can't do that.
  949. # [07:15] * glazou let's clusterize everything
  950. # [07:15] * fantasai you mean grasterize, right? :)
  951. # [07:15] * fantasai thanks Steve :)
  952. # [07:15] <dael> SteveZ: I thought I heard two things useful.
  953. # [07:16] * liam "thought"?
  954. # [07:16] * glazou fantasai don't tempt me :-D
  955. # [07:16] <dael> SteveZ: 1 was clilley point that we need a nonesense language to test and 2nd we need an algorithm that processes that nonsense lang which I thought was prioritize existing spaces or use letter spacing
  956. # [07:16] <dael> SteveZ: That's testable
  957. # [07:17] <dael> SteveZ: Outside the nonsense language you can't test because people may have heuristics that let them do a better job
  958. # [07:17] <dbaron> https://www.rfc-editor.org/rfc/rfc6919.txt has "SHOULD CONSIDER" which seems to match this case
  959. # [07:17] * plh proposes klingon to test justification
  960. # [07:17] <dael> fantasai: There's simple cases where we can say you should get this result
  961. # [07:17] <dael> fantasai: But we can't say here's the algorithm you must use.
  962. # [07:17] * glazou plh, eh css is more complex than klingon ;-)
  963. # [07:18] <dael> fantasai: So we can say here's a praragraph of latin words with spaces and we can test if it's been handled correctly. And than do 5 CJK characters in a 6em box and than Thai and than etc. We can't test script mixing because people will want to have different priorities
  964. # [07:18] <dael> fantasai: So we can test, but we can't spec more than a few outputs on a test case.
  965. # [07:18] * hober glazou plh: klingon's justification rules are the same as english
  966. # [07:18] * glazou wonders how to write "grapheme cluster" in klingon though
  967. # [07:18] <dael> fantasai: I can say you should have these outputs, but nothing more spec.
  968. # [07:19] <clilley> "I can't define justification, but I know it when I see it"
  969. # [07:19] <dael> dbaron: This sounds hard to jsutify spending time on because we'll write some code, someone will tell us it's wrong, we have to re-write and on and on and we may as well stick witht he western behaviour
  970. # [07:19] * plh notes to David that it's called "job security"
  971. # [07:19] <dael> clilley: That seems worse. Unless you're well known you get english.
  972. # [07:19] <dael> TabAtkins: If you're not known you have to be a special case.
  973. # [07:19] * hober glazou: closest I an get is "Degh"
  974. # [07:20] <dael> clilley: Well the prose is something where her'es a good way for spacing in general and if there's special cases you can do that better.
  975. # [07:20] * hober (that means "symbol")
  976. # [07:20] <dael> fantasai: What are you asking me to do dbaron ?
  977. # [07:20] * glazou let's adopt Degh
  978. # [07:20] <dael> dbaron: I'm curious what other impl think they'll do. I'd rather have an alogrithm in the spec that's better than what we have and we can move toward and have something where if people say they think we can do better in their language, tell them they should get it in the spec.
  979. # [07:21] * liam wonders if it'd be better to have a set of justification-in-language-X documents?
  980. # [07:21] <dael> clilley: Yeah. So people will come with different opinions and this can get concensus of how things can be.
  981. # [07:21] <dael> plinss: This is sounding like counter-styles.
  982. # [07:21] <dael> zcorpan_: An algorithm in the spec that we know is wrong and can get feedback and importove is more likely to get interop
  983. # [07:21] <dael> zcorpan_: You can put in a bit note saying it's prob. wrong
  984. # [07:21] <dael> clilley: It's prob sub-optimal
  985. # [07:22] <dael> SteveZ: The Japaense layout req taskforce is the best to capture what you need and even they recognie that it's house styles. Don't assume there's a right way.
  986. # [07:23] <dael> dauwhe: We devote our lives to carefully justifying text. But we do a lot of hand tweeking for results and it's so immensely complicated and we're frustrated we have so little control over it.
  987. # [07:23] <dael> dbaron: I think broswers have different introp than formatters. We can more about interop
  988. # [07:24] <dael> dbaron: I don't consider it worth investing in something like this if it's complicated and won't lead to browser interop. I'm curious what others think
  989. # [07:24] <dael> Rossen__: I think your last sentence summerizes well We won't put in much without an interop result
  990. # [07:24] <dael> hober: If we spec something that's simplier to being worse in common cases, sure we could converge, but we don't want to if it's worse.
  991. # [07:24] <dael> fantasai: I don't htink we're prop you do worse. We're prop we do better in non-English
  992. # [07:25] <dael> fantasai: I don't htink introp of languages isn't the goal. We want the text to jsutify and look good, but exactly what it looks like we shouldn't obsess over. That'll vary and that's okay.
  993. # [07:25] <dael> dauwhe: I have no expections that every word will maintain across browsers
  994. # [07:25] <dael> fantasai: That's true jsut from different font librabries
  995. # [07:26] <dael> dauwhe: If font version changes it breaks justification. The smallest length can make large changes.
  996. # [07:26] <dael> plinss: There is an expectation that if I only change the browser, I should get the same thing
  997. # [07:26] <dael> dauwhe: That doens't happen today
  998. # [07:26] <dael> plinss: People want that.
  999. # [07:26] <dael> dauwhe: And this isn't text-align: justify, but othervalues of text-align
  1000. # [07:27] <dael> dbaron: If we start doing something that we think is better, someone will think it's worse and be furious and it's easier to point to a spec with some research than to say we thought this was better because we talked to the guy over here.
  1001. # [07:27] * liam says, f they're angry they can come and join the WG and help us fix it
  1002. # [07:27] <dael> fantasai: We want interop on if a line of text has been jsutified or not. Where it happens is less important.
  1003. # [07:27] <dael> fantasai: Right now if you have CJK and you justify, it's not right.
  1004. # [07:27] <dael> fantasai: That's how deep the spec should get.
  1005. # [07:28] <dael> dbaron: Thent he spec should require that.
  1006. # [07:28] <dael> dbaron: If that's what you want to solve it should be must level
  1007. # [07:28] <dael> fantasai: As far as an alogirthm, I can do a non-normative appendix, but I don't want people that have a better idea or different performance be locked into a browser-required alogrithm.
  1008. # [07:28] <dael> dbaron: That's fair
  1009. # [07:28] <fantasai> s/not right/left-aligned/
  1010. # [07:29] <dael> dauwhe: Plus that might take a 5 years for the algorithm
  1011. # [07:29] <Rossen__> s/dbaron: That's fair/Rossen__: That's fair/
  1012. # [07:29] <dael> plinss: Thinking back to counter styles, you mentioned that justification style is a hosue style so maybe at some point we want to name the prop to control all the properites of just and do it as an @ rule so people who want to be really specific can.
  1013. # [07:29] <dael> plinss: We can have our list of default parameters for these languages that are good starting points
  1014. # [07:30] <dael> dauwhe: That might be a good way of describing it.
  1015. # [07:30] <dael> fantasai: So not going to happen in the next year.
  1016. # [07:30] <dael> plinss: I'm sayin somewhere downt he road
  1017. # [07:30] <dael> fantasai: The algorithm will have different kinds of outputs.
  1018. # [07:30] <fantasai> s/year/6 years/
  1019. # [07:30] <dael> koji: Are we resolving this as adding a non-normative appendix?
  1020. # [07:31] <dael> fantasai: We're saing require what should be justified
  1021. # [07:31] <dael> koji: So liek the minimum
  1022. # [07:31] <jdaggett> frankly, one *could* spec text-justify: auto in infinite detail but as fantasai says, this would take a *lot* of research and probably wouldn't be completely relevant in the end
  1023. # [07:31] <dael> fantasai: These are justification oppotunities and if they exist you must do them. Would that work for you?
  1024. # [07:31] <dael> dbaron: I guess so. There's a bunch of things you said about where you know how to prioritize that should be in the spec.
  1025. # [07:31] <jdaggett> "ideal" justification is not something easily defined, there's typically "better for this use"
  1026. # [07:32] <dael> dauwhe: And hopefully the simple statements can be tested.
  1027. # [07:32] * glazou wants |text-transform: suffixize| for CSS WG dogfood
  1028. # [07:32] <jdaggett> to say that "this has already been done for print" is nonsense, a lot of print typography is manual tweeking up the wazoo
  1029. # [07:33] * fantasai :)
  1030. # [07:33] <dael> RESOLVED: Require which lines are justified even if justification method is not defined
  1031. # [07:33] <dael> plinss: next is arabic letters connecting between elements
  1032. # [07:33] <dbaron> jdaggett, but if fantasai is saying that the point of the text in the spec is to ensure that CJK text should be justified inter-ideograph when justify is specified, then the spec should at least require that
  1033. # [07:33] <dael> fantasai: So this was people taking a UL and formatting as inline elements and because there wasn't space all the arabic words jammed together.
  1034. # [07:33] * dauwhe jdaggett: most of the time spent in producing a book is manual adjustment of word, line, and page breaks.
  1035. # [07:34] <dael> fantasai: So if you format with no spaces the arabic elements run up together. We were discussing how to create boundries at the element boundry
  1036. # [07:34] <dael> fantasai: We could create a prop devoted to it, we could piggyback off of bidi isolation
  1037. # [07:34] <jdaggett> dbaron: sure, if specific requirements are being stated those should be detailed, agreed
  1038. # [07:34] <dael> fantasai: Or if you have non-0 padding or margin, you consider that shaping isolated
  1039. # [07:35] <dael> fantasai: This is about shaping behviour for scripts like arabic?
  1040. # [07:35] * plh sounds like we need justify: manual
  1041. # [07:35] <dael> glenn: What about arabic cuase the spaces to collapse
  1042. # [07:35] <dael> TabAtkins: It's not. Its the lack of space causes it to have text on text.
  1043. # [07:35] <dael> TabAtkins: Can you do a zero-width non-joiner? Is that sufficent?
  1044. # [07:36] <dael> fantasai: Yep. I think we can do that.
  1045. # [07:36] <jdaggett> plus any print justification algorithm is inherently offline and can do infinite automatic adjustments without worrying too much about rendering speed. this isn't true for browsers
  1046. # [07:36] <dael> fantasai: Let me pull up the thread.
  1047. # [07:36] <liam> [people do worry about formatting speed. Luckily there are very good very fast algorithms, but there are NP-complete corner cases for all of them]
  1048. # [07:37] <dael> fantasai: I thinkt hat would work if author is aware. If we want this in UA stylesheet or take affect automatically it wouldn't work, but I'm not sure we need that
  1049. # [07:37] <dael> fantasai: I can reply to the thread and ask if that's felt to be suffiecent.
  1050. # [07:37] <jdaggett> liam: but with browsers those algorithms need to execute in real-time on $25 devices
  1051. # [07:37] <plh> http://lists.w3.org/Archives/Public/www-style/2014Feb/0302
  1052. # [07:37] <jdaggett> it ain't the same!
  1053. # [07:37] <liam> jdaggett, yes, understood.
  1054. # [07:37] <dael> fantasai: Okay. Next?
  1055. # [07:37] <dael> koji: Control characters
  1056. # [07:37] <koji> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72
  1057. # [07:38] <dael> fantasai: We got a question from James Clark about why are we ignoring form feed, verical tab, and new-line characters?
  1058. # [07:38] <dael> TabAtkins: They're normalize out.
  1059. # [07:38] <dael> fantasai: You can stick them in the DOM
  1060. # [07:39] <dael> TabAtkins: Oh...neermind.
  1061. # [07:39] <dael> fantasai: Then ROc said mozilla has control character visiability prop, do we want that?
  1062. # [07:39] <dael> plinss: Some word processers let yo make spaces visible
  1063. # [07:40] <dael> fantasai: Then there was a reply saying that there was a section...[missed]
  1064. # [07:40] <dael> zcorpan_: But you can put it into the script afterwards
  1065. # [07:40] <dael> fantasai: But then it will work out in legacy
  1066. # [07:40] <dael> fantasai: So there's a legacy problem with pages that use control characters.
  1067. # [07:40] <dael> dbaron: But pages that are in UTF-8 can spec these control points
  1068. # [07:40] <dael> fantasai: Do we need to care in CSS?
  1069. # [07:40] <dael> clilley: no.
  1070. # [07:41] <dael> fantasai: So we say Zach Winburg's comment is our of spec.
  1071. # [07:41] <dael> fantasai: For the original comments, just say there's no reason too. They're formmating
  1072. # [07:41] <astearns> s/our of spec/out of scope/
  1073. # [07:41] <dael> glenn: Sometimes you want to see control codes. If you're doing arabic you want to see left or right marks and joiners, but not in the default
  1074. # [07:42] <dael> TabAtkins: mozilla has a display for invisble characters
  1075. # [07:42] <dael> zcorpan_: That was to catch errors
  1076. # [07:42] <dael> TabAtkins: Some times you want to display on purpose
  1077. # [07:42] <dael> glenn: Unicode has a block that has visual depiction symbols and some fonts support those for control groups
  1078. # [07:42] <dael> fantasai: Wasn't there a prop in GCPM?
  1079. # [07:42] <dael> glenn: You don't wnat to change the character content
  1080. # [07:43] <dael> clilley: Text transform doesn't
  1081. # [07:43] <dael> TabAtkins: That's a decent idea
  1082. # [07:43] <clilley> text-transform: control-visible
  1083. # [07:43] <dael> fantasai: And you can pick waht you want.
  1084. # [07:43] <dael> TabAtkins: We can add a keyword to replace Mozilla's propritary
  1085. # [07:43] <dael> zcorpan_: And would that be compat with showing spaces or tabs?
  1086. # [07:43] <dael> TabAtkins: This is what it would do.
  1087. # [07:43] <dael> zcorpan_: I thought it was just control, not spaces.
  1088. # [07:44] <dael> fantasai: So any suggestions on responding to this comment other than no change?
  1089. # [07:44] <dael> fantasai: Apperently we conflict with unicode, but I don't think we care.
  1090. # [07:44] <clilley> s/care/are
  1091. # [07:44] <dael> koji: I think the proposal also wants to treat things with whitespace. Is that reasonable to add?
  1092. # [07:45] <dael> koji: He's saying because HTML and Unicode do it's own thing we should.
  1093. # [07:45] <dael> koji: Form-feed character
  1094. # [07:45] <dael> fantasai: I don't have an opinion. We should do what browsers do which I'm guessing is not to display
  1095. # [07:45] <dael> koji: impl?
  1096. # [07:45] <dael> dbaron: I'm not sure.
  1097. # [07:45] <dbaron> s/dbaron/?/
  1098. # [07:45] <dael> fantasai: We can write a test
  1099. # [07:46] <dael> fantasai: it's invisible
  1100. # [07:46] <dael> fantasai: So I think that's what we're doing. And the sepc says don't render
  1101. # [07:46] <plinss> s/?/Rossen__/
  1102. # [07:46] <dael> koji: We don't have formfeed as whitespace
  1103. # [07:46] <dael> fantasai: no, it's a control character.
  1104. # [07:46] <dael> fantasai: Any other comments?
  1105. # [07:46] <dael> fantasai: I think that's all the text stuff
  1106. # [07:47] <dael> [break = 15 min]
  1107. # [07:49] * Quits: lmclister (~lmclister@public.cloak) ("")
  1108. # [07:56] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
  1109. # [07:58] * Joins: shans_ (~shans@public.cloak)
  1110. # [08:06] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1111. # [08:08] * Joins: zcorpan (~zcorpan@public.cloak)
  1112. # [08:10] <dael> Topic: split CSS3 Text
  1113. # [08:10] * dauwhe so...
  1114. # [08:11] <dael> koji: The basic issue is some properties are ready but some properties need more work
  1115. # [08:11] * clilley modules will be split, until morale improves
  1116. # [08:12] <dael> koji: I'm proposing the split the fast moving ones so they can go to CR while the other ones can stay in a different spec.
  1117. # [08:12] <dael> astearns: I'm all for splitting to different levels. You had prop at some point different modules
  1118. # [08:13] <dael> fantasai: My concern is the things we're chunning on are the things that are the highest priority, where as the things that are stable the 2.1 stuff is fine. So text-justify, line-break and word-break are the thigns the i18n care aboutt he most and the split would make them go slower.
  1119. # [08:13] <dael> fantasai: I think in this case I'd be against pushing that stuff to the next level
  1120. # [08:13] * glazou "Box model / Render tree ? No. sudo Box model / Render tree ? Ok." :-)
  1121. # [08:13] <dael> fantasai: That might mean it'll be another 3 to 6 months to CR, but I don't think it'll be more than that
  1122. # [08:14] <dael> fantasai: We need to do the eidts we discussed today, do a ne WD and do a few cycles of LC to get comments.
  1123. # [08:14] <dael> fantasai: And that's kinda what we're stuck on right now
  1124. # [08:14] <clilley> rrsagent, here
  1125. # [08:14] <RRSAgent> See http://www.w3.org/2014/05/21-css-irc#T06-14-32
  1126. # [08:14] <dael> koji: The size is quite large so half the properties we get almost 0 feedback so asking review of all the features every time doens't makes sense
  1127. # [08:15] <dael> fantasai: We can say what has changed since last LC and please focus on those things. i think if we split we'll have to do LC/CR for one and FPWD from the other and that takes longer.
  1128. # [08:15] <dael> plh: What about at risk?
  1129. # [08:15] <dael> fantasai: The thigns that are holding back we don't want to drop
  1130. # [08:15] <dael> glaz: You said FPWD was hard?
  1131. # [08:16] <dael> fantasai: It would take the focus away from the things that need work to the things that are stable and giong well. There's also a certain amount of editorial work and to keep the two drafts in sync.
  1132. # [08:16] <dael> fantasai: That won't make things go fasted except what's high priority
  1133. # [08:16] <dael> glaz: This is a level. We don't need everything in the other level. It's not versions.
  1134. # [08:17] <dael> glaz: You don't need to copy 3 into 4. 4 is an extension
  1135. # [08:17] <SteveZ> The AB (some time ago) advised that we do not produce delta specs
  1136. # [08:17] <dael> TabAtkins: You really do. You don't want delta specs.
  1137. # [08:17] <dael> fantasai: There's individuals that interact
  1138. # [08:17] <dael> glaz: That's the purpose of levels!
  1139. # [08:17] <dael> dauwhe: Is there a natural split? I want one-stop-shopping for text.
  1140. # [08:17] <SteveZ> Delta specs are not reader friendly
  1141. # [08:18] <dael> fantasai: I think this will jsut get text-indent and a few others to CR faster
  1142. # [08:18] <dael> koji: What happened to text-decoration is that the spec went to CR and impl starts. This will help us focus on the things left in the spec. I can see a lot of benefits
  1143. # [08:18] <dael> fantasai: If the high priority thigns were in the stable state I'd agree.
  1144. # [08:18] <dael> koji: But that helps me to move low priority to other specs.
  1145. # [08:19] <dael> hober: So you're saying that you should move the higher readiness to CR?
  1146. # [08:19] <dael> glaz: A few years ago we said if there are things that are slow and blocking we should remove them to antoher level
  1147. # [08:19] <dael> dbaron: But the ideal is we do that for things that are high priority.
  1148. # [08:20] <dael> fantasai: When we split text-decoration it's because it was long and there was a logical break. It turned out one part was faster, but I was expecting the same.
  1149. # [08:20] <dael> fantasai: There is a clear priority here. I want to concentrate on the high priority things.
  1150. # [08:20] <dael> koji: If half the CSS items are thigns we don't want, why keep them?
  1151. # [08:21] <dael> fantasai: It was in 2.1 plus a few minor extensions, plus hanging punctuation and I don't think hanging puctuation is worth it.
  1152. # [08:21] <dael> koji: There are 7 properties
  1153. # [08:21] <dael> glaz: Beurocratic isn't bad, it's editorial
  1154. # [08:21] <dael> fantasai: What are the 7 prop?
  1155. # [08:21] <dael> koji: [in irc]
  1156. # [08:21] <koji> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0121.html
  1157. # [08:22] <koji> Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation Lower: word-break line-break text-align text-align-last text-justify word-spacing letter-spacing
  1158. # [08:22] <koji> Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation
  1159. # [08:22] <dael> plh: Are the impl of those sever prop?
  1160. # [08:22] <dael> fantasai: Yes. Of all. The first 2 are in CSS 2.1, the next 2 have impl, hanging-puntuation is AH and text-indent is in CSS 2.1
  1161. # [08:23] <dael> fantasai: The lower 4 are high for i18n and ebook communities. If it'll take us 6 months or less it'll cause more confusion instead of benefit. We won't know why we pub two levels in 6 months.
  1162. # [08:23] <dael> glaz: We did that for selectors
  1163. # [08:23] <dael> fantasai: No, they were many years apart
  1164. # [08:24] <dael> glaz: We split levels 3 and 4 and we released CR when we did 4.
  1165. # [08:24] <dael> fantasai: But 4 isn't going to CR in multiple years.
  1166. # [08:24] <dael> fantasai: These properties should go in 6 months. I think it should be 6 months.
  1167. # [08:25] <dael> fantasai: Selectors 3 went to PR. Here we have a WD that we're taking to CR and creating a new one to also take to CR.
  1168. # [08:25] <dael> fantasai: We also have impl of everything that we're planning to defer.
  1169. # [08:25] <dael> fantasai: They all have impl.
  1170. # [08:25] <dael> Rossen__: So how confident are you in the 6 months?
  1171. # [08:26] <dael> fantasai: It depends on how much time I put in, but koji is also available so as long as we're actively responding, we should be able to
  1172. # [08:26] <dael> fantasai: We're not getting "redign this" feedback
  1173. # [08:26] * Joins: jcraig (~jcraig@public.cloak)
  1174. # [08:26] <dael> koji: I think that's optimistic. Last time i18n asked for a 3 month extension to LC. To make CR in 6 months we have to do the WD in one or two months. That's tough.
  1175. # [08:26] <dael> Rossen__: So we're talking about longer.
  1176. # [08:27] <dael> koji: That's why i want to reduce the focus
  1177. # [08:27] <dael> fantasai: I wasn't really working on this for the last 6 months, koji was the only one working.
  1178. # [08:27] <dael> koji: I expect a lot of work.
  1179. # [08:27] <dael> dauwhe: Can w3c help focus i18n on this?
  1180. # [08:27] <dael> fantasai: I think that LC was during the holidays.
  1181. # [08:28] <dael> glaz: That's not a valid excuse. There's always holidays. We've even discussed this during a F2F.
  1182. # [08:28] <dael> fantasai: They're overloaded I think.
  1183. # [08:28] <dael> s/there's always holidays/they're always later
  1184. # [08:29] <dael> clilley: Part of their job is to check every spec everyone produces
  1185. # [08:29] <dael> koji: I can't imagine how one person could make all the test cases for this spec.
  1186. # [08:29] <dael> koji: I don't have an impl team.
  1187. # [08:29] <dael> plh: If we don't know we can get to rec in 6 months, why aren't we splitting?
  1188. # [08:29] * Joins: lmclister (~lmclister@public.cloak)
  1189. # [08:30] <dael> koji: We said CR. To PR I need help from impl.
  1190. # [08:30] <dael> hober: CR is an offical call for impl. What's stopping us from unofficially asking we'd like people to impl
  1191. # [08:30] <dael> fantasai: They're impl already.
  1192. # [08:30] <dael> hober: So then why haven't I heard of a call for impl?
  1193. # [08:30] <dael> dbaron: And if there was a CR we'd feel more confident.
  1194. # [08:31] <dael> clilley: CR gives a message of stability. There's no patitent difference. You can CR in 0 time. If you have full pass test suite you don't have to go to CR if you've met the exit criteria
  1195. # [08:31] <dael> clilley: You just need a test suite that passes
  1196. # [08:31] <dael> koji: What happened to text decoration is that once it got to CR it was picked up. I think CR gives a good message
  1197. # [08:32] <dael> fantasai: What on this list would you pick out?
  1198. # [08:32] <dael> dbaron: I think we would impl the stuff in the lower list.
  1199. # [08:32] <dael> fantasai: I don't see a benefit of taking the higher level stuff to CR.
  1200. # [08:32] <dael> fantasai: text-indent maybe, but no one is super excited. Maybe hinging punctuation for CJK, but that's one property.
  1201. # [08:33] <dauwhe> s/hinging/hanging/
  1202. # [08:33] <dael> fantasai: The things people are really waiting on are the thigns in the lower list. Those are the ones that a transition to CR would make a difference and the split will slow them getting to CR at least somewhat. It will add time.
  1203. # [08:34] <dael> fantasai: Making sure it's all coherent and ther's intro text. It's easy to cut things out, it's hard to pull things out and make it fit together. That takes time and it's not worth spending without a beneit and I don't think we would get a benefit.
  1204. # [08:34] <dael> clilley: Splitting won't help in any way. I think fantasai gave a good demistration of that.
  1205. # [08:34] <dael> glaz: Is there concensios.
  1206. # [08:34] <dael> RESOLVED: No change
  1207. # [08:34] <Rossen__> s/demistration/demonstration/
  1208. # [08:34] <dael> Topic: web-platform-tests and csswg-test github
  1209. # [08:35] <dael> plh: I don't know how familair people are with testing we have and the differences between the two
  1210. # [08:35] <dael> plh: How much detail should I go into?
  1211. # [08:35] * fantasai note to Dael, in the previous conversation, might be useful to cut/paste the lists from Koji's email into the minutes
  1212. # [08:36] <dael> plh: With webplatform tests contains test suits for abourd 60 spec from 6 WG. THe goal is actually to make the web work. It might sound crazy, but that's the goal and there's imput to make that work
  1213. # [08:36] <dael> plh: There's high activity on that at the moment. At the moment ?? from Mozilla is doing fantastic work to get it to work on Firefox. My hope is by end of year we'd get results from browsers
  1214. # [08:36] <zcorpan> s/??/James Graham/
  1215. # [08:36] <astearns> s/??/jgraham/
  1216. # [08:36] * glazou fantasai koji pasted the two lists into IRC
  1217. # [08:37] <dael> plh: So you put a test into the suite and overnight you get results.
  1218. # [08:37] <dael> plh: That would be very useful for WG to get the raw test results. That's the goal. The problem is it wan'ts to cover CSS as well
  1219. # [08:37] <dael> plh: By running the tests it's also web tests. and there's ongoing work to be able to write a webdriver test as well
  1220. # [08:38] <dael> plh: So theres' a huge advantage to haveing CSS. The CSS test repo is a mirror of mecurial. I'd assume this group is more familair than me.
  1221. # [08:38] <dael> plh: So there's discussion about how to get them to interact. There's 3 proposals.
  1222. # [08:38] <dael> plh: 1 is to make a simple solution. Make the CSS repo a sub of webplatformtest
  1223. # [08:38] <dbaron> s/sub/submodule/
  1224. # [08:39] <dael> plh: So if you want to maek a publich test you make it on the CSS repo. On the pro it's easy, on the con it's confusing because people can't pull requests from the same place. Right now webplatform is using a review different system than CSS
  1225. # [08:39] <astearns> s/publich test/pull request/
  1226. # [08:39] <zcorpan> s/review different system/different review system/
  1227. # [08:40] * hober does anyone who didn't formerly work at opera actually like critic?
  1228. # [08:40] <dael> plh: The third that can be argued the most is we have different requirements. webrepo placed the bar low to favor test submission.
  1229. # [08:40] <dael> plh: The seoncd solution is to have the repo as a subtree. The problem is you would have two systems and you could send pull requests to both.
  1230. # [08:40] <dael> plh: We're used to dealing with one place and we'd have to look at two with different test requirements
  1231. # [08:41] * zcorpan hober i think darobin said he started to like it but maybe i wasn't allowed to cite him on that. i might misremember him for someone else also, but still
  1232. # [08:41] <dael> plh: Third solution is to say we're not going to try and integrate.
  1233. # [08:41] * hober zcorpan: :)
  1234. # [08:41] <dael> plh: People will send submitters to webplatform test and in order to satisfy the requirements it'll have to move to the reposity by the same or a different person
  1235. # [08:41] <dael> plh: So it would be submit your test to the webplatform and than the CSS will reask
  1236. # [08:42] <dael> plh: CSS platofrm does have tools that the webplatofrm doesn't have. The whole system we have on ED is all on the CSS test repo and you wouldn't get that on webplatform until written.
  1237. # [08:42] <dael> clilley: That was discussed this morning.
  1238. # [08:42] <dael> plh: I'm talking about a bigger rewrite
  1239. # [08:42] <dael> plinss: I was giong to clean up, but not fundimentally re-write
  1240. # [08:42] <dael> clilley: I misunderstood
  1241. # [08:43] <dael> plh: To finish, we don't have everyone in the room, but we can start by saying are the opinions, what to test contributors want to see?
  1242. # [08:43] <dael> plh: At the end of the day with webplatform test we can let people submit test and merge into CSS test repo that's fine.
  1243. # [08:44] <dael> plh: Do people have opinions, do they care at the moment?
  1244. # [08:44] <dael> zcorpan: My opinion is that people should be able to make a pull request to webplatform tests for when they want to add CSS tests and not have to put in the meta data that the CSS WG req for their tests
  1245. # [08:44] <dael> zcorpan: How the syncing works I have less opinons
  1246. # [08:44] <dael> plinss: Without some fundimental metadata we won't get use from the test.
  1247. # [08:45] <dael> plinss: The fundimental dicodomy is that the stated goal of the webplatform is to get better tests, but they don't care about getting specs to REC and we do
  1248. # [08:45] <dael> zcorpan: There is some meta data to annotate which tests to which section. You put it in a directory and it annotates it for a particular section.
  1249. # [08:46] <dael> plinss: I don't care about what form the meta data is in, but I'm saying we need to to exist. And if you're promising our minimum of meta data we can work witht hat
  1250. # [08:46] <dael> zcorpan: Right
  1251. # [08:46] <dael> plinss: Biggest problem is tracking issues. Where are the bugs going to be filed and where tracked and if we're copying back how will people know where to look
  1252. # [08:46] <dael> hober: We already have that problem.
  1253. # [08:47] <dael> plinss: But at least we haev a system. There's even less information about where we'll track information for the tests.
  1254. # [08:47] <dael> plh: We have a tracking per WG and er system that's automatically
  1255. # [08:47] <dael> plh: I can tell you the number of tests and pull requests we have to each spec. You mentioned that it didn't care about getting to REC and you're right.
  1256. # [08:48] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
  1257. # [08:48] <dael> plh: But WG can use it to get to rec and that's good enough. If we can get test results from three or four browsers that great.
  1258. # [08:48] <dael> astearns: I think the most important thing is one place to submit for any webplatform tests. So any one place that takes difference and reviews differences is a big thing
  1259. # [08:49] * Joins: jcraig (~jcraig@public.cloak)
  1260. # [08:49] <dael> plh: If we do that there's a lot of work to be done. most of the CSS tests re manual so they'll have to be run manually which takes time.
  1261. # [08:50] <dael> plh: It may will be that we have an appraoch like with the presto where they have thier of github and we're trying to over time move thier tests to webplatform and than remove them from the original repository. We'll be sucessful when that's 0, but it'll take us a while.
  1262. # [08:51] <dael> astearns: So. I'm much more concerned with getting test solutions than having a single place to track issues and reviews. I jsut want the tests.
  1263. # [08:51] <dael> astearns: I'll accept multiple processes and the headaches to get bigger test suites.
  1264. # [08:51] <dael> astearns: I thought we decided as long as a review happened, it didn't matter where. It jsut mattered that it was tracked.
  1265. # [08:52] <dael> astearns: There could be a review in many places and we can deal with having the headache of having these mulitple ways as long as we get more tests in the test suite.
  1266. # [08:52] <dael> zcorpan: Multiple reviews thing is already an issue in webplatform without CSS
  1267. # [08:52] <dael> astearns: And it's an issue in CSS
  1268. # [08:52] <dael> plinss: I have a plan to sync our systems
  1269. # [08:52] <dael> astearns: And if you get to it great. If not that's fine.
  1270. # [08:53] <dael> plinss: I don't know how to sync those three and another repo. It sounds like a nightmare, but maybe it's possible.
  1271. # [08:53] <dael> plinss: fundimentally from one aspect I don't care and don't want to worry about this stuff. If we had an all in one we can use I'd be happy, but we don't. The other systems out there don't meet our needs. they don't help use get the specs to REC.
  1272. # [08:54] <dael> plinss: And they'ren ot offering to help us with the needs beyond what they're acknoledged.
  1273. # [08:54] <dael> astearns: But getting to REC means sufficent tests and I don't have any evendence that any tools help us get to rec
  1274. # [08:55] <dael> plinss: But what we have is multi test suites so we can run against things becides browers. We accpet from other sources and fold them into an area to generate the data to get us to REC. That's not from sheppard.
  1275. # [08:55] <astearns> s/any tools/critic *or* shepherd/
  1276. # [08:55] <fantasai> s/multi/multi-format/
  1277. # [08:55] <dael> plinss: I'm all for trying to blend, but I don't want the throw out the baby with the bathwater and make it harder to get specs done. If we can bring thigns together and get them in one place, but still keep going, that's great.
  1278. # [08:55] * Quits: lmclister (~lmclister@public.cloak) ("")
  1279. # [08:56] <dael> plinss: I don't know what the right step is. If it's sub trees and pulling from different places or if it's submodules
  1280. # [08:56] * Joins: Ms2ger (~Ms2ger@public.cloak)
  1281. # [08:56] <dael> astearns: If all tests were in same repsoitory and we have our system or our tess and the tess in W3C and their tests do what they want, maybe the competition will move fast
  1282. # [08:57] <dael> plh: And we tried to be highly modular and they're likely to try and impose every bit of the system
  1283. # [08:57] * Ms2ger "tess"?
  1284. # [08:57] <dael> plinss: The other problem is there's a lot of histroical review data we would lose or have the track seperatly
  1285. # [08:57] <dael> s/tess/test
  1286. # [08:58] <plh> s/likely/not likely/
  1287. # [08:58] <dael> plinss: I don't want to lose that information. Tests have to be good tests of they make our jobs harder. If the webplatform can live with use in a subdirectory we can do that and maintina our own repo for as long as we need to. But I don't know if that will fly
  1288. # [08:58] * dbaron wouldn't mind spending 15 minutes on a position:sticky interop issue (which I realize might be good to do while we have a whiteboard)
  1289. # [08:58] <Ms2ger> I don't think that improves the situation.
  1290. # [08:59] <dael> plh: I think we've done as much as we can on this topic
  1291. # [08:59] <dael> plinss: There are questions about if putting all CSS in a subdirectory is good enough
  1292. # [08:59] <dael> plh: I don't have an answer. I think there are some people who don't like this approach
  1293. # [08:59] <Ms2ger> My personal answer to that is "no"
  1294. # [08:59] * Ms2ger plh ^
  1295. # [08:59] * fantasai answer to which question?
  1296. # [09:00] <dael> Topic: annotate url() with "crossorigin" "integrty" etc.
  1297. # [09:00] * fantasai nm
  1298. # [09:00] * SteveZ It is midnight here. My coach has turned into a pumpkin and me with it. Good night!
  1299. # [09:00] <dael> zcorpan: So yesterday ?? talked about an ability to to give attr to a url in CSS
  1300. # [09:00] * krit SteveZ night!
  1301. # [09:00] * liam night SteveZ
  1302. # [09:00] <dael> zcorpan: It doesn't have to be url. I mean the functionality
  1303. # [09:01] <TabAtkins> s/??/Anne van Kesteren/
  1304. # [09:01] * fantasai 'night Steve! Thanks for staying up with us
  1305. # [09:01] * dauwhe waves goodbye
  1306. # [09:01] * krit is someone talking?
  1307. # [09:01] <fantasai> s/be url/be url() function/
  1308. # [09:01] <SteveZ> bye
  1309. # [09:01] * krit can't here anything
  1310. # [09:01] <dael> zcorpan: In HTML you can do <link rel=stylesheet href=http:// a/b crossorigin=anonymous>
  1311. # [09:01] * TabAtkins zcorpan was drawing on the board
  1312. # [09:01] * krit ah now
  1313. # [09:01] * liam - there was a gap
  1314. # [09:01] * Quits: SteveZ (~SteveZ@public.cloak) ("Page closed")
  1315. # [09:02] <dael> zcorpan: In this case you can read the stylesheet data in CSSOM but without crossorigin you can't read it.
  1316. # [09:02] <dael> zcorpan: So today with @import you cannot annotate the url with the crossorigin. You can have a media here, but the media piece is missing.
  1317. # [09:02] <krit> zcorpan: Is that just about Stylesheets or other resources like images as well?
  1318. # [09:02] <dael> zcorpan: So import stylesheets can't be read in CSSOM
  1319. # [09:03] <dael> zcorpan: What it's asking for is some way to spec a crossorigin.
  1320. # [09:03] <dael> zcorpan: There's also a spec called sub resource integrity which takes and integrity attr
  1321. # [09:03] <astearns> http://w3c.github.io/webappsec/specs/subresourceintegrity/
  1322. # [09:03] <dael> zcorpan: And the user can compare the downloaded hash with the spec hash and they prob. want to use this is CSS as well.
  1323. # [09:03] <dael> zcorpan: So how?
  1324. # [09:04] <dael> zcorpan: You can't put anything ins url() but we can come up with some other fucntion like newurl("...", crossorigin...);
  1325. # [09:04] * Joins: jh (~jh@public.cloak)
  1326. # [09:04] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  1327. # [09:04] <dael> zcorpan: I don't have a concrete prop for how to do this, but I wanted to see what people thing.
  1328. # [09:05] <dael> glaz: To be sure I understand, current behaviour of linking, we can link to any stylesheet from anywhere. If this is going to be changed without crossorgin, you won't be able to reach across, right?
  1329. # [09:05] <dael> dbaron: No the issue you can't acces without crossorigin.
  1330. # [09:05] <dael> zcorpan: You should be able to opt-in to loading and accessing
  1331. # [09:05] <dael> glaz: This is a change
  1332. # [09:05] <dael> zcorpan: It's a new feature.
  1333. # [09:05] <dael> plinss: I haven't read up on crossorigin, but I'm assuming it's more than having the attr that makes it accessible
  1334. # [09:06] <dael> zcorpan: Yeag
  1335. # [09:06] <dael> TabAtkins: Relatively easy. There's already been a lot of work done.
  1336. # [09:06] <dael> plinss: It'll depend on the responce of the server.
  1337. # [09:06] <dael> zcorpan: Yeah. If you try and link and spec and if the server doesn't support...
  1338. # [09:06] <hober> something like link(<url> <plist>?) (where <plist> is [<ident> <string>]+) e.g. link(http://a/b crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200")
  1339. # [09:06] <dael> plinss: So you're requiresting that the browser does thing
  1340. # [09:06] <dael> zcorpan: If the server doesn't support cores you'll get an error
  1341. # [09:07] <glazou> s/reach across/reeach the OM
  1342. # [09:07] <dael> plinss: You don't get the style sheet? Not just you don't get access?
  1343. # [09:07] <dbaron> s/cores/CORS/
  1344. # [09:07] <dael> zcorpan: Yes. If you opt into I want cores and it doesn't support you get a network error
  1345. # [09:07] * Joins: adenilson (~anonymous@public.cloak)
  1346. # [09:07] <dael> plh: One question if when you function you'll need to have some questions about lazyload.
  1347. # [09:07] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
  1348. # [09:07] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1349. # [09:07] <dael> hober: If you look at my IRC syntax and you accept aribrary.
  1350. # [09:08] <dael> plh: That would work.
  1351. # [09:08] <glazou> s/cores/CORS
  1352. # [09:08] <dael> zcorpan: I think your prop needs quotes for parsing, but is fine
  1353. # [09:08] <dbaron> s/your/your (hober's)/
  1354. # [09:08] <hober> so link(<url> <plist>?) (where <plist> is [<ident> <string>]+) e.g. link("http://a/b" crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200")
  1355. # [09:08] <dael> dbaron: I think this is fine if we come up with a good name for it.
  1356. # [09:09] <dael> zcorpan: So we have link. Any other ideas?
  1357. # [09:09] <dael> dbaron: Or href.
  1358. # [09:09] <dael> fantasai: Are we using this for anything but @import?
  1359. # [09:09] <dbaron> ... because there's precedent, not because it's any good
  1360. # [09:09] <dael> zcorpan: Yeah.
  1361. # [09:09] <dael> fantasai: For images we can put in the image function.
  1362. # [09:09] <dael> hober: The generic case is just slightly worst than current syntax
  1363. # [09:10] <dael> TabAtkins: One poss is we play with parsing for " URLs can take arguements after.
  1364. # [09:10] <dael> hober: So no new function
  1365. # [09:10] <dael> TabAtkins: You would have to fo " or you're get an error
  1366. # [09:10] <krit> what about a core() function?
  1367. # [09:10] <krit> cors(<url> | image, CORS arguments) ?
  1368. # [09:10] <dael> hober: I'm sympatetic to no new function, but I worry about I'm an author I hear of this awesome thing, but I don't look at if I " the URL
  1369. # [09:11] <dael> TabAtkins: So same scenario if we add a new prop though.
  1370. # [09:11] <dael> plinss: And if you're really niave you don't check if the serve supports CORS
  1371. # [09:11] <dael> dbaron: If you find a way to do TabAtkins prop you make URLs with quotes return as tokins
  1372. # [09:11] <krit> people love url()!!!
  1373. # [09:11] <krit> you can not get rid of it
  1374. # [09:11] <dael> TabAtkins: I think I can do this.
  1375. # [09:11] <dael> TabAtkins: It'll consume space until it find the quote
  1376. # [09:12] <dael> dbaron: It's the URL without " tokin that's crazy so this will work.
  1377. # [09:12] <fantasai> s/tokin/token
  1378. # [09:12] <dbaron> s/tokin/token/
  1379. # [09:12] <dael> TabAtkins: Yeah. I want to get into the code to make sure but at this point I'm certain I can do this quick.
  1380. # [09:12] <dael> zcorpan: I like the URL with quotes idea.
  1381. # [09:12] <dael> fantasai: But you don't need multiple
  1382. # [09:12] <dael> TabAtkins: Everywhere a function can take a URL it can take a cross.
  1383. # [09:13] <dael> fantasai: I don't know about that. In SVG it uses a hyphin
  1384. # [09:13] <TabAtkins> s/cross/quoted string/
  1385. # [09:13] * dauwhe not nearly enough em-dashes in CSS syntax
  1386. # [09:13] <dael> hober: I love this idea of inhancing URL
  1387. # [09:13] * fantasai we resolved not to use beyond ASCII
  1388. # [09:14] <krit> what about image() ???
  1389. # [09:14] <dael> action TabAtkins figure out if inhancing URL works
  1390. # [09:14] * trackbot is creating a new ACTION.
  1391. # [09:14] <trackbot> Created ACTION-632 - Figure out if inhancing url works [on Tab Atkins Jr. - due 2014-05-28].
  1392. # [09:14] <liam> s/inhancing/enhancing/
  1393. # [09:14] * glazou so in fact the topic was "crossoriginize this"
  1394. # [09:14] * fantasai and em-dash is not ASCII
  1395. # [09:14] * krit glazou could you unmute me?
  1396. # [09:14] * astearns I loved "On Beyond ASCII" as a kid
  1397. # [09:14] <dael> TabAtkins: We'd build the resource integrty stuff alongside.
  1398. # [09:14] <dael> zcorpan: I don't expect the entegrity right now.
  1399. # [09:14] <glazou> done
  1400. # [09:14] <dael> krit: You're just talking about URL what about image.
  1401. # [09:14] <dael> hober: Image takes URL arguement so it's same thing
  1402. # [09:15] <dael> TabAtkins: Alternatly we could also allow these in image fucntion grammar.
  1403. # [09:15] <dael> fantasai: How often would we use this for images?
  1404. # [09:15] <dael> plinss: I think integrety would become popular for things like online banking
  1405. # [09:15] <dael> fantasai: I image it would in the HTML, but the CSS?
  1406. # [09:15] <dael> TabAtkins: We can always let you do it as URL and flatten it later if necessary
  1407. # [09:16] <dael> fantasai: Yes. I think it won't be used often for images.
  1408. # [09:16] * liam doesn't see why not
  1409. # [09:16] <dael> fantasai: Also it's more closely tied tot he network request rather thant the image proessing.
  1410. # [09:16] <fantasai> so fits better in url() than flattened into image()
  1411. # [09:16] <dael> plinss: So TabAtkins you'll come back to us
  1412. # [09:17] <dael> hober: If it doesn't work we can add the function
  1413. # [09:17] <dael> Topic: grid/subgrid
  1414. # [09:17] <dael> Rossen__: Quick review
  1415. # [09:17] <dael> Rossen__: Grid is awesome.
  1416. # [09:17] <astearns> [whiteboard drawing]
  1417. # [09:18] <dael> Rossen__: The thing we can do with grid is you have a division of space and you have lines where you can size and have adaptive layout
  1418. # [09:18] <dael> Rossen__: The one thing it doesn't give you is grouping.
  1419. # [09:18] <dael> Rossen__: If you have items on the grid you want to group and attach behviour, you can't.
  1420. # [09:19] <fantasai> http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
  1421. # [09:19] <dael> Rossen__: For ex a simple form with a button and an input field for text. If you want to treat it as a group where text spans two cells and the button is one, but I want hover where the whole group is hovered, in order to deal witht hat we into subgrid
  1422. # [09:19] <dael> Rossen__: It behavies liek a semi-transparent item in the level of grid and the purpose is grouping.
  1423. # [09:19] <fantasai> My position: If you can convince me that 80% of Web use cases for grid layout can be handled without compromising accessibility, I will retract my objection to removing subgrid. Otherwise not.
  1424. # [09:20] <dael> Rossen__: All the items in a subgrid are in the top-level grid, but have this invisible elemnt that let's us attach behaviour
  1425. # [09:20] <dael> Rossen__: For the past 1 or 2 years one exersize we went though was take the initial grid spec with is an app based grid with cells and try and merge that with typography based grid
  1426. # [09:20] <dael> Rossen__: We did that . Everyone in the grid taskforce contributed a lot
  1427. # [09:21] <dael> Rossen__: The spec is in fairly good shape to get to LC
  1428. # [09:21] <dael> fantasai: I think it needs another round or two for the algorithm
  1429. # [09:21] <dael> Rossen__: As concepts it's good
  1430. # [09:21] <fantasai> fantasai: but design-wise, it's good
  1431. # [09:21] <dael> Rossen__: The one wrinkle is that impl subgrid will be fairly complex.
  1432. # [09:21] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  1433. # [09:22] <dael> Rossen__: The reason why is (and subgrids nest) so the entire layout of subgrids boils down to the dependnency of subgrids which can bring any element anywhere in a subtree with a different amount of spanning on some leverl as well as overflow
  1434. # [09:22] <dael> rossen: the current sampling makes me thing blink and firefox are close to impl grid
  1435. # [09:22] <dael> fantasai: mozilla is nowhere near
  1436. # [09:23] <dael> jet: It's been going around for a bit
  1437. # [09:23] <dael> rossen: But we want to push grid out as soon as we can. We want to rev our unprefixed version of grid for everything except subgrid.
  1438. # [09:23] <TabAtkins> (jet indicated someone named "max" was put on it too)
  1439. # [09:24] <fantasai> I think you mean "mats"
  1440. # [09:24] <dael> rossen: I think subgrid as a functionality is needed. I prop we move subgirid to level 2, allow level 1 to ship so all impl that are close can roll out at the same time
  1441. # [09:24] <dael> rossen: And than work on subgrid as soon as we can
  1442. # [09:24] <dael> rossen: In the meantime if we find out impl of subgrid is quicker, we might pull into level 1 before rec, but my initial prototyping suggests it will have a sig impl delay
  1443. # [09:25] <dael> fantasai: My position is if we can cover 80% of common use cases with existing without subgrid or comp accessability, I'm okay, but I'm not convised. I think we can cover 30% There's common cases that wil be worse with grid.
  1444. # [09:25] * Ms2ger has a feeling this discussion has been had several times
  1445. # [09:25] <dael> fantasai: Those case for which grid is designed and I haven't heard markup for an example that uses grid and isn't bad markup
  1446. # [09:26] * astearns ms2ger would be correct. this is a sub-conversation nested fairly deeply
  1447. # [09:26] <dael> rossen: I can tell you almost, nearly all HTML based windows store apps use grid.
  1448. # [09:26] * TabAtkins this is us attempting to pop the stack of this convo completely
  1449. # [09:26] <dael> rossen: They're assiable and request subgrid as a future, but almost all that content that will be on the web will be fine without subgrid
  1450. # [09:26] * Ms2ger astearns, I propose to move this discussion to F2F v2
  1451. # [09:26] <zcorpan> s/assiable/accessible/
  1452. # [09:26] <dael> fantasai: App layouts seem to be simplier
  1453. # [09:26] <dael> rossen:I don't agree.
  1454. # [09:27] <dael> fantasai: I want a concrete example of something common with proper markup and I haven't seen that
  1455. # [09:27] <dael> dbaron: fantasai concern is about people having to remove thigns from markup
  1456. # [09:28] <dael> TabAtkins: So anythign doing a vaguely grid layout, accessibility wise it's fine, right now they're deeply nested, but for accessibility they're fine. There's a decent number of use cases for in page components that are better solved by subgrid, but I want to solve page layout right now.
  1457. # [09:28] <dael> fantasai: So write an ex an post to the ML
  1458. # [09:28] <dael> TabAtkins: Look at any website
  1459. # [09:28] * liam wants to see page layout solved too :-)
  1460. # [09:28] <dael> fantasai: I did and said you'd have to remove these things and add emply elements.
  1461. # [09:29] <dael> fantasai: I went to a grid layout system, I posted the link about. There's people that made frameworks for gridlink layouts.
  1462. # [09:29] <dbaron> s/things/things (section markup and ids)/
  1463. # [09:29] <dbaron> s/assiable/accessible/
  1464. # [09:29] <dael> fantasai: I took that, figured out how to mark with grid and subgrid and figured out it's very different.
  1465. # [09:29] <dael> TabAtkins: This first is fine if you don't remove sections.
  1466. # [09:30] <dael> fantasai: If you want the pictures to line up, you need to remove the markup that collects around "here" [pointing] unless you guarentee it lines up.
  1467. # [09:30] <dael> fantasai: So something where you have something that looks like a grid, but doesn't rely on things being the same size. If its' same size, why not use flex.
  1468. # [09:31] <dael> TabAtkins: You don't need subgrid until you're trying to style with padding and border. You're taking each top level piece and display box works.
  1469. # [09:31] <dael> fantasai: Than we can put display box in grid
  1470. # [09:31] <dael> TabAtkins: That's silly.
  1471. # [09:31] <dbaron> s/display box/display-box: contents/
  1472. # [09:31] <dbaron> s/in grid/in the grid spec/
  1473. # [09:31] <dael> fantasai: I agree. I don't want to give a feature that authors will be excited about but to use it they have to strip out content to use it, they're continue to do that after we ship subgrid
  1474. # [09:32] <dael> fantasai: Markup won't sure for 2 years, it'll suck for 10 because people will keep stripping it out.
  1475. # [09:32] <dael> TabAtkins: Given the pattern worst case you need a diva round the pattern so that you can say auto: flow
  1476. # [09:32] <dael> hober: I thinkt he point stands is you have to take out the layout for a complicated model.
  1477. # [09:32] <dael> fantasai: auto:flow only works in one direction.
  1478. # [09:33] <dael> fantasai: I'm not convinced this isn't harmful. I'm pretty sure it's harmful. Unless you have examples that show me I'm wrong, but you have not done that
  1479. # [09:33] * dauwhe see footer at http://alistapart.com
  1480. # [09:33] <dael> TabAtkins: Most sites have a simple grid that's hard to do now and can be addressed fine with grid
  1481. # [09:33] <dael> fantasai: And how many of the use cases is that?
  1482. # [09:33] <dael> TabAtkins: The plan is people will use grid forever
  1483. # [09:34] <dael> fantasai: I don't want them int he habit to do harmful thigns to use grid and keep using it
  1484. # [09:34] <dael> TabAtkins: This is a short period of time
  1485. # [09:34] <dael> fantasai: So we wait until subgrid is impl
  1486. # [09:34] * liam wonders if fantasai is trying to be a little paternalistic here?
  1487. # [09:34] <dael> fantasai: It's not tutorials, it's about habits. I fyou do it the old way it'll work in old version os IE.
  1488. # [09:35] <dael> hober: Prob shouldn't add verya ttractive desireable features to use practically in the real world but require reduced markup quality.
  1489. # [09:35] <dael> TabAtkins: I say not many or most case and the markup qualityt oday is so terrible we're improving anyway
  1490. # [09:35] <dael> TabAtkins: We'd rather a flatter structure.
  1491. # [09:35] <dael> plinss: Does display box conent solve most of the problems
  1492. # [09:35] <dael> TabAtkins: Some
  1493. # [09:36] <dael> plinss: Enough to aleviate your concerns?
  1494. # [09:36] <dael> fantasai: Yes, my concerns about active markup being bad
  1495. # [09:36] * hober %$&* it, let's change the default styling of div to be display-box: contents
  1496. # [09:36] <dael> plinss: So is display box being ready before subgrid a way to make this work
  1497. # [09:36] <dael> TabAtkins: So I can't promise, but it's likely ready before subgrid
  1498. # [09:36] <dael> TabAtkins: We have something else calling for this feature.
  1499. # [09:37] <dael> plinss: Does this handle your concerns?
  1500. # [09:37] <dael> TabAtkins: I'm otherwise going to object to obections here.
  1501. # [09:37] <dael> fantasai: If that's impl and shipped before or with grid and we update the spec to have a nice tutorial to use these together, htan I think that will be acceptable
  1502. # [09:38] <dael> plinss: Okay.
  1503. # [09:38] <dael> TabAtkins: Sounds fine to me
  1504. # [09:38] <dael> rossen: Jet, you're okay witht hat?
  1505. # [09:38] <dael> fantasai: I'm waiting for display content before I remove my objection
  1506. # [09:38] <dael> TabAtkins: The agreement was it shipping
  1507. # [09:38] <dael> fantasai: Until that's happening, I'm not removing my obj
  1508. # [09:39] <dael> dbaron: Would you be okay with something in the spec that says impl impling grid are also expected to impl display: box
  1509. # [09:39] <dael> hober: That's a message to say that things should be in the order. All the example should have to use it in order to have the affect you want.
  1510. # [09:39] <dael> TabAtkins: The examples today don't need it
  1511. # [09:39] * Joins: rossen___ (~uid21900@public.cloak)
  1512. # [09:39] <SimonSapin> s/display: box/display-box/
  1513. # [09:39] <dael> plinss: So phrase it in a way to say display: box content is an impl requirement of grid
  1514. # [09:40] <dael> dbaron: They're correct that the examples should have it as well
  1515. # [09:40] * Joins: Rossen_ (~Rossen@public.cloak)
  1516. # [09:40] <dael> clilley: rossen___ the app store has an accessibility review? Any problems?
  1517. # [09:40] * dbaron thought we had a compromise, and then Chris changed the topic
  1518. # [09:41] <dael> rossen___: Grid is a default that's used for authoring apps. In order to submit it has to meet assicibility. Im' not sure how it's essessed
  1519. # [09:41] <dael> rossen___: With the current grid which we have without subgrid, all these application exist just fine
  1520. # [09:41] <dael> clilley: Some data would be useful
  1521. # [09:41] <dael> rossen___: They're all new content. Nonea re using the same pattern as the website, though I wouldn't expect much different
  1522. # [09:41] <dael> fantasai: Put if you have labesla nd forms elements, it's a jumble
  1523. # [09:42] <Ms2ger> s/labesla nd/labels and/
  1524. # [09:42] <dael> dbaron: The other point is on the web we want the platform so people write accessibile as the default. If you have a revew state that means you havea different situation.
  1525. # [09:42] <dael> dbaron: I think we almost had a comprimise
  1526. # [09:42] * Parts: rossen___ (~uid21900@public.cloak)
  1527. # [09:43] <dael> plinss: Proposed res is to move subgrid to level two and add a requirement for display-box to be used with grid.
  1528. # [09:43] <dael> fantasai: I'd prefer a label for at risk
  1529. # [09:43] * Quits: Shinsuke (~Shinsuke@public.cloak) (Ping timeout: 180 seconds)
  1530. # [09:43] <dael> astearns: How far along is the display box impl?
  1531. # [09:43] <dael> plinss: Peple said it's easier
  1532. # [09:43] <dael> astearns: Is it impl yet?
  1533. # [09:43] <dael> plinss: So it's coming real soon.
  1534. # [09:43] <dael> fantasai: We should finish the draft.
  1535. # [09:44] <fantasai> jet^: Think it's almost landed
  1536. # [09:44] <dael> RESOLVED: move subgrid to at risk for level 1 and add a requirement for display-box to be used with grid and include examples
  1537. # [09:44] <dael> fantasai: I'll make the edits
  1538. # [09:44] <dael> Rossen_: I'll review them
  1539. # [09:44] <dael> TabAtkins: And I'll go over them.
  1540. # [09:45] <fantasai> Topic: sticky
  1541. # [09:45] <dael> Topic: position sticky
  1542. # [09:45] * fantasai do we even have an editor for positioning?
  1543. # [09:45] <dael> dbaron: It's a followup to an issue that hasn't been editing into spec. There was a thread started that it doesn't explain the two boxes you need to use sticky
  1544. # [09:45] <fantasai> fantasai: Can we turn the spec into a list of links into the www-style archives?
  1545. # [09:46] <dael> dbaron: My understanding of sticky is that you have soemthing like a hearder and you want to to scroll up witht he content and than stop for a period of time witht he content where it's the header and than sroll off when it's done being used
  1546. # [09:46] <dael> dbaron: So it's fundimentally like position: relative except the offset is changing dynamically.
  1547. # [09:46] <dael> dbaron: You can use any of top.right.bottom.left properties
  1548. # [09:47] <fantasai> . -> /
  1549. # [09:47] <dael> dbaron: You have the boxes you care about. the scrollable box, the element's containing block, and than you have the sticky element itself.
  1550. # [09:47] * liam wonders if this is e.g. for a table header that remains visible when you scroll a long table
  1551. # [09:47] <dael> dbaron: For the sticky element we only care about the margin box and for the scrollable area we care about the padding box.
  1552. # [09:47] * fantasai yes
  1553. # [09:47] <dael> dbaron: What happens if you set none of the offesets nothing interesting happens.
  1554. # [09:48] <dael> dbaron: If you set the offset to top: 20px, it's relative to the outside box so it means you care about the edge that's 20px from the top of the scrollable area. So you prevent this margin box from going above...
  1555. # [09:49] <dael> dbaron: So top 20px says the top px of the sticky box won't go above the container as long as the scrolling box doesn't go above
  1556. # [09:49] <dael> hober: So it implicitly controls two edges
  1557. # [09:49] <dael> dbaron: It's two constraints. And the 2nd overirdes the first.
  1558. # [09:49] <dael> dbaron: The point of the 2nd is to have it scroll off. Even though this isn't in the spec, we agree that this is how it works.
  1559. # [09:49] * astearns position:sticky-for-a-while
  1560. # [09:49] <dael> dbaron: Where impl don't agree is if the boxes are the same size
  1561. # [09:50] <dael> Rossen_: Or some of the internal boxes are bigger.
  1562. # [09:50] <dael> dbaron: I want to discuss what if they're the same. The issue is that the second constraint constrains relative to something that's scrolling withint the scrollable area
  1563. # [09:50] <dael> hober: If they're the same you never hit the bottom
  1564. # [09:51] <dael> dbaron: The problem is the scrollable box is sorta like two boxes. the actualy box and the scrollable area.
  1565. # [09:51] <dael> dbaron: There are three options for the second constrant where the sticky element's containing block is it's scrollable container
  1566. # [09:51] <dael> dbaron: I prefer 1) Throw out hte second constraint
  1567. # [09:51] <dael> dbaron: 2) make the scrollable constraint the area inside the scrollable conatiner
  1568. # [09:52] <dael> dbaron: and that means most of the time the 2nd constraint doesn't happen either unless you're in an overflow case
  1569. # [09:52] <dael> dbaron: Geicko does #1
  1570. # [09:52] <dael> dbaron: 3rd is webkit which is use the box that isn't being scrolled. You have to write weird test cases to trigger this
  1571. # [09:52] * Joins: yamamoto_ (~yamamoto@public.cloak)
  1572. # [09:53] <plinss> s/Geicko/Gecko/
  1573. # [09:53] <dael> dbaron: Webkit will force the sticky element intot he box, even if it's below it.
  1574. # [09:53] <dael> dbaron: If the sticky element is scrolled up above, it'll force it down into the box. Which seems crazy
  1575. # [09:53] * clilley Geckos have sticky elements on their toes
  1576. # [09:54] <dael> dbaron: I think in this case where the two boxes are the same, the purpose of the contianing block constrant has disappeared
  1577. # [09:54] <dael> [whiteboard]
  1578. # [09:54] <dael> dbaron: I've got a testcase link in which Gecko and Webkit disagree
  1579. # [09:54] <dbaron> https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943
  1580. # [09:55] * krit wondered about the relation between Gecko and Geicko before...
  1581. # [09:55] <TabAtkins> *Geiko
  1582. # [09:55] <dael> dbaron: So the case...
  1583. # [09:56] <dael> dbaron: In webkit, I was right the first time. If the box is way below, webkit will constrain it to the bottom and than will scroll it up to the 20px margins until, I'm not sure when
  1584. # [09:56] <dael> Rossen_: Can I add one more view?
  1585. # [09:56] <dael> Rossen_: This is what I was going to add intot he spec and it's almost ready.
  1586. # [09:56] <dael> Rossen_: Last I talked about this with Cory is the follwoing.
  1587. # [09:56] <dael> Rossen_: We have an element to which you'llb e using position: sticky.
  1588. # [09:57] <dael> Rossen_: You default to 0px, not matter what
  1589. # [09:57] <dael> dbaron: They default to auto, not 0
  1590. # [09:57] <dael> hober: For what it's worth, the webkit testcase is paying attention to how I thought.
  1591. # [09:57] <dael> dbaron: [corrects]
  1592. # [09:57] <dael> hober: Oh. That's evil.
  1593. # [09:58] <dael> dbaron: The other thing to notice is they have a bottom of 180px that pushes them outside the containing block.
  1594. # [09:59] <dael> Rossen_: So the termonology we used is the sticky position which is the position at which the box will get stuck. Also the release position which is the condition at which the box gets put away.
  1595. # [09:59] <dael> hober: That you're using enormous values is what makes it apperent.
  1596. # [09:59] <dael> Rossen_: So sticky position is byt he scroller, release pos is trigger by containing block and an open question is if cont. block is the same as the scroll in which case we need to define reasonable behaviour.
  1597. # [10:00] <dael> dbaron: I was suggesting if they're the ame you throw away release
  1598. # [10:00] <dael> Rossen_: So it's stuff forever. that could be reasonable. If you have a bunch of these they'd stick on eachother. It would be sucky if they're the same size, but a reasonable comprimise.
  1599. # [10:00] <dael> Rossen_: The other problem is when sticky is about the trigger so we have to either define so it's brought back or it doens't trigger
  1600. # [10:01] <dael> dbaron: The other fun case is if you have both top and bottom or left and right and figuring out who wins
  1601. # [10:01] <dael> Rossen_: We can use the scroll direction as a preference so ify ou're scrolling down we take preference of the tob
  1602. # [10:02] <dael> hober: Having the behaviour depend on initial scroll direction is weird. As an author trying to debug, not realizing it's that you originally scrolled
  1603. # [10:02] <dael> dbaron: I think he ment by which way you can scroll to overflow.
  1604. # [10:02] <dael> hober: I'm presuming you've scrolled a bit
  1605. # [10:02] <dael> Rossen_: Initially. When the scroller is at origin than you have a direction
  1606. # [10:02] <dael> hober: That does seem reasonable
  1607. # [10:03] <dael> adenilson: I have all thre browsers and they're all doing something weird
  1608. # [10:03] <dael> dbaron: It's a weird testcase
  1609. # [10:03] <dael> dbaron: We should try and fix this
  1610. # [10:03] <dael> TabAtkins: We're no longer shipping sticky
  1611. # [10:03] <dael> TabAtkins: It's in stable, but not in less stable versions
  1612. # [10:04] <dael> dbaron: I think chrome has sticky in experemental web platform, but apple is shipping and we are.
  1613. # [10:04] <dael> TabAtkins: The more i think about it, webkit's behaviour makes sense
  1614. # [10:04] <dael> dbaron: It makes sesne to pull to the opposite edge
  1615. # [10:04] <dael> TabAtkins: It doesn't want to exit it's containing block
  1616. # [10:04] <dael> hober: Which is undesireable in the weird case where they're the same.
  1617. # [10:05] <dael> Rossen_: Having section don't necessary mean...they can be sep by headers
  1618. # [10:05] <dael> hober: But they the stack
  1619. # [10:05] <dael> TabAtkins: This is how I'd expect if the containing block is the viewport
  1620. # [10:05] <dael> Rossen_: Or if the release is defined by interacting with another sticky item
  1621. # [10:05] <dael> hober: No no
  1622. # [10:06] <dael> dbaron: Youc an compute this locally and this is all data you want to send to your compositor. What I don't like about webkit is it's totally different information in that one case
  1623. # [10:06] <dael> dbaron: In every other case it's in the scrolling except in that case where the release is a scrolling position
  1624. # [10:06] * Joins: shans__ (~shans@public.cloak)
  1625. # [10:07] <dael> fantasai: Sticky is relative to the nearest ancestor
  1626. # [10:07] <dael> fantasai: It's sticky in both dimensions
  1627. # [10:07] <dael> hober: Yes. In the axis you set and offset
  1628. # [10:07] <dael> dbaron: top/bottom/left/right auto means not sticky
  1629. # [10:07] <dael> hober: It's relatively positiioned, but you haven't offset it from it's original static position.
  1630. # [10:07] <dael> fantasai: Okay.
  1631. # [10:08] <dael> dbaron: In firefox the green one is honoring the bottom 180 and the orange one is honoring the top 180
  1632. # [10:08] <dael> dbaron: Green starts like that beciase that's bottom 180.
  1633. # [10:09] <dael> dbaron: There's no release constraint, just sticky.
  1634. # [10:09] <dael> TabAtkins: Whereas in ours this means sticky so it stays
  1635. # [10:09] <dael> hober: So there's a release side where you're willing to release but if you haven't hit that you should stick
  1636. # [10:09] <dael> TabAtkins: Now that I can see it live, I can see it's a bug
  1637. # [10:09] <dael> TabAtkins: I'm not sure.
  1638. # [10:10] <dael> TabAtkins: If I like it or not.
  1639. # [10:10] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
  1640. # [10:10] <dael> TabAtkins: If you say the green is bottom 180, top 0 it wouldn't ever fall off.
  1641. # [10:10] <dael> dbaron: It's kinda an edge case and I jsut want the make the impl simplier and don't have to worry about a release that's outside the box.
  1642. # [10:10] <dael> TabAtkins: I'm assuming this is because it's easier, but I'm not sure
  1643. # [10:11] <dael> hober: I think Simon thought through a lot of edge cases.
  1644. # [10:11] <dael> TabAtkins: I'm not opposed to changing.
  1645. # [10:11] <dael> dbaron: I think we're done this topic
  1646. # [10:11] <dael> TabAtkins: Who is edit position?
  1647. # [10:11] <dael> Rossen_: It's going
  1648. # [10:11] <dael> TabAtkins: You have a plan?
  1649. # [10:11] <dael> Rossen_: Yeah.
  1650. # [10:11] <dael> Rossen_: I have most of this edit done, I have to clean it up.
  1651. # [10:12] <dael> TabAtkins: Can we define static pos in your draft
  1652. # [10:12] <dael> Rossen_: Fine with me. WE need it for flex and grid
  1653. # [10:12] <dael> plinss: We haven't pub a WD in 2 years
  1654. # [10:12] <dael> Rossen_: As soon as I have the edit I'll ask for a new WD
  1655. # [10:12] <dael> Topic: CSS conditions
  1656. # [10:13] <dael> dbaron: This was a humorous spec
  1657. # [10:13] <dael> plinss: FPWD on April 1, 2015
  1658. # [10:14] <dael> dbaron: Is there stuff worth saying about the workshop?
  1659. # [10:14] <dael> hober: I have questions about it.
  1660. # [10:14] <dael> hober: Is it in this building?
  1661. # [10:14] <dael> many: yes
  1662. # [10:14] <dael> hober: It starts at 9?
  1663. # [10:14] <dael> astearns: 9:30. It's all day, but the afternoon is in Korean.
  1664. # [10:15] * krit the morning is in Korea and the afternoon in Korean?
  1665. # [10:15] <dael> dauwhe: We got the announcement in Korean.
  1666. # [10:15] <dael> dauwhe: It's independant talks.
  1667. # [10:15] <dael> plh: Is there a page for this thing?
  1668. # [10:15] <dael> clilley: It's only e-mail
  1669. # [10:16] <dael> hober: If the format is morning is in English and the purpose of WG to attend is to be able to interact, I assume there's oportunities for people to ask questions in the afternoon an have those translated back
  1670. # [10:16] <dael> dwim: Are you sure the afternoon is in Korean?
  1671. # [10:16] <dael> dwim: Korea guys may present in English
  1672. # [10:16] <dael> glaz: The meeting tomorrow is witht he TTA members. It's the gov't telecom agency
  1673. # [10:17] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
  1674. # [10:17] <dael> glaz: They are going to host the meeting on this floow starting at 9am about W3C and CSS ingeneral and than a focus on CSS in the morning.
  1675. # [10:18] <dael> glaz: The Korean members will give talks in Korean for the rest of the day. Al WG members are welcome to join.
  1676. # [10:18] * Quits: jh (~jh@public.cloak) ("Page closed")
  1677. # [10:18] <dael> glaz: And that's it.
  1678. # [10:18] <dael> glaz: Let me check the exact schedule.
  1679. # [10:18] <dael> plh: Is there a page for this?
  1680. # [10:18] <dael> glaz: No.
  1681. # [10:19] <dael> glaz: 9:30 for the first session, welcome at 9.
  1682. # [10:19] <dael> glaz: There's prob. an introduction by an offical before.
  1683. # [10:19] <dael> glaz: Registration is at 9, just say you're a CSS WG member
  1684. # [10:20] * liam not p;lanning to attend workshop :)
  1685. # [10:20] * astearns liam: slacker
  1686. # [10:20] <dael> glaz: at 2pm is pure CSS drawing. 3pm is CSS post and pre process. 4pm is CSS 3
  1687. # [10:20] * liam :)
  1688. # [10:21] * liam Live Free or Die
  1689. # [10:21] * liam Live three or Die
  1690. # [10:21] <dael> glaz: A few minutes ago I e-mailed TTA to thank them for hosting. I think the walking distance hotel was very convenient and they were incredibly helpful
  1691. # [10:21] <liam> [I would like to thank Daniel for the audio webinar facility]
  1692. # [10:21] <dael> glaz: I'd also like to thank dwim for all the help he gave us
  1693. # [10:21] <dael> Meeting agorned
  1694. # [10:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  1695. # [10:22] <glazou> THANK U DAEL !!!
  1696. # [10:22] * Quits: plh (~plh@public.cloak) ("Page closed")
  1697. # [10:22] * Quits: glazou (~glazou@public.cloak) ("Page closed")
  1698. # [10:22] <krit> bye folks!
  1699. # [10:22] <liam> bye :)
  1700. # [10:22] <liam> 4:20am here
  1701. # [10:22] * Quits: dael (~dael@public.cloak) ("Page closed")
  1702. # [10:23] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  1703. # [10:25] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  1704. # [10:25] * Quits: andrey (~andrey@public.cloak) (Ping timeout: 180 seconds)
  1705. # [10:25] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
  1706. # [10:27] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  1707. # [10:28] * Quits: clilley (~clilley@public.cloak) ("Page closed")
  1708. # [10:28] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
  1709. # [10:29] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  1710. # [10:30] * Quits: yamamoto_ (~yamamoto@public.cloak) ("Page closed")
  1711. # [10:31] * Quits: murakami_ (~murakami@public.cloak) (Ping timeout: 180 seconds)
  1712. # [10:39] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1713. # [10:47] * Joins: dauwhe (~dauwhe@public.cloak)
  1714. # [10:52] * Quits: heeyoun (~uid33091@public.cloak) (Client closed connection)
  1715. # [10:53] * Joins: heeyoun (~uid33091@public.cloak)
  1716. # [10:57] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1717. # [11:04] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
  1718. # [11:30] * Joins: antonp (~Thunderbird@public.cloak)
  1719. # [11:36] * Quits: Garbee (~uid21171@public.cloak) (Client closed connection)
  1720. # [11:37] * Quits: abinader (~sid21713@public.cloak) (Client closed connection)
  1721. # [11:37] * Joins: abinader (~sid21713@public.cloak)
  1722. # [11:37] * Joins: Garbee (~uid21171@public.cloak)
  1723. # [11:52] * Joins: dauwhe (~dauwhe@public.cloak)
  1724. # [11:58] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1725. # [11:59] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1726. # [12:00] * Joins: antonp (~Thunderbird@public.cloak)
  1727. # [12:07] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1728. # [12:09] * Joins: antonp (~Thunderbird@public.cloak)
  1729. # [12:24] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1730. # [12:24] * Joins: antonp (~Thunderbird@public.cloak)
  1731. # [12:35] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1732. # [12:36] * Joins: antonp (~Thunderbird@public.cloak)
  1733. # [12:47] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1734. # [12:48] * Joins: antonp (~Thunderbird@public.cloak)
  1735. # [12:51] * Joins: dauwhe (~dauwhe@public.cloak)
  1736. # [13:00] * Parts: dauwhe (~dauwhe@public.cloak) (dauwhe)
  1737. # [13:01] * Quits: dwim (~uid10661@public.cloak) ("Connection closed for inactivity")
  1738. # [13:02] * Joins: dbaron (~dbaron@public.cloak)
  1739. # [13:11] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  1740. # [13:20] * Joins: zcorpan (~zcorpan@public.cloak)
  1741. # [13:20] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1742. # [13:21] * Joins: antonp (~Thunderbird@public.cloak)
  1743. # [13:28] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1744. # [13:28] * Joins: antonp1 (~Thunderbird@public.cloak)
  1745. # [13:44] * Joins: antonp (~Thunderbird@public.cloak)
  1746. # [13:44] * Quits: antonp1 (~Thunderbird@public.cloak) (Client closed connection)
  1747. # [13:47] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  1748. # [13:47] * Joins: zcorpan (~zcorpan@public.cloak)
  1749. # [13:54] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1750. # [13:55] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1751. # [13:55] * Joins: antonp (~Thunderbird@public.cloak)
  1752. # [13:58] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1753. # [14:02] * Joins: antonp (~Thunderbird@public.cloak)
  1754. # [14:13] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
  1755. # [14:16] * Joins: antonp (~Thunderbird@public.cloak)
  1756. # [14:38] * Joins: Ms2ger (~Ms2ger@public.cloak)
  1757. # [14:44] * Joins: jdaggett (~jdaggett@public.cloak)
  1758. # [15:31] * Joins: zcorpan (~zcorpan@public.cloak)
  1759. # [15:43] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  1760. # [15:45] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  1761. # [16:03] * Joins: koji_ (~koji@public.cloak)
  1762. # [16:03] <koji_> fantasai; I:m ok to have the S&C added to HTML later, if that:s easier process wise. Would want an active version of it somewhere, so we can develop it, but don:t care if it:s in HTMl5
  1763. # [16:03] * Parts: koji_ (~koji@public.cloak)
  1764. # [16:09] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  1765. # [16:32] * Joins: dauwhe_ (~dauwhe@public.cloak)
  1766. # [16:33] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
  1767. # [16:33] * Joins: dauwhe_ (~dauwhe@public.cloak)
  1768. # [16:46] * Joins: dauwhe (~dauwhe@public.cloak)
  1769. # [16:52] * Joins: dauwhe__ (~dauwhe@public.cloak)
  1770. # [16:52] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1771. # [16:54] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  1772. # [16:54] * Joins: dauwhe (~dauwhe@public.cloak)
  1773. # [17:00] * Quits: dauwhe__ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1774. # [17:06] * Joins: dauwhe_ (~dauwhe@public.cloak)
  1775. # [17:11] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1776. # [17:13] * Joins: dauwhe (~dauwhe@public.cloak)
  1777. # [17:17] * Joins: xiaoqian (xiaoqian@public.cloak)
  1778. # [17:19] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1779. # [17:19] * Joins: dauwhe__ (~dauwhe@public.cloak)
  1780. # [17:20] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  1781. # [17:20] * Joins: dauwhe (~dauwhe@public.cloak)
  1782. # [17:25] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  1783. # [17:26] * Joins: zcorpan (~zcorpan@public.cloak)
  1784. # [17:26] * Quits: dauwhe__ (~dauwhe@public.cloak) (Client closed connection)
  1785. # [17:27] * Joins: dauwhe_ (~dauwhe@public.cloak)
  1786. # [17:28] * Joins: dauwhe__ (~dauwhe@public.cloak)
  1787. # [17:29] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  1788. # [17:32] * Joins: rhauck (~Adium@public.cloak)
  1789. # [17:33] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1790. # [17:34] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1791. # [17:35] * Joins: dauwhe (~dauwhe@public.cloak)
  1792. # [17:35] * Quits: xiaoqian (xiaoqian@public.cloak) ("Page closed")
  1793. # [17:35] * Quits: dauwhe__ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1794. # [17:41] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  1795. # [17:52] * Joins: Ms2ger (~Ms2ger@public.cloak)
  1796. # [17:57] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  1797. # [18:01] * Joins: lmclister (~lmclister@public.cloak)
  1798. # [18:11] * Joins: dauwhe (~dauwhe@public.cloak)
  1799. # [18:22] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1800. # [18:43] * Quits: harayama (~harayama@public.cloak) (Ping timeout: 180 seconds)
  1801. # [18:53] * Joins: rhauck (~Adium@public.cloak)
  1802. # [19:07] * Joins: jcraig (~jcraig@public.cloak)
  1803. # [19:16] * Quits: lmclister (~lmclister@public.cloak) ("")
  1804. # [19:16] * Joins: dauwhe (~dauwhe@public.cloak)
  1805. # [19:21] * Joins: lmclister (~lmclister@public.cloak)
  1806. # [19:23] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1807. # [19:57] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1808. # [20:09] * Joins: jcraig (~jcraig@public.cloak)
  1809. # [20:17] * Joins: dauwhe (~dauwhe@public.cloak)
  1810. # [20:25] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1811. # [20:48] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
  1812. # [20:48] * Quits: tantek (~tantek@public.cloak) (tantek)
  1813. # [20:50] * Joins: zcorpan (~zcorpan@public.cloak)
  1814. # [21:01] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  1815. # [21:02] * Joins: tantek (~tantek@public.cloak)
  1816. # [21:09] * Quits: tantek (~tantek@public.cloak) (tantek)
  1817. # [21:13] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1818. # [21:18] * Joins: dauwhe (~dauwhe@public.cloak)
  1819. # [21:25] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1820. # [21:29] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  1821. # [21:30] * Joins: zcorpan (~zcorpan@public.cloak)
  1822. # [21:30] * Joins: jcraig (~jcraig@public.cloak)
  1823. # [21:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  1824. # [21:30] * Joins: zcorpan (~zcorpan@public.cloak)
  1825. # [21:35] * Joins: darktears (~darktears@public.cloak)
  1826. # [21:38] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1827. # [21:39] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1828. # [21:42] * Joins: tantek (~tantek@public.cloak)
  1829. # [21:43] * Joins: zcorpan (~zcorpan@public.cloak)
  1830. # [21:44] * Joins: jcraig (~jcraig@public.cloak)
  1831. # [21:46] <krit> zcorpan: Do you plan to use bikeshed on CSS OM View
  1832. # [21:46] <krit> ?
  1833. # [21:47] <zcorpan> krit: yeah
  1834. # [21:47] <krit> zcorpan: cool, it would auto link DOMRect and so on
  1835. # [21:47] <zcorpan> yes
  1836. # [21:58] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1837. # [22:01] * Joins: jcraig (~jcraig@public.cloak)
  1838. # [22:04] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1839. # [22:10] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  1840. # [22:10] * Joins: darktears (~darktears@public.cloak)
  1841. # [22:10] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  1842. # [22:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
  1843. # [22:30] * Joins: zcorpan (~zcorpan@public.cloak)
  1844. # [22:37] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  1845. # [23:14] * Joins: jcraig (~jcraig@public.cloak)
  1846. # [23:20] * Joins: dauwhe (~dauwhe@public.cloak)
  1847. # [23:20] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  1848. # [23:21] * Joins: dauwhe_ (~dauwhe@public.cloak)
  1849. # [23:21] * Quits: dauwhe_ (~dauwhe@public.cloak) ("")
  1850. # [23:23] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  1851. # [23:27] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  1852. # [23:57] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
  1853. # Session Close: Thu May 22 00:00:00 2014

The end :)