/irc-logs / w3c / #webapps / 2015-08-24 / end

Options:

Previous day, Next day

  1. # Session Start: Mon Aug 24 00:00:00 2015
  2. # Session Ident: #webapps
  3. # [00:01] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  4. # [00:03] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  5. # [00:36] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
  6. # [00:36] * Joins: Florian (~Florian@public.cloak)
  7. # [00:43] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  8. # [00:58] * Joins: Florian (~Florian@public.cloak)
  9. # [01:38] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  10. # [01:38] * Joins: Florian (~Florian@public.cloak)
  11. # [01:45] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  12. # [02:06] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
  13. # [02:40] * Joins: jyasskin (~textual@public.cloak)
  14. # [03:37] * xiaoqian RRSAgent, draft minutes
  15. # [03:37] <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html xiaoqian
  16. # [04:06] <MikeSmith> meeting seems to have ended sorta abruptly
  17. # [04:07] <MikeSmith> in medias res
  18. # [04:46] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  19. # [05:56] * Joins: Florian (~Florian@public.cloak)
  20. # [06:04] * Quits: Florian (~Florian@public.cloak) ("Leaving...")
  21. # [06:30] * Joins: grisha (~grisha@public.cloak)
  22. # [06:41] * Quits: grisha (~grisha@public.cloak) (Ping timeout: 180 seconds)
  23. # [08:14] * heycam|away is now known as heycam
  24. # [08:34] * Joins: grisha (~grisha@public.cloak)
  25. # [08:35] * grisha slaps grisha around a bit with a large fishbot
  26. # [08:35] * Quits: grisha (~grisha@public.cloak) ("Page closed")
  27. # [08:35] * Joins: grisha (~grisha@public.cloak)
  28. # [08:39] * heycam is now known as heycam|away
  29. # [08:43] * heycam|away is now known as heycam
  30. # [09:06] * heycam is now known as heycam|away
  31. # [09:16] * Joins: johanneswilm (~johannes@public.cloak)
  32. # [09:23] * Joins: dom (dom@public.cloak)
  33. # [09:26] * heycam|away is now known as heycam
  34. # [09:34] * Quits: grisha (~grisha@public.cloak) (Ping timeout: 180 seconds)
  35. # [09:37] * Joins: wilsonpage (~wilsonpage@public.cloak)
  36. # [09:46] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  37. # [09:50] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  38. # [10:01] * Joins: enrica (~enrica@public.cloak)
  39. # [10:03] * Joins: weinig (~weinig@public.cloak)
  40. # [10:06] * Joins: chaals (~Adium@public.cloak)
  41. # [10:07] * Joins: Florian (~Florian@public.cloak)
  42. # [10:07] * chaals will be late ;( Feel free to appoint a scribe and start the next topic...
  43. # [10:08] * chaals will be about another 20 minutes if I am lucky...
  44. # [10:08] * Florian chaals: we're still gathering / having breakfast for now
  45. # [10:08] * Florian chaals: how late do you expect to be? Minutes or hours?
  46. # [10:10] * chaals with any luck I will be there by 10.30...
  47. # [10:18] * Quits: weinig (~weinig@public.cloak) (weinig)
  48. # [10:18] * Joins: weinig (~weinig@public.cloak)
  49. # [10:18] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  50. # [10:18] * Joins: grisha (~grisha@public.cloak)
  51. # [10:21] <Florian> rssagent, pointer
  52. # [10:21] <Florian> rssagent, help
  53. # [10:23] * Joins: rniwa (~textual@public.cloak)
  54. # [10:27] <Florian> Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan
  55. # [10:30] * Joins: johanneswilm (~johannes@public.cloak)
  56. # [10:30] <Florian> trackbot, start meeting
  57. # [10:30] * trackbot is preparing a teleconference.
  58. # [10:30] <trackbot> RRSAgent, make logs public
  59. # [10:30] <RRSAgent> I have made the request, trackbot
  60. # [10:30] <trackbot> Zakim, this will be DOM3
  61. # [10:30] <trackbot> Meeting: Web Applications Working Group Teleconference
  62. # [10:30] <trackbot> Date: 24 August 2015
  63. # [10:31] <Florian> trackbot, point
  64. # [10:31] <trackbot> Sorry, Florian, I don't understand 'trackbot, point'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
  65. # [10:31] <Florian> trackbot, pointer
  66. # [10:31] <trackbot> Sorry, Florian, I don't understand 'trackbot, pointer'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
  67. # [10:31] <Florian> rssagent, point
  68. # [10:31] <Florian> rssagent, pointer
  69. # [10:31] <Florian> Meeting: Editing TF face to face
  70. # [10:32] <Florian> rssagent, log
  71. # [10:33] <rniwa> https://github.com/w3c/editing/issues/77#
  72. # [10:33] <Florian> rrsagent, pointer
  73. # [10:33] <RRSAgent> See http://www.w3.org/2015/08/24-webapps-irc#T08-33-14
  74. # [10:34] <Florian> Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan
  75. # [10:34] <Florian> Scribe: Florian
  76. # [10:34] * Joins: wilsonpage (~wilsonpage@public.cloak)
  77. # [10:35] * Joins: tantek (~tantek@public.cloak)
  78. # [10:36] <Florian> Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting
  79. # [10:36] <Florian> Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan, tantek
  80. # [10:36] <tantek> hello
  81. # [10:37] * Joins: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak)
  82. # [10:40] <Florian> Enrica: Should we keep talking about multirange selections?
  83. # [10:40] <Florian> Florian: let's do that when we have mozilla on the phone later today
  84. # [10:41] <Florian> Chair: chaals
  85. # [10:42] * Joins: chaals (~Adium@public.cloak)
  86. # [10:42] <Florian> Johannes: Ehsan will call at 2pm. We will talk about selection normalization then as well.
  87. # [10:43] <Florian> Present: Ryosuke, SamW, Enrica, SimonS, Grisha, Piotr, Florian, Johannes, Johan, tantek, chaals
  88. # [10:44] * Joins: chaals1 (~Adium@public.cloak)
  89. # [10:44] <chaals1> rrsagent, draft minutes
  90. # [10:44] <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html chaals1
  91. # [10:45] <chaals1> scribe: chaals
  92. # [10:45] <chaals1> agenda?
  93. # [10:46] <chaals1> zakim, agenda?
  94. # [10:46] <Florian> Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting
  95. # [10:46] * chaals1 changes topic to 'Editing TF f2f. Ping us for remote connection. minutes: http://www.w3.org/2015/08/24-webapps-minutes.html'
  96. # [10:48] <chaals1> Topic: input events
  97. # [10:48] <Florian> https://github.com/w3c/editing/issues/72
  98. # [10:48] <chaals1> JW: looking at issues 71 and 72, wonder if we should change the name of events, or keep it but make it clear that this is only for cE, or deal with input/textarea events (later?)
  99. # [10:49] <chaals1> … stuff do deal with selection should be in the selection API.
  100. # [10:49] <chaals1> … but they need the intention of what the user wanted to do…
  101. # [10:49] <Florian> s/71 and 72/72 and 73/
  102. # [10:49] <chaals1> RN: Fine to spec in selection.
  103. # [10:49] * Quits: chaals (~Adium@public.cloak) (Ping timeout: 180 seconds)
  104. # [10:50] * chaals1 is now known as chaals
  105. # [10:50] <chaals> … caret is a type of selection…
  106. # [10:50] <chaals> JW: What about name - does it apply to input fields as well?
  107. # [10:51] <chaals> RN: interesting question - what happens in a multi-range selection. Do we fire beforeinput events with multiple ranges, or multiple single events one per range?
  108. # [10:51] <chaals> JW: don't mind
  109. # [10:51] <chaals> FR: Think it is better to have a single event with all the data to eenable doing smart things
  110. # [10:51] <chaals> SW: so targetRanges?
  111. # [10:51] <chaals> Johan: then we need an array for the ranges.
  112. # [10:52] <chaals> … you can delete at multiple locations
  113. # [10:52] <chaals> RN: There isn't a way to insert different characters in different locations
  114. # [10:52] <chaals> FR: You can put the same data in multiple places at once...
  115. # [10:52] <chaals> SW: But it is the same data and three targetRanges
  116. # [10:53] <chaals> JW: So we need targetranges?
  117. # [10:53] <chaals> [yes]
  118. # [10:54] <chaals> JW: Input on what to do with input?
  119. # [10:54] <chaals> FR: This is pretty different, making it apply is odd. The name is confusing.
  120. # [10:54] <chaals> EC: Call it the editing event?
  121. # [10:54] <chaals> JW: beforeEditing?
  122. # [10:54] <chaals> EC: yeah, beforeEdit …
  123. # [10:55] <chaals> JW: Only applies to contenteditable, right?
  124. # [10:55] <chaals> PK: We have beforeinput on ce=true
  125. # [10:55] <chaals> s/beforeinput/input/
  126. # [10:55] <chaals> JW: Input events have change and input. ce has input and what we call this...
  127. # [10:56] <chaals> SW: Problem?
  128. # [10:56] <chaals> FR: beforeinput doesn't work on input elements
  129. # [10:56] <chaals> [what the input event does]
  130. # [10:58] <Florian> https://developer.mozilla.org/en-US/docs/Web/Events/input
  131. # [11:00] <chaals> FR: There is already a beforeinput event
  132. # [11:00] <chaals> JW: This spec has different fields for the event
  133. # [11:01] <chaals> … so can we override the other event, or should we call ours something else - beforeEdit?
  134. # [11:01] <chaals> … don't mind which.
  135. # [11:02] <chaals> FR: Ours is supposed to be the same as the general one, no?
  136. # [11:02] <johanneswilm> http://w3c.github.io/editing/input-events.html
  137. # [11:02] <chaals> JW: Thought so, but seems not.
  138. # [11:03] <chaals> EC: In webkit we fire input events for input/textarea events...
  139. # [11:03] <chaals> … so they seem to be disjoint.
  140. # [11:03] <chaals> … Why don't we go completely disjoint?
  141. # [11:05] <chaals> JW: Think it is a good idea to have a different name.
  142. # [11:06] <chaals> PK: We should check other browsers too...
  143. # [11:08] <chaals> [should we use the input event? no, having multiple events of the same name leads to confusion]
  144. # [11:08] <chaals> PK: There is apparently input n ce in firefox but seems broken
  145. # [11:08] <PiotrekKoszulinski> http://jsfiddle.net/hxh4ybsf/
  146. # [11:09] * Joins: Johan_S_rlin (~Johan_S_rlin@public.cloak)
  147. # [11:14] <chaals> [does pgup pgdn move the caret? Sometimes, but not others]
  148. # [11:15] <chaals> SW: We could spec it, but it would never fire in Safari
  149. # [11:15] <chaals> RN: it needs to fire in selection...
  150. # [11:15] <chaals> … so if we spec it that means we would need to support it
  151. # [11:16] <chaals> EC: Moving caret by a page isn't deterministic…
  152. # [11:17] <chaals> CMN: Not unusual for a user to do that though
  153. # [11:17] <chaals> SW: Wonder if we should be linking up everything that platforms can do.
  154. # [11:18] <chaals> … we *could* implement this - but think we're ratholing something that isn't that important.
  155. # [11:18] <chaals> RN: We wouldn't trigger this from user actions
  156. # [11:19] <chaals> SW: But if authors want to make something, good luck to them.
  157. # [11:20] <chaals> RESOLUTION: remove caret, and put it in beforeselectionchange in selection API
  158. # [11:21] <chaals> RESOLUTION: We call the relevant events edit and beforeedit (instead of overloading input)
  159. # [11:21] <chaals> EC: If we do this let's have home, start/end of doc, etc etc
  160. # [11:22] <chaals> RN: Home is line boundary, ctrl-home is document boundary
  161. # [11:24] <chaals> EC: So we are left with the things that are not selection… insert/replace char/text/content, un/do
  162. # [11:24] <chaals> RN: Why do we need different things for replacing text or content?
  163. # [11:25] <chaals> JW: Don't suppose we do. Lets get rid of replaceText and make it content.
  164. # [11:26] <chaals> RN: Might want to add another boolean for spellchecking
  165. # [11:27] <chaals> CMN: Does it matter?
  166. # [11:27] <chaals> EC: If you want to do visualisation ...
  167. # [11:27] <chaals> RN: IME will also do replacecontent
  168. # [11:28] <chaals> FR: The boundary between typing and spellchecking is fluid
  169. # [11:28] <chaals> EC: So this comes from the browser saying it wants to autocorrect something?
  170. # [11:30] <chaals> [is there a fingerprinting issue with noting something is autocorrected?]
  171. # [11:32] <chaals> [probably - you can see the dictionary, and how often people are making mistakes. But what's the real problem?]
  172. # [11:32] <chaals> SW: Don't think there is a real problem here
  173. # [11:32] <chaals> FR: What's the value in doing this?
  174. # [11:33] <chaals> PK: e.g. so you don't move the selection there
  175. # [11:33] <chaals> JW: That's why replacecontent should not move the caret.
  176. # [11:33] <chaals> SW: This would also happen on dictation, where words that were put there are updated later.
  177. # [11:34] * Quits: weinig (~weinig@public.cloak) (weinig)
  178. # [11:35] <chaals> [When you replace content, the offset for the cursor is probably different…]
  179. # [11:36] * Joins: weinig (~weinig@public.cloak)
  180. # [11:37] <chaals> JW: Whatever the common behaviour is when content is replaced, keep doing that…
  181. # [11:38] <johanneswilm> https://github.com/w3c/editing/issues/25
  182. # [11:38] <chaals> JW: MS Office team want to know the source for the edit event… #25
  183. # [11:39] <chaals> lya: if you have a floatingUI that comes up when you select something, you need to know how the selection happens
  184. # [11:39] * wilsonpage is now known as wilsonpage-away
  185. # [11:39] <chaals> FR: so you get different behaviour depending on whether you used keyboard or mouse?
  186. # [11:39] * wilsonpage-away is now known as wilsonpage
  187. # [11:39] <chaals> Ilya: Are they asking for this to be specified
  188. # [11:40] <chaals> JW: yes…
  189. # [11:43] <chaals> [do they need to know what they are actually asking here - what a given keyboard event will actually fire…]
  190. # [11:44] <chaals> SW: issue is that we don't support progressive enhancement and we need a viable way for that to happen…
  191. # [11:45] <chaals> FR: A browser may have an event type, but not actually fire it ever…
  192. # [11:47] <chaals> CMN: feature detection breaks…
  193. # [11:48] <chaals> SW: This is hard because our events fire after the old event, so you don't know if it will trigger the new event…
  194. # [11:48] <chaals> EC: Why not do something similar with execcommand - would that be crazy?
  195. # [11:49] <chaals> SW: Not for knowing the source of the event, but that is a different problem.
  196. # [11:49] <chaals> … hard part is knowing the set of sources
  197. # [11:49] <chaals> EC: We could have an enum that we can extend.
  198. # [11:54] * Quits: grisha (~grisha@public.cloak) (Ping timeout: 180 seconds)
  199. # [11:54] * Quits: weinig (~weinig@public.cloak) (weinig)
  200. # [11:55] * Quits: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak) (Ping timeout: 180 seconds)
  201. # [11:57] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  202. # [12:07] * Joins: johanneswilm (~johannes@public.cloak)
  203. # [12:08] * Joins: weinig (~weinig@public.cloak)
  204. # [12:10] <chaals> Topic: can we do progressive enhancement…
  205. # [12:10] <chaals> SW: remains an open issue.
  206. # [12:10] * Joins: grisha (~grisha@public.cloak)
  207. # [12:10] <chaals> CMN: there are a lot of gotchas, too
  208. # [12:10] <chaals> s/Ilya/Grisha/G
  209. # [12:11] <chaals> Topic: Can we put the source?
  210. # [12:11] <chaals> JW: That's not so hard, right?
  211. # [12:11] <chaals> FR: listing things isn't a great idea
  212. # [12:11] * Joins: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak)
  213. # [12:11] <chaals> Grisha: So we need a table of accelerators to fire a function… who maintains that?
  214. # [12:11] <chaals> JW: Your browser.
  215. # [12:12] <chaals> FR: That's the problem with the list - you don't know what to do with a source you didn't know about in advance
  216. # [12:15] <chaals> CMN: see also Brian Kardell's input-modality proposal in WICG
  217. # [12:15] <chaals> RN: Can we have a relatedEvent?
  218. # [12:15] <chaals> SW: Sometimes. But not if find causes a selection.
  219. # [12:17] <chaals> CMN: We don't really want authors listening to device-specific events, because they make a mess of it…
  220. # [12:17] <chaals> FR: Authors should not have to care about dev-specific events, but they should be able to care…
  221. # [12:19] <chaals> SW: Don't think supporting this is high priority
  222. # [12:19] <chaals> CMN: Maybe not, and it will probably be misused more than well used, but authors really really want it all the time :(
  223. # [12:21] <chaals> RN: If you have a timer to check whether an intention is for a particular keydown, we cannot guarantee the association.
  224. # [12:21] <chaals> SW: Having a pointer to the event that caused something, or null, might be enough.
  225. # [12:22] <chaals> RN: That would more or less address the use case.
  226. # [12:22] <chaals> FR: There is a risk that people will make assumptions about why they get null…
  227. # [12:22] <chaals> SW: Don't think it is a huge issue
  228. # [12:23] <chaals> RN: What if a combination of events were the cause of a single DI event?
  229. # [12:23] <chaals> SW: last one? Still don't think this is an important problem to solve.
  230. # [12:24] <chaals> RN: You want to prollyfill, so if there is a ctrl-C you set a timer to see if it fired a copy… and if it didn't, you fire one.
  231. # [12:25] * Quits: weinig (~weinig@public.cloak) (weinig)
  232. # [12:27] <chaals> JW: you want to know what things are working...
  233. # [12:28] * Joins: weinig (~weinig@public.cloak)
  234. # [12:29] <chaals> SW: So #19 and #25 are the same thing?
  235. # [12:30] <chaals> CMN: similar…
  236. # [12:31] <chaals> FR: So the relatedEvent thing is probably not that bad...
  237. # [12:34] <chaals> TC: Maybe you really should record a use case of supporting polyfills
  238. # [12:35] <chaals> RESOLUTION: have a relatedEvent to point to the UI event that caused a DI event to be fired.
  239. # [12:38] <rniwa> Filed https://github.com/w3c/editing/issues/78
  240. # [12:39] <chaals> Topic: Deleting content
  241. # [12:39] <chaals> Grisha: is there a reason to have the 3 different delete events?
  242. # [12:40] <chaals> JW: If people click delete button or backspace, you have different things happen.
  243. # [12:40] <chaals> … if you build track changes you get the intent to delete forward, move the caret
  244. # [12:40] <chaals> EC: can we have one delete event and use attributes? Ditto for insertCharacter/Line
  245. # [12:41] <chaals> RN: There is a difference between line break and paragraph break.
  246. # [12:42] <chaals> … don't think we want to collapse lines and characters - and would like to have a way of inserting a paragraph. Agree that we should have forward/backward as an attribute on the delete event.
  247. # [12:43] * Quits: weinig (~weinig@public.cloak) (weinig)
  248. # [12:43] * Joins: weinig (~weinig@public.cloak)
  249. # [12:45] <chaals> [A use case for delete backwards - tracking changes means that the delete thing doesn't remove the content, but marks it and moves the caret backwards]
  250. # [12:52] <chaals> EC: When do we fire deleteContent?
  251. # [12:52] <chaals> RN: A default of keypress
  252. # [12:52] <chaals> FR: The default will be forward or backward
  253. # [12:53] <chaals> … we don't need deleteContent if it is only for an edge case
  254. # [12:53] <chaals> EC: So if someone presses an "h", what do I fire?
  255. # [12:55] * Quits: weinig (~weinig@public.cloak) (weinig)
  256. # [12:56] <chaals> [insertcharacter, or replacecharacter]
  257. # [12:57] * Joins: weinig (~weinig@public.cloak)
  258. # [12:57] <chaals> CMN: with a delete event that has forward/backward, if it has neither then it is basically replace with nothing
  259. # [12:57] * Quits: weinig (~weinig@public.cloak) (weinig)
  260. # [12:59] <chaals> FR: The problem is if you are listening for delete, when sometimes what is fired is a replace with empty, then you get complexity.
  261. # [13:00] * Joins: weinig (~weinig@public.cloak)
  262. # [13:01] <chaals> RESOLUTION: one delete event with data for forward/backward
  263. # [13:02] <chaals> FR: Typing/replacing at caret/selection uses insert, doing it elsewhere uses replace
  264. # [13:02] <chaals> RESOLUTION: We want to be able to insert newline or new paragraph
  265. # [13:03] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  266. # [13:03] <chaals> [lunch]
  267. # [13:03] * Quits: enrica (~enrica@public.cloak) (enrica)
  268. # [13:03] * heycam is now known as heycam|away
  269. # [13:07] * Quits: weinig (~weinig@public.cloak) (weinig)
  270. # [13:10] * Quits: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak) (Ping timeout: 180 seconds)
  271. # [13:25] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  272. # [13:32] * wilsonpage is now known as wilsonpage-away
  273. # [13:49] * heycam|away is now known as heycam
  274. # [13:55] * Joins: weinig (~weinig@public.cloak)
  275. # [13:56] * Joins: enrica (~enrica@public.cloak)
  276. # [13:56] * Joins: chaals (~Adium@public.cloak)
  277. # [14:04] <chaals> Present+ Ehsan(videconf)
  278. # [14:04] * Joins: Florian (~Florian@public.cloak)
  279. # [14:04] <chaals> Present+ Johannes, Johan, Chaals, Ryosuke, Grisha, Piotr, SamW, Enrica, SimonS, Tantek
  280. # [14:04] <chaals> Topic: selections
  281. # [14:05] <chaals> Ryosuke: If we allow JS to set selection, can we always render a selection caret?
  282. # [14:06] <chaals> … we currently do normalisation of selection endpoints, but going forward we want to change that.
  283. # [14:07] <chaals> EA: Gecko tries to be permissive, ask where the selection goes and try to get a caret there.
  284. # [14:07] <chaals> … there are edge case bugs, but we restructured this a few years ago which helped in a bunch of situations for getting carets where we couldn't.
  285. # [14:07] <chaals> … So things are better, but it isn't perfect yet. It is impossible to predict every possible place to put the caret.
  286. # [14:08] <chaals> RN: Would you be OK with not doing normalisation?
  287. # [14:09] * Joins: ehsan (~ehsan@public.cloak)
  288. # [14:09] <ehsan> the audio feed stopped
  289. # [14:09] <rniwa> Is Gecko okay with not normalizing selection when JavaScript modifies it
  290. # [14:09] <ehsan> rniwa: ^
  291. # [14:09] * chaals we stopped talking
  292. # [14:09] <ehsan> yes, in the abstract sense :)
  293. # [14:09] <chaals> rrsagent, draft minutes
  294. # [14:09] <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html chaals
  295. # [14:10] * Joins: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak)
  296. # [14:10] <chaals> RN: Current proposal is not to normalise selection when JS modifies it.
  297. # [14:10] <chaals> … do we need to specify a guarantee of wher the caret can be?
  298. # [14:10] * Joins: smaug (~chatzilla@public.cloak)
  299. # [14:10] <chaals> … e.g. we cannot render a caret in an element with display none.
  300. # [14:11] <chaals> … also in a japanese IME in composition there is often no caret.
  301. # [14:11] <chaals> … Can these be specified?
  302. # [14:11] <chaals> EA: Harder cases are where selection goes into part ofthe DOM that is obscured by another element.
  303. # [14:11] * wilsonpage-away is now known as wilsonpage
  304. # [14:11] <johanneswilm> examples of where the caret doesn't go or doesn't render: https://bug873883.bmoattachments.org/attachment.cgi?id=751510
  305. # [14:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  306. # [14:12] <chaals> … Or where user places caret next to an image. Should we render it on the border of the image?
  307. # [14:12] <chaals> … How does it combine with background colour of image…
  308. # [14:12] <chaals> … There are some other tricky cases. The button element - should it go inside it or not?
  309. # [14:13] <chaals> … there is a text node underneath it, so it makes sense to be able to edit that, or it is a form control and it makes no sense to allow editing it…
  310. # [14:13] <chaals> … there is value in specifying how the browser deals with these situations. We can normalise things, or list the possible cases…
  311. # [14:13] * Quits: tantek (~tantek@public.cloak) (tantek)
  312. # [14:14] <chaals> JW: e.g. can't get between two canvas elements immediately adjacent in Firefox, can go between SVGs, but cannot in Chrome, etc...
  313. # [14:15] <chaals> … do we want a guarantee of where things will go?
  314. # [14:16] <chaals> EA: 2 cases to consider - caret when you are using keyboard to navigate, and when JS moves it. There are many places where you cannot get a caret with user navigation keys, but can do it wiith script.
  315. # [14:16] <chaals> … There are 2 classes of problems, some putting the caret there and some painting it.
  316. # [14:16] <chaals> RN: yes, we have those 2 kinds of issues.
  317. # [14:17] <chaals> EA: 3rd question - whether we should do caret navigation through the DOM or the rendered page.
  318. # [14:17] <chaals> … Gecko does screen-based navigation - sometimes weird but often better.
  319. # [14:18] * Joins: tantek (~tantek@public.cloak)
  320. # [14:18] <chaals> JW: We left how the caret moves unspecified for now. Important thing is that you can get the caret "everywhere it should" and be rendered there
  321. # [14:19] <chaals> … we want to avoid cases where the caret is now where it looks like it is. We realise there are places you cannot get to, but if we can move the caret there with JS that shoud be enough.
  322. # [14:19] * Joins: Florian (~Florian@public.cloak)
  323. # [14:19] <chaals> RN: Browser bugs *will* exist…
  324. # [14:20] <chaals> EC: Idea is that with JS you can place selection anywhere, and there will be no attempt to move it to be visible. So if it is put into an invisible element you just won't see it, but that will be a legitimate thing to do?
  325. # [14:20] <chaals> JW: In certain places we want a guarantee that the caret will be rendered.
  326. # [14:21] <chaals> RN: Don't think we need a restriction - I think it is premature to spec a list of places where carets must be rendered.
  327. # [14:21] <chaals> … we need implementation experience of not normalising first, and need to fix caret-painting bugs.
  328. # [14:22] <chaals> EA: Now position of caret is not observable by script. Are we going to add that?
  329. # [14:22] <chaals> RN: Think we are still using collapsed selection. We discussed this yesterday
  330. # [14:22] <chaals> … at boundary of bidi levels we could have two caret positions, so there would be two rectangles.
  331. # [14:23] <chaals> … We need to sort out carets in vertical mode, too.
  332. # [14:23] * Quits: weinig (~weinig@public.cloak) (weinig)
  333. # [14:23] <chaals> EA: Collapsed selection is probably OK. Not sure it is useful for authors, but it is what we do now.
  334. # [14:24] <chaals> FR: Logical position of caret is offset, plus bidi level, plus if you are at a line break. This gives enough to find out where you are, or to specify where a caret should be.
  335. # [14:26] <chaals> RN: Discussed adding a new selection object. Current selection API seems to be misused. Argument that one reason is the interface makes it hard to understand that you have to get the counts and collect them, so Ojan selected we have an iterator of ranges that may help get better quality support.
  336. # [14:26] <chaals> … in multi-range world, the fact we have anchor, etc, looks like a single range and not so smart for a set of them.
  337. # [14:27] <chaals> … So if we have a multiple range selection in a new API, we can carry caret information better.
  338. # [14:27] <chaals> FR: Other issue motivating a new selection API was a desire for non-Live nodes…
  339. # [14:28] <chaals> EA: Performance implications for keeping ranges alive… supporting multi-range selections, do other vendors want to do it?
  340. # [14:29] <chaals> RN: Apple is - for example so you can select content visually when different boxes are laid out and aren't in DOM order.
  341. # [14:30] <chaals> FR: And selecting rectangles on a touch device…
  342. # [14:30] <chaals> … selecting across a user-select: none thing…
  343. # [14:32] <chaals> EA: We can enable users to select multiple things at a time - another example is selecting table cells.
  344. # [14:32] <chaals> … how many of these cases do we want to expose? (not all of them are necessary to support)
  345. # [14:33] <chaals> … Multi-range selection is very very difficult to implement properly - there are lots of points in code that need to deal with it.
  346. # [14:33] <chaals> … So it is great for the user, but very hard for the engine.
  347. # [14:35] <chaals> FR: If we let JS author create selections however tehy want, they can create e.g. overlapping ranges. We considered throwing exceptions to stop that, and backed off to say we would allow overlapping selections, only normalise if you tried to exec command, otherwise leave it up to the scripter to decide how to handle their weird results
  348. # [14:36] <chaals> EA: Seen pages put selections in places that make no sense. Hard to say what the right behaviour should be. Whatever we choose, we want to be consistent across browsers.
  349. # [14:37] * Joins: weinig (~weinig@public.cloak)
  350. # [14:38] <chaals> FR: Do you mean problem rendering selection, or how the selection braks exec comman in e.g. overlapping ranges
  351. # [14:38] <chaals> EA: We e.g. display visual selection behaviour selecting a run from RTL to LTR, but select logically, which is of course a bug
  352. # [14:41] <chaals> FR: If an editor wants to e.g. allow visual selection across bidi boundaries, they need multiple ranges and don't want the selection to move from under them?
  353. # [14:42] <chaals> PK: We like gecko's behaviour because we know where it will put text. For multi-range, allowing table selection is interesting even though it can be faked if it isn't supported.
  354. # [14:42] <chaals> EC: How does gecko handle copy? Do you take a single fragment or keep a set of fragments on clipboard?
  355. # [14:43] <chaals> EA: we iterate over each one, don't remember how we handle the gap…
  356. # [14:44] <chaals> … *think* we put some break between the ranges
  357. # [14:44] <chaals> FR: Seems like you put double line break between fragments.
  358. # [14:45] <chaals> EC: What happens if you copied 3 disjoint things and try to paste into 2 ranges.
  359. # [14:45] <chaals> FR: You replace the first range with the whole clipboard, and just delete the second range.
  360. # [14:47] <chaals> EA: This is an example of where correct behaviour is non-obvious. E.g. select items from an ordered list and an unordered list nested, and delete things so you promote list items from the sub-list to the parent list.
  361. # [14:47] <chaals> … ther are a lot of these tricky cases where we just do *something* because there is no sane behaviour.
  362. # [14:48] <chaals> FR: Tables are an example of where there is an obvious behaviour that is hard - e.g. copy column and paste to another column should not paste the column into the first replaced cell, but …
  363. # [14:49] <chaals> EC: WOuld be easy to leave it up to implementation what to do.
  364. # [14:49] <chaals> FR: The browser should do the simple and predictable thing, and leave it up to JS editor developers to customise behaviour in smarter ways.
  365. # [14:50] <chaals> EA: I am sure there are cases where it is hard to come up with "the simple predictable behaviour".
  366. # [14:52] <chaals> RN: Think the current plan for ce=typing is for each app to implement bolding, underline etc themselves, so they decide on what "sensible behaviour" is.
  367. # [14:52] <chaals> … if we want to let app decide what to do with multi-range copy/paste, we need to have the information available about where each piece came from.
  368. # [14:53] <chaals> … cut/paste multi ranges in the same place should look like a noop… which takes lots of information about what is in the clipboard
  369. # [14:54] <chaals> FR: We have beforeedit that says what is going to happen, but in order to do the smart thing, you need to have the structure available
  370. # [14:54] <chaals> … don't need to stitch together in the clipboard, do we?
  371. # [14:55] <chaals> RN: Stitching may not happen in clipboard. It doesn't assume there are multiple pieces in the clipboard - there is no way to support that
  372. # [14:55] <chaals> SW: Yes you can, at least on Mac, annotate types and multiple pieces.
  373. # [14:56] <chaals> EA: Even if clipboard understands format, you are bound by common denomiator of different clipboards. As far as I recall there is no clipboard that allows for multiple pieces somewhere, so gecko needs to stitch the pieces together.
  374. # [14:56] <chaals> EC: There is also the issue of exposing this to the clipboard API.
  375. # [14:57] * Joins: jyasskin (~textual@public.cloak)
  376. # [14:57] <chaals> FR: If you don't have multi-piece clipboards, you may be able to intercept the copy event and annotate with extra information, but then those annotations will do weird things e.g. on paste inot a different application.
  377. # [14:58] <chaals> EA: You can copy different formats at the same time. If the goal is to have copy-paste within the browser, you can invent your own format.
  378. # [14:59] <chaals> … Paste into another application would show there is text/html (stitched) or magic-firefox-clipboard-format… would that be good enough, or cause problems because you can't paste from FF to IE?
  379. # [15:00] <MikeSmith> RRSAgent, make minutes
  380. # [15:00] <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html MikeSmith
  381. # [15:00] <chaals> FR: Or copy HTML table and paste into Excel
  382. # [15:00] <chaals> RN: We could spec the annotation we add in a browser to provide structure information…
  383. # [15:01] <chaals> … if that were supported across browsers it seems other apps could recognise it too.
  384. # [15:01] <chaals> EC: Not sure we should specify the clipboard format for native platform… we should specify what goes there to use with clipboard API
  385. # [15:02] <chaals> … anyone can specify as many formats as they want to post to clipboard. Think we should aim for copy/paste consistency within an app, not so sure we need to have fidelity copying from one browser to another.
  386. # [15:03] <chaals> FR: If we manage to get this working for a given browser, then maybe we can go to a standard clipboard format
  387. # [15:03] <chaals> RN: Browser vendors can't change the format, it is an OS-based format they use.
  388. # [15:03] <chaals> FR: But we can standardise an additional format that we could put in which is interoperable.
  389. # [15:04] <chaals> SW: We don't need to debate this now if it is a "later on" feature.
  390. # [15:04] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  391. # [15:06] <chaals> Topic: deleting…
  392. # [15:06] <chaals> FR: We thought we had a non-overlapping set of things for when to delete and when to replace…
  393. # [15:06] <chaals> … but what if you do alt-backspace - delete something that isn't selected, but with direction.
  394. # [15:07] <chaals> … if delete doesn't have a range other than selection you cannot use it for e.g. previous line…
  395. # [15:08] <chaals> EC: Thought these were low-level events where you got the info backwards/forward. Now you are asking for more commands, like word or line.
  396. # [15:08] <chaals> JW: If the caret moves, why not select the word and then delete it?
  397. # [15:08] <chaals> FR: Yes, we could do that. Perhaps save previous selection, delete the word, restore ...
  398. # [15:09] <chaals> FR: If browser has a native deleteWord, it is a thing that it would do.
  399. # [15:09] <chaals> … depends on how that is implemented, maybe it already does the right thing.
  400. # [15:09] <chaals> JW: So the caret moves, so I think we are fine.
  401. # [15:10] <chaals> PK: What if I cancel the deletion but not the selection of the word before that.
  402. # [15:10] <chaals> JW: Tough luck…
  403. # [15:11] * Joins: jyasskin (~textual@public.cloak)
  404. # [15:11] <chaals> FR: You don't know that you get select in order to delete.
  405. # [15:11] <chaals> CMN: If you have relatedEvent then perhaps you do...
  406. # [15:11] <chaals> RN: WHy not targetRange?
  407. # [15:11] <chaals> FR: There isn't one on delete, only on replace.
  408. # [15:12] <chaals> … otherwise there is overlap between delete and replace.
  409. # [15:12] <chaals> RN: Don't think that is an issue.
  410. # [15:12] <chaals> … we can spec them around this.
  411. # [15:12] <chaals> FR: Yes, but that is harder to make happen.
  412. # [15:13] <chaals> RN: All commands should always work on target range.
  413. # [15:14] <chaals> EC: So what happens in ce=typing when user types "hello". I select "lo", press delete. What events come out?
  414. # [15:14] <chaals> RN: targetrange are those characters, will delete backward.
  415. # [15:15] <chaals> EC: and user presses "delete word"? Webkit changes selection to select word, deletes.
  416. # [15:15] <chaals> RN: Same. select the content, delete backward with targetrange as what was selected.
  417. # [15:15] <chaals> [chaals leaves]
  418. # [15:16] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  419. # [15:16] * Quits: weinig (~weinig@public.cloak) (weinig)
  420. # [15:21] * Quits: PiotrekKoszulinski (~PiotrekKoszulinski@public.cloak) (Ping timeout: 180 seconds)
  421. # [15:24] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  422. # [15:36] <MikeSmith> is the meeting still going on?
  423. # [15:37] <MikeSmith> is somebody else taking notes elsewhere? (etherpad or something)
  424. # [15:37] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  425. # [15:39] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  426. # [15:42] * Quits: grisha (~grisha@public.cloak) (Ping timeout: 180 seconds)
  427. # [15:45] * Quits: Johan_S_rlin (~Johan_S_rlin@public.cloak) (Ping timeout: 180 seconds)
  428. # [15:46] * Quits: smaug (~chatzilla@public.cloak) (Client closed connection)
  429. # [15:46] * Joins: smaug (~chatzilla@public.cloak)
  430. # [15:49] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  431. # [15:50] * Quits: enrica (~enrica@public.cloak) (enrica)
  432. # [16:03] <tantek> MikeSmith - meeting is over
  433. # [16:03] <MikeSmith> tantek: ah ok
  434. # [16:03] <MikeSmith> thanks
  435. # [16:03] <tantek> notes were all in IRC - no separate etherpad AFAIK
  436. # [16:04] <MikeSmith> ok
  437. # [16:04] <MikeSmith> chaals just sorta seemed to drop the mic there
  438. # [16:04] <MikeSmith> today and yesterday too
  439. # [16:04] <tantek> rrsagent, make minutes public
  440. # [16:04] <RRSAgent> I'm logging. I don't understand 'make minutes public', tantek. Try /msg RRSAgent help
  441. # [16:04] <tantek> rrsagent, pointer
  442. # [16:04] <RRSAgent> See http://www.w3.org/2015/08/24-webapps-irc#T14-04-21
  443. # [16:04] <tantek> rrsagent, make minutes
  444. # [16:04] <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webapps-minutes.html tantek
  445. # [16:05] * Joins: shepazu (schepers@public.cloak)
  446. # [16:23] * Joins: Florian (~Florian@public.cloak)
  447. # [16:31] * Quits: ehsan (~ehsan@public.cloak) (Client closed connection)
  448. # [16:49] * Joins: johanneswilm (~johannes@public.cloak)
  449. # [17:21] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  450. # [17:22] * Joins: Florian (~Florian@public.cloak)
  451. # [17:25] * Joins: Spocke (~Spocke@public.cloak)
  452. # [17:26] * Quits: Spocke (~Spocke@public.cloak) ("Page closed")
  453. # [17:34] * Joins: Lachy (~Lachy@public.cloak)
  454. # [17:36] * Quits: tantek (~tantek@public.cloak) (tantek)
  455. # [17:44] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  456. # [17:45] * Joins: Florian (~Florian@public.cloak)
  457. # [17:45] * Quits: Lachy (~Lachy@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
  458. # [17:46] * Joins: tantek (~tantek@public.cloak)
  459. # [18:02] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  460. # [18:02] * Joins: Florian (~Florian@public.cloak)
  461. # [18:09] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  462. # [18:09] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  463. # [18:24] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  464. # [18:37] * Joins: marcosc (~marcosc@public.cloak)
  465. # [18:38] * Quits: marcosc (~marcosc@public.cloak) ("")
  466. # [18:43] * Joins: marcosc (~marcosc@public.cloak)
  467. # [18:46] * Quits: dom (dom@public.cloak) ("")
  468. # [18:46] * Joins: jyasskin (~textual@public.cloak)
  469. # [18:50] * Quits: tantek (~tantek@public.cloak) (tantek)
  470. # [18:52] * heycam is now known as heycam|away
  471. # [18:59] * Joins: jsbell (~jsbell@public.cloak)
  472. # [19:15] * Joins: wilsonpage (~wilsonpage@public.cloak)
  473. # [19:44] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
  474. # [19:46] * Joins: marcosc (~marcosc@public.cloak)
  475. # [21:14] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  476. # [21:21] * Joins: wilsonpage (~wilsonpage@public.cloak)
  477. # [21:22] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  478. # [21:23] * Joins: shepazu (schepers@public.cloak)
  479. # [21:23] * Quits: shepazu (schepers@public.cloak)
  480. # [21:25] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  481. # [21:26] * Joins: wilsonpage (~wilsonpage@public.cloak)
  482. # [21:32] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  483. # [21:34] * Joins: shepazu (schepers@public.cloak)
  484. # [21:35] * Joins: wilsonpage (~wilsonpage@public.cloak)
  485. # [21:46] * Joins: johanneswilm (~johannes@public.cloak)
  486. # [21:46] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  487. # [21:58] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
  488. # [22:10] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  489. # [22:25] * Joins: Florian (~Florian@public.cloak)
  490. # [22:30] * Joins: tantek (~tantek@public.cloak)
  491. # [22:30] * Joins: johanneswilm (~johannes@public.cloak)
  492. # [22:38] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  493. # [22:40] * Joins: Florian (~Florian@public.cloak)
  494. # [22:45] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  495. # [22:46] * Joins: Florian (~Florian@public.cloak)
  496. # [23:24] * Joins: weinig (~weinig@public.cloak)
  497. # [23:24] * Quits: weinig (~weinig@public.cloak) (weinig)
  498. # [23:38] * Joins: Lachy (~Lachy@public.cloak)
  499. # Session Close: Tue Aug 25 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn