/irc-logs / w3c / #webapps / 2008-07-29 / end

Options:

  1. # Session Start: Tue Jul 29 00:00:00 2008
  2. # Session Ident: #webapps
  3. # [00:01] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  4. # [00:15] * Joins: shepazu (schepers@128.30.52.30)
  5. # [00:21] * Quits: heycam (cam@124.168.12.194) (Quit: bye)
  6. # [00:37] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  7. # [00:58] * Joins: mjs (mjs@17.203.14.227)
  8. # [01:12] * Joins: mjs_ (mjs@17.255.109.93)
  9. # [01:13] * Quits: mjs (mjs@17.203.14.227) (Ping timeout)
  10. # [01:15] * Joins: mjs (mjs@17.203.14.227)
  11. # [01:17] * Quits: mjs_ (mjs@17.255.109.93) (Ping timeout)
  12. # [01:22] * Joins: shepazu (schepers@128.30.52.30)
  13. # [01:59] <Hixie> shepazu: do you know if the intent is for dom3 events to have conformance criteria for the firing of events like dblclick?
  14. # [02:00] * Quits: aroben (aroben@71.58.56.76) (Quit: aroben)
  15. # [02:00] <shepazu> Hixie: what kind of conformance criteria did you have in mind, that isn't covered by the spec now?
  16. # [02:01] <shepazu> in general, the intent is to be as conformy criteriac as possible
  17. # [02:02] <Hixie> like, "when the user clicks a coordinate x,y, the user agent must fire a click event" with a description of what the event is required to be like, and what its default action should be, etc
  18. # [02:02] <shepazu> ah, yeah, sounds like it should be done
  19. # [02:03] <Hixie> is there a public issues list for dom3 events anywhere? (is that the tracker?)
  20. # [02:03] <shepazu> it is the tracker, yes... mo
  21. # [02:03] <Hixie> k
  22. # [02:04] <Hixie> should i file something about having requirements for each of the events there?
  23. # [02:04] <shepazu> http://www.w3.org/2008/webapps/track/products/2
  24. # [02:04] <shepazu> feel free to add issues there
  25. # [02:04] <shepazu> thanks!
  26. # [02:04] <Hixie> coo, will do
  27. # [02:05] <shepazu> goodgood
  28. # [02:05] <Hixie> also, right now the dom3 events spec says events capture and bubble on a tree rooted at the Document object, but UAs (well, HTML browsers at least) seem to do it rooted at the Window, with the Window owning the Document -- do you know if the idea is to define that in DOM 3 Events too? Or should I kind of "patch" DOM Events from HTML5 (where Window is defined at the moment)?
  29. # [02:06] <shepazu> hmm
  30. # [02:07] <shepazu> I'd have to look at that closer, but if that's the case with current browsers, we should at least allow for that option explicitly
  31. # [02:07] <shepazu> (seems to me)
  32. # [02:08] <shepazu> please raise an issue on that, if you'd be so kind
  33. # [02:08] <Hixie> will do
  34. # [02:08] <shepazu> (links into the HTML5 spec or other sources would be helpful)
  35. # [02:14] <shepazu> Hixie: also, any evidence that would contra-indicate such changes would be great, so we are aware of what the implications would be
  36. # [02:15] <Hixie> i haven't done much research in this area
  37. # [02:15] <Hixie> but it should be relatively easy to do the reverse engineering for the Window case at least
  38. # [02:15] <shepazu> ok, well, when you post the issue, it will post to the mailing list, and then we'll hopefully get plenty of feedback
  39. # [02:16] <Hixie> done
  40. # [02:19] <shepazu> sweet
  41. # [03:03] * Joins: mjs_ (mjs@17.255.109.93)
  42. # [03:03] * Quits: mjs_ (mjs@17.255.109.93) (Connection reset by peer)
  43. # [03:04] * Quits: mjs (mjs@17.203.14.227) (Ping timeout)
  44. # [03:22] * Joins: harry (kcome@58.213.216.124)
  45. # [04:11] * Joins: mjs (mjs@17.203.14.227)
  46. # [05:06] * Quits: weinig (weinig@17.203.14.159) (Quit: weinig)
  47. # [05:39] * Quits: mjs (mjs@17.203.14.227) (Quit: mjs)
  48. # [05:41] * Joins: mjs (mjs@17.255.109.93)
  49. # [05:42] * Joins: mjs_ (mjs@17.255.109.93)
  50. # [05:42] * Quits: mjs (mjs@17.255.109.93) (Connection reset by peer)
  51. # [05:42] * Quits: mjs_ (mjs@17.255.109.93) (Quit: mjs_)
  52. # [06:06] <shepazu> Hixie: yt?
  53. # [06:07] <shepazu> I notice you pointed out that D3E doesn't define activation behavior, and I wrote up a very quick definition, corrections welcome:
  54. # [06:07] <shepazu> activation behavior
  55. # [06:07] <shepazu> The action taken when an event, typically initiated by users through an input device, causes an element to fulfill a defined role. The role may be defined for that element by the host language, or by author-defined variables, or both. The role for any given element may be a generic action, or may be unique to that element. For example, the activation behavior of an HTML or SVG <a> element is to cause the user agent to traverse the link specified in the
  56. # [06:57] * Joins: mjs (mjs@24.5.43.151)
  57. # [07:04] * Joins: weinig (weinig@71.198.176.23)
  58. # [07:23] * Joins: smaug (chatzilla@216.18.1.210)
  59. # [08:54] * Joins: heycam (cam@124.168.12.194)
  60. # [09:19] * Joins: marcos (marcos@124.171.136.76)
  61. # [09:29] * Quits: marcos (marcos@124.171.136.76) (Quit: marcos)
  62. # [09:33] * Joins: arve (arve@213.236.208.22)
  63. # [09:37] * Quits: mjs (mjs@24.5.43.151) (Quit: mjs)
  64. # [09:43] * Joins: mjs (mjs@24.5.43.151)
  65. # [11:01] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  66. # [11:17] * Joins: Lachy (Lachlan@213.236.208.247)
  67. # [11:20] * Quits: Lachy (Lachlan@213.236.208.247) (Ping timeout)
  68. # [11:20] * Joins: Lachy (Lachlan@213.236.208.22)
  69. # [11:41] <Hixie> shepazu: it's not so much that the term needs to be defined, so much as it needs to be invoked as part of default actions or something
  70. # [11:41] <shepazu> Hixie: this is orthogonal
  71. # [11:41] <Hixie> shepazu: it could be called "foobar" and not be defined at all, as far as i am concerned, so long as it is invoked :-)
  72. # [11:42] <shepazu> 2 different issues... defining the term, and specifying the behavior
  73. # [11:42] <shepazu> I just did the easy one first :)
  74. # [11:43] <Hixie> :-)
  75. # [11:43] <Hixie> i don't usually bother to define the terms like that, i mean, they're pretty self-describing
  76. # [11:43] <Hixie> but to each his own :-)
  77. # [11:45] * Quits: harry (kcome@58.213.216.124) (Ping timeout)
  78. # [12:01] * Joins: harry (kcome@58.213.219.134)
  79. # [12:39] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  80. # [12:39] * Joins: Lachy (Lachlan@213.236.208.22)
  81. # [12:48] * Joins: ArtB (ce846302@128.30.52.43)
  82. # [13:10] * ArtB looks for tlr; sigh ...
  83. # [13:14] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  84. # [14:35] * Joins: peterthiessen (chatzilla@206.132.181.143)
  85. # [15:57] * Joins: aroben (aroben@71.58.56.76)
  86. # [16:09] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  87. # [16:19] * Joins: Lachy (Lachlan@85.196.122.246)
  88. # [16:23] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  89. # [16:23] * Joins: Lachy (Lachlan@85.196.122.246)
  90. # [17:13] * Quits: weinig (weinig@71.198.176.23) (Connection reset by peer)
  91. # [17:13] * Joins: weinig (weinig@71.198.176.23)
  92. # [17:28] * Quits: weinig (weinig@71.198.176.23) (Quit: weinig)
  93. # [17:57] * Joins: weinig (weinig@17.203.14.159)
  94. # [18:55] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  95. # [18:55] * Joins: Hixie (ianh@129.241.93.37)
  96. # [19:00] * Quits: harry (kcome@58.213.219.134) (Ping timeout)
  97. # [19:11] * Joins: marcos (marcos@124.171.136.76)
  98. # [19:33] * Quits: smaug (chatzilla@216.18.1.210) (Ping timeout)
  99. # [19:35] * Quits: ArtB (ce846302@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  100. # [19:38] * Quits: peterthiessen (chatzilla@206.132.181.143) (Ping timeout)
  101. # [19:44] * Joins: tlr (tlr@128.30.52.30)
  102. # [19:47] * Joins: peterthiessen (chatzilla@206.132.181.143)
  103. # [19:47] * Quits: peterthiessen (chatzilla@206.132.181.143) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070206])
  104. # [19:53] * Joins: smaug (chatzilla@216.18.1.210)
  105. # [20:07] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  106. # [20:09] * Quits: mjs (mjs@24.5.43.151) (Quit: mjs)
  107. # [20:21] * Joins: scotfl (scotfl@70.64.14.62)
  108. # [20:21] * Parts: scotfl (scotfl@70.64.14.62)
  109. # [20:27] * Quits: marcos (marcos@124.171.136.76) (Quit: marcos)
  110. # [21:30] * Joins: ArtB (c0646811@128.30.52.43)
  111. # [22:17] * Joins: mjs (mjs@17.255.96.56)
  112. # [23:05] * Quits: mjs (mjs@17.255.96.56) (Quit: mjs)
  113. # [23:09] * Joins: mjs (mjs@17.255.96.56)
  114. # [23:32] * Joins: mjs_ (mjs@17.255.96.56)
  115. # [23:33] * Quits: mjs (mjs@17.255.96.56) (Connection reset by peer)
  116. # [23:46] <Hixie> heycam: yt?
  117. # [23:55] <Hixie> heycam: well anyway, i was going to ask you if you had come up with any solution for the "replaceable" issue
  118. # [23:55] <Hixie> heycam: e.g. window.opener is a readonly Window attribute, but setting it has to work, it blows away the original property and replaces it with whatever the author set
  119. # [23:56] <Hixie> I don't want to define it as a "attribute any opener" that just happens to return a Window until it's set, and then returns whatever it was set to
  120. # [23:56] <Hixie> that's just annoying in the spec
  121. # [23:57] <Hixie> it would be cool if we could have a [Replaceable] attribute that just makes it so that the setter causes the property to be replaced with whatever it was set to, removing all previous semantics of the attribute
  122. # Session Close: Wed Jul 30 00:00:00 2008

The end :)