/irc-logs / freenode / #whatwg / 2007-03-18 / end

Options:

  1. # [0:04] <annevk> and the overloading <object> debate continues
  2. # [0:04] <annevk> yay
  3. # [0:04] <othermaciej> w00t
  4. # [0:05] <annevk> othermaciej, btw, you think we should add the constants to XMLHttpRequest?
  5. # [0:10] <othermaciej> annevk: I don't really have a strong opinion
  6. # [0:10] <othermaciej> they seem nice, but not absolutely necessary
  7. # [0:11] * annevk doesn't really care either
  8. # [0:11] <annevk> but it's trivial to add them in the spec
  9. # [0:11] <annevk> and prolly trivial in implementations too
  10. # [0:12] * twanj (n=chatzill@c-66-176-118-121.hsd1.fl.comcast.net) Quit (Read error: 60 (Operation timed out))
  11. # [0:14] * annevk asks some other implementors
  12. # [0:15] <othermaciej> it is more typical DOM practice to have named constants and not just bare numbers with special meanings for things like this
  13. # [0:16] <annevk> yup
  14. # [0:19] <Dashiva> And the longer the better
  15. # [0:19] <othermaciej> I don't understand why people think <object> is a good thing
  16. # [0:19] <othermaciej> "I'm including something" doesn't seem very semantically meaningful
  17. # [0:20] <othermaciej> making things more generic runs counter to the very idea of semantic markup
  18. # [0:20] <Dashiva> I don't think it's on semantical grounds, more for simplicity and fear of redundance (my guesswork only, of course)
  19. # [0:20] <Hixie> <object> is anything but simple
  20. # [0:21] <othermaciej> <object> is possibly the most complex element in all of HTML
  21. # [0:21] <Dashiva> But not changing the status quo is simpler than doing so
  22. # [0:22] <Hixie> maybe we should drop <object> from HTML5 altogether
  23. # [0:22] * Hixie ducks
  24. # [0:22] <Dashiva> heh
  25. # [0:22] <othermaciej> heh
  26. # [0:22] <Dashiva> I'm sure macromedia would love that
  27. # [0:22] <Hixie> we have <embed> for plugins
  28. # [0:22] <othermaciej> Hixie: is there a list anywhere of which elements HTML5 drops or deprecates that are in HTML4? Is that on the wiki?
  29. # [0:23] <Hixie> dunno off hand, there might be
  30. # [0:23] <annevk> <embed> works better for Flash than <object> anyway
  31. # [0:23] <Dashiva> Does object serve any purposes that aren't served by specific elements?
  32. # [0:23] * hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Read error: 104 (Connection reset by peer))
  33. # [0:23] <Dashiva> iframe, img, video eats up a lot of it
  34. # [0:23] * hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  35. # [0:23] <Dashiva> If embed handles plugins, what's left?
  36. # [0:23] * hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Remote closed the connection)
  37. # [0:24] * hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  38. # [0:24] <annevk> audio...
  39. # [0:24] <annevk> but there's an API for that
  40. # [0:24] <Hixie> we have Audio() for that
  41. # [0:24] <Hixie> (i don't really undertand how <audio> would make sense)
  42. # [0:24] <annevk> after thinking about it some more me neither
  43. # [0:24] <Dashiva> For playing music?
  44. # [0:24] <othermaciej> I think <audio> makes sense
  45. # [0:24] <annevk> how would it work?
  46. # [0:25] <Dashiva> Like embed, or bgsound if you want
  47. # [0:25] <Hixie> othermaciej: what does it represent?
  48. # [0:25] <annevk> if it's about the UI you just want a declarative interface to Audio() through buttons or something
  49. # [0:25] <othermaciej> it represents an embedded semantic/foreground sound, analogous to img and video
  50. # [0:25] <annevk> othermaciej, http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Markup_2 has element and attribute changes
  51. # [0:25] <Dashiva> Well, it frees you from depending on scripts
  52. # [0:25] <annevk> might not be up to date
  53. # [0:25] <othermaciej> this will be easier to discuss on Monday so I'll hold off for now
  54. # [0:26] <Hixie> crap gotta go ref the finals
  55. # [0:26] <Hixie> bbiab
  56. # [0:26] <Dashiva> annevk: I see it sort of like event-source
  57. # [0:27] <othermaciej> wow, "target" attribute is removed?
  58. # [0:27] <annevk> it was recently added again I think
  59. # [0:27] <annevk> i'll fix that
  60. # [0:28] <othermaciej> most of the obsolete attributes seem rightfully obsoleted, but many of the obsolete elements are in the "browsers will have to implement these anyway" category
  61. # [0:29] <met_> osolete Elements: acronym (use <abbr> instead) = reason for this?
  62. # [0:29] <annevk> those will prolly be in the rendering section for exactly that reason
  63. # [0:29] <annevk> met_, there's no real useful difference and authors are constantly confused as to which to use
  64. # [0:29] <othermaciej> met_: please see archives of the many debates on this
  65. # [0:29] <annevk> othermaciej, just like the parsing section handles all elements the rendering section will (hopefully anyway) too
  66. # [0:30] <othermaciej> annevk: maybe there should be some category of elements that conformant implementations must implement, but which can never appear in a conformant document and must be rejected by conformance checkers
  67. # [0:30] <othermaciej> like a stronger version of deprecation
  68. # [0:30] <othermaciej> I don't think relegating it to the conformance section makes sense, since in some cases the API may matter too
  69. # [0:30] <annevk> othermaciej, yes, that's what I said :)
  70. # [0:30] <met_> othermaciej, any way how to fullsearch mailing list other than google site:lists.whatwg.org ?
  71. # [0:30] <annevk> rendering section only applies to implementors
  72. # [0:30] <othermaciej> although I suppose defining the content model for an intrinsically nonconformant element is kinda pointless
  73. # [0:31] <annevk> yup
  74. # [0:31] <annevk> you just need parsing + rendering
  75. # [0:31] <othermaciej> annevk: maybe it shouldn't be called "rendering" if it might contain APIs and attribute definitions
  76. # [0:31] <othermaciej> you need parsing, rendering, how to interpret the attributes, etc
  77. # [0:31] <annevk> oh, dunno about APIs
  78. # [0:31] <othermaciej> met_: I dunno
  79. # [0:31] <annevk> for <body> and such you'd have to define a lot of additional stuff too then
  80. # [0:32] <annevk> (for instance)
  81. # [0:32] <annevk> link@target and form@target are still on the page as they're not defined yet
  82. # [0:33] <annevk> <font> is also in HTML5
  83. # [0:35] <annevk> fixed that too
  84. # [0:36] <met_> not sure about acronym dropping, but ok I can live without it 8-), but general question from this
  85. # [0:36] <met_> many people will ask "why you drop this", "why you add this" etc. etc. and there is no other answer than "see in mailing list archive".
  86. # [0:36] <met_> may be there is need from "something" faq, wiki answers, dunno, otherwise you will see "why you drop acronym" and other questions for hundred and hundred times
  87. # [0:36] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  88. # [0:37] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Remote closed the connection)
  89. # [0:37] <annevk> you are free to do so
  90. # [0:37] <annevk> encouraged even
  91. # [0:38] <met_> not sure if i am the right person, still do not orientate in spec enough
  92. # [0:38] <met_> btw full text mailing list search exists at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/
  93. # [0:39] * icaaq calls it in for the night. Kepp up the good work :)
  94. # [0:40] * icaaq is now known as icaaq_sleeps
  95. # [0:42] * hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Read error: 110 (Connection timed out))
  96. # [0:42] * annevk uses "g <string> inurl:whatwg-whatwg" for searching mostly
  97. # [0:46] * annevk -> bed
  98. # [0:54] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  99. # [1:01] * met_ (n=Hassman@r5bx220.net.upc.cz) Quit ("Chemists never die, they just stop reacting.")
  100. # [1:01] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has left #whatwg
  101. # [1:04] <Hixie> othermaciej: yeah don't worry in due course we'll be defining all the various elements that browsers have to support
  102. # [1:04] <Hixie> othermaciej: but they won't be "HTML5"
  103. # [1:04] <Hixie> othermaciej: (the parsing section already does this -- it defines parsing for dozens of obsolete elements)
  104. # [1:06] <Hixie> othermaciej: i guess <audio> could make sense if it implies ui controls (unlike <video> which doesn't in v1, though probably would in v2)
  105. # [1:18] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  106. # [1:23] * h3h (n=w3rd@cpe-70-95-234-202.san.res.rr.com) has joined #whatwg
  107. # [1:24] <sayrer> I don't understand the objections to <audio>
  108. # [1:31] <Lachy> The audio and video APIs should be made the same, except for the width/height
  109. # [1:33] <Lachy> I haven't made up my mind about <audio> yet. In some ways, Audio() provides all the necessary features for using Audio with script, but <audio> provides a declerative way to embed audio, potentially with a UA supplied UI that also provides the API
  110. # [1:34] <sayrer> also volume controls and other things that hover over the content area probably need to work differently for vide
  111. # [1:34] <Lachy> I know <embed> and <object> already provide a way to embed audio with a plugin-supplied-UI, but that audio doesn't have any API
  112. # [1:37] <Lachy> oh, it would be cool if the API could provide access to the ID3 tag info (or equivalent) in audio and video files
  113. # [1:39] <sayrer> yeah. it would be good not specify it idl
  114. # [1:39] <sayrer> so it can be a dictionary (JS Object)
  115. # [1:39] <Lachy> sayrer, what?
  116. # [1:40] <Lachy> care to rephrase that?
  117. # [1:40] <sayrer> Lachy: I don't think we want an AudioMetadataInterface
  118. # [1:40] <Lachy> why not?
  119. # [1:41] <sayrer> because it will be easier to do it adhoc
  120. # [1:41] <sayrer> see what keys people use
  121. # [1:42] <sayrer> there is already a big list in id3, right?
  122. # [1:42] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Remote closed the connection)
  123. # [1:43] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  124. # [1:43] * Lachy is looking up the list of ID3 tags
  125. # [1:50] <Lachy> couldn't a metadata API be as simple as getValue(key);? Then there are no limits on what keys can be accessed
  126. # [1:51] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) Quit (Remote closed the connection)
  127. # [1:51] <Lachy> we definitely don't want getArtistName() getAlbumName(), etc. cause that's not very extensible
  128. # [1:51] * tantek (n=tantek@66.194.95.2) has joined #whatwg
  129. # [1:51] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  130. # [1:54] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has left #whatwg
  131. # [1:56] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has joined #whatwg
  132. # [2:00] * hendry (n=hendry@91.84.53.136) Quit ("nn")
  133. # [2:01] <sayrer> Lachy: I agree. might be better to specify them as JSON and let implementations bind them per-language
  134. # [2:06] * tantek (n=tantek@66.194.95.2) Quit ()
  135. # [2:28] <Lachy> sayrer, do you mean to expose the data in JSON format like {"Artist":"Someone", "Album":"Something", ... } ?
  136. # [2:28] <sayrer> Lachy, I mean define it in JSON, and say the actual API is per-language
  137. # [2:29] <Lachy> define what in JSON?
  138. # [2:29] <sayrer> so in JS and Python, say, it is just a your normal object
  139. # [2:29] <Lachy> the API?
  140. # [2:29] <sayrer> say it is a JSON dictionary and give a couple super obvious keys
  141. # [2:29] <sayrer> in Java, it could be a hashtable
  142. # [2:30] <Lachy> but what exactly does "it" refer to?
  143. # [2:30] <sayrer> "the metadata"
  144. # [2:30] <Lachy> I'm so confused
  145. # [2:30] <sayrer> so, you had it right in your example
  146. # [2:31] <Lachy> oh, ok. I thought I had it wrong because of what you said afterwards
  147. # [2:31] <sayrer> in JS it would be
  148. # [2:31] <sayrer> >> audio.metadata.Artist
  149. # [2:31] <sayrer> "Someone"
  150. # [2:31] <sayrer> in Java, it would be uglier
  151. # [2:47] * moeffju is now known as moeffju[ZzZz]
  152. # [3:06] <Lachy> Hixie, yt?
  153. # [3:07] <Lachy> the stop() method appears to be missing from the HTMLVideoElement IDL
  154. # [3:09] <othermaciej> Lachy: a metadata API can't be that simple
  155. # [3:10] <Dashiva> I just got 28 mailing list messages for all of today in one huge chunk...
  156. # [3:13] * bewest (n=ben@httpcraft/bewest) has joined #whatwg
  157. # [3:14] * sayrer (n=chatzill@user-10876hc.cable.mindspring.com) Quit ("Chatzilla 0.9.73-rdmsoft [XULRunner 1.8.0.4/2006050908]")
  158. # [3:15] <hasather_> Dashiva: digest?
  159. # [3:27] * weinig is now known as weinig|zZz
  160. # [3:28] * webben (n=benjamin@91.84.131.217) Quit ("Leaving")
  161. # [3:28] <Dashiva> No, regular mail. Must've been a choke somewhere along the way to me
  162. # [3:59] * mpt (n=mpt@121-72-132-150.dsl.telstraclear.net) has joined #whatwg
  163. # [4:11] <Hixie> ok i am now here
  164. # [4:31] * tantek (n=tantek@66.194.95.2) has joined #whatwg
  165. # [4:45] <Lachy> Hixie, I've been thinking about whether or not we need an audio element and there are a couple of advantages to having it
  166. # [4:46] <Lachy> it would make the audio available to users without script
  167. # [4:47] <Lachy> <audio ui="on"> could provide a UI, similar to what we get with object/embed today
  168. # [4:50] <Hixie> yeah but we'd still have to have the API to do sound effects
  169. # [4:50] <Hixie> so it's yet another feature
  170. # [4:50] <Lachy> adding support for visulatisations could be done in the future as well, if there were a screen provided for it
  171. # [4:54] <Lachy> well, there are some use cases for it too. Providing music previews on a music site like this, which currently uses flash: http://magnatune.com/artists/albums/bradsucks-dontknow/hifi_play
  172. # [4:55] <Hixie> that would use the Audio API, not the element, since it makes its own UI and everything
  173. # [4:56] <Lachy> possibly, but the API would need to be enhanced. The spec also says Audio() is desiged for sound effects, not streaming music like that does
  174. # [4:56] <Hixie> yeah
  175. # [4:56] <Hixie> well it certainly is at the moment
  176. # [4:58] <Lachy> but even if it were enhanced, users without script (like many mobile phone) would have no alternative
  177. # [5:02] <Dashiva> streaming is a very good use case
  178. # [5:05] <Lachy> is there an open format that supports streaming for live broadcasts, or only proprietary formats like those used in Real Player and Windows Media Player?
  179. # [5:05] * hasather_ (n=hasather@81-235-209-174-no62.tbcn.telia.com) has left #whatwg
  180. # [5:06] <Dashiva> The format used in shoutcast, maybe? Not sure
  181. # [5:11] * tantek (n=tantek@66.194.95.2) Quit ()
  182. # [5:15] <Hixie> Lachy: i haven't added them yet but all the events on <video> can be event listener attributes, and Audio is an EventTarget too
  183. # [5:16] <Lachy> I thought they would be
  184. # [9:04] * csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) Quit ()
  185. # [9:21] * annevk2 (n=annevk@86.90.70.28) has joined #whatwg
  186. # [9:29] * annevk (n=annevk@86.90.70.28) Quit (Read error: 110 (Connection timed out))
  187. # [9:50] * icaaq_sleeps is now known as icaaq
  188. # [11:02] * annevk2 is now known as annevk
  189. # [11:08] * ROBOd (n=robod@86.34.246.154) has joined #whatwg
  190. # [11:19] * hendry (n=hendry@91.84.53.136) has joined #whatwg
  191. # [11:26] * annevk (n=annevk@86.90.70.28) Quit (Read error: 110 (Connection timed out))

The end :)