/irc-logs / w3c / #html-wg / 2007-09-02 / end

Options:

  1. # Session Start: Sun Sep 02 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:13] * Joins: robburns (robburns@68.78.101.66)
  4. # [00:54] * Quits: robburns (robburns@68.78.101.66) (Quit: robburns)
  5. # [00:58] * Quits: Lachy (chatzilla@124.170.30.206) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
  6. # [00:58] * Joins: Lachy (chatzilla@124.170.30.206)
  7. # [01:05] * Joins: robburns (robburns@71.57.41.70)
  8. # [01:06] * Joins: gsnedders (gsnedders@86.142.195.139)
  9. # [01:10] * Quits: tH (Rob@87.102.114.49) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  10. # [01:20] * Quits: gsnedders (gsnedders@86.142.195.139) (Quit: gsnedders)
  11. # [01:25] * Quits: zcorpan_ (zcorpan@85.227.145.211) (Ping timeout)
  12. # [01:29] * Joins: heycam (cam@221.187.46.123)
  13. # [01:31] * Joins: xover (xover@193.157.66.5)
  14. # [01:32] * Quits: xover (xover@193.157.66.5) (Quit: Leaving)
  15. # [01:44] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
  16. # [01:47] * Quits: laplink (link@193.157.66.70) (Ping timeout)
  17. # [01:51] * Joins: robburns (robburns@71.57.41.70)
  18. # [01:51] * Joins: laplink (link@193.157.66.70)
  19. # [01:53] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
  20. # [02:09] * Joins: jonbarnett (barnett@74.194.19.8)
  21. # [02:10] * Joins: robburns (robburns@71.57.41.70)
  22. # [02:27] * Joins: Sander (svl@86.87.68.167)
  23. # [02:28] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
  24. # [02:29] * Joins: robburns (robburns@71.57.41.70)
  25. # [02:31] * Joins: gsnedders (gsnedders@86.142.195.139)
  26. # [02:37] * Quits: laplink (link@193.157.66.70) (Ping timeout)
  27. # [02:37] * Joins: laplink (link@193.157.66.70)
  28. # [02:45] * Quits: Lachy (chatzilla@124.170.30.206) (Ping timeout)
  29. # [02:46] * Joins: Lachy (chatzilla@124.170.133.193)
  30. # [02:48] * Quits: gsnedders (gsnedders@86.142.195.139) (Quit: gsnedders)
  31. # [02:57] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
  32. # [03:09] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  33. # [03:24] * Joins: robburns (robburns@98.193.22.194)
  34. # [03:28] * Quits: hasather (hasather@90.227.221.48) (Quit: leaving)
  35. # [03:45] * Quits: robburns (robburns@98.193.22.194) (Connection reset by peer)
  36. # [03:45] * Joins: robburns (robburns@98.193.22.194)
  37. # [04:32] * Quits: heycam (cam@221.187.46.123) (Ping timeout)
  38. # [04:47] * Joins: heycam (cam@221.187.46.123)
  39. # [05:18] * Quits: heycam (cam@221.187.46.123) (Quit: bye)
  40. # [06:03] * Quits: jgraham (jgraham@81.86.209.27) (Ping timeout)
  41. # [06:12] * Joins: schepers (schepers@128.30.52.30)
  42. # [06:17] * Joins: jgraham (jgraham@81.86.222.151)
  43. # [06:31] * Joins: heycam (cam@221.187.46.123)
  44. # [06:45] * Joins: gavin_ (gavin@74.103.208.221)
  45. # [06:46] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
  46. # [06:52] * Joins: robburns (robburns@98.193.22.194)
  47. # [08:02] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
  48. # [08:30] * Quits: schepers (schepers@128.30.52.30) (Client exited)
  49. # [08:32] * Joins: schepers (schepers@128.30.52.30)
  50. # [09:35] * Joins: hasather (hasather@90.227.221.48)
  51. # [09:59] * Joins: tH_ (Rob@87.102.114.49)
  52. # [09:59] * tH_ is now known as tH
  53. # [10:13] * Joins: ROBOd (robod@86.34.246.154)
  54. # [10:25] * Quits: schepers (schepers@128.30.52.30) (Quit: Trillian (http://www.ceruleanstudios.com)
  55. # [11:16] * Quits: heycam (cam@221.187.46.123) (Quit: bye)
  56. # [11:38] * Joins: hendry (hendry@89.16.172.32)
  57. # [11:59] * Joins: gsnedders_ (gsnedders@86.142.195.139)
  58. # [12:11] * Quits: laplink (link@193.157.66.70) (Ping timeout)
  59. # [12:26] * Joins: bitcrumb (Lode@87.64.65.44)
  60. # [12:29] * Quits: bitcrumb (Lode@87.64.65.44) (Quit: bitcrumb)
  61. # [12:32] * Joins: laplink (link@193.157.66.70)
  62. # [12:34] * Joins: zcorpan_ (zcorpan@85.227.145.211)
  63. # [14:28] * Joins: edas (edaspet@77.194.106.57)
  64. # [14:34] * Joins: Sander (svl@86.87.68.167)
  65. # [15:34] * Joins: myakura (myakura@122.16.115.215)
  66. # [16:37] * Joins: gsnedders (gsnedders@217.42.133.228)
  67. # [16:38] * Quits: gsnedders_ (gsnedders@86.142.195.139) (Ping timeout)
  68. # [16:39] * Quits: deltab (deltab@82.36.30.34) (Connection reset by peer)
  69. # [16:40] * Quits: edas (edaspet@77.194.106.57) (Quit: Quitte)
  70. # [16:48] * Joins: schepers (schepers@128.30.52.30)
  71. # [16:49] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  72. # [16:50] * Joins: robburns (robburns@98.193.22.194)
  73. # [16:57] * Quits: myakura (myakura@122.16.115.215) (Quit: Leaving...)
  74. # [16:58] * Quits: hasather (hasather@90.227.221.48) (Quit: leaving)
  75. # [17:32] * Quits: schepers (schepers@128.30.52.30) (Quit: Trillian (http://www.ceruleanstudios.com)
  76. # [18:02] <Philip`> robburns: "... since HTML5 proposes to add document.write to the XML serialization of HTML ..." - I believe it intentionally doesn't propose that, since it would be incompatible with XML parsers
  77. # [18:04] <zcorpan_> "In an XML context, the document.write(s) method must raise an INVALID_ACCESS_ERR exception."
  78. # [18:06] <robburns> Hi
  79. # [18:06] <robburns> Philip: how is document.write incompatible with XML parsers?
  80. # [18:07] <robburns> other than it hasn't been defined in a specification?
  81. # [18:09] <zcorpan_> robburns: if you allow arbitrary markup to be inserted to the input stream (what document.write does in html) then the xml parser can't tell if the document was well-formed or not
  82. # [18:10] <zcorpan_> robburns: it's also unclear what should happen when the script element is the root element
  83. # [18:10] * Joins: edas (edaspet@84.98.141.225)
  84. # [18:10] * Joins: xover (xover@193.157.66.5)
  85. # [18:11] <robburns> zcorpan: I agree with what you say, but why not simply require the string be a well formed document fragment and then clarify what should happen if the element is the root element.
  86. # [18:12] <Philip`> I expect it would have to be defined in an entirely rewritten specification that looks much more like the HTML parser specification - it can't just be fitted on top of the existing XML spec, which is a pain
  87. # [18:12] <Philip`> (and web browsers couldn't use standard XML parsers any more)
  88. # [18:13] <Philip`> (though I have no idea if that's actually wrong and the XML parsers let you fiddle with the input stream in mid-parse with no problems)
  89. # [18:13] <zcorpan_> robburns: iirc the reason why Hixie didn't spec how it should work was because there were lots of other edge cases
  90. # [18:14] <robburns> Philip: Why would it be fitting it on top of an XML spec more than anything else related to the XMl serialization of HTML? Also why would browsers be unable to use standard XML parsers?
  91. # [18:15] <zcorpan_> robburns: you need to halt the parser in order to wait for document.write() to execute, and you might not have that control over the parser using an off-the-shelf parser
  92. # [18:16] <robburns> zcorpan_: so the off the shelf parsers would need to be updated?
  93. # [18:16] <robburns> looking at the June 14th HTML5 draft , it has a document.write for XML:
  94. # [18:16] <robburns> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.78#controlling
  95. # [18:17] <robburns> correction: June 7th draft
  96. # [18:17] <zcorpan_> robburns: you would need to fork them
  97. # [18:17] <Philip`> robburns: http://www.whatwg.org/specs/web-apps/current-work/#document.write1
  98. # [18:18] * Quits: edas (edaspet@84.98.141.225) (Quit: Quitte)
  99. # [18:18] <robburns> I understand there might be issues to resolve, but they do not look like insurmountable issues to me.
  100. # [18:19] <Philip`> What would the benefit be?
  101. # [18:19] <Philip`> It wouldn't help with porting HTML documents to XHTML, since you'd have to rewrite all your document.writes to generate well-formed XML fragments
  102. # [18:20] <Philip`> and if you're rewriting it all, you can rewrite it to use DOM methods instead
  103. # [18:20] <zcorpan_> or innerHTML
  104. # [18:21] <robburns> Philip: I think the benefit is that it would be a properly abstracted API, rather than a lumped together set of methods
  105. # [18:22] <robburns> Philip: The problem is that we have an in-memory HTML that should be properly abstracted from the serialization or other paths that got it to where it is.
  106. # [18:22] <robburns> To me that means that we have methods that can return either serialization and also methods that can accept either serialization. If that requires improvements in standard XML parsers well those improvements may yield other benefits as well.
  107. # [18:23] <robburns> innerHTML has some issues to deal with too.
  108. # [18:23] * Joins: edas (edaspet@77.194.100.53)
  109. # [18:23] <zcorpan_> innerHTML in xml is already defined and implemented
  110. # [18:23] <zcorpan_> innerHTML is less problematic
  111. # [18:24] <robburns> zcorpan_: I don't believe WebKit supports it. What browsers support innerHTML in XML de-serialized documents.
  112. # [18:24] <robburns> ?
  113. # [18:26] <Philip`> document.write isn't serialisation-independent at all - its purpose is to modify the serialised form of the document, so it doesn't make sense to use it with two different serialisations at once
  114. # [18:26] <zcorpan_> robburns: webkit supports it, firefox, opera
  115. # [18:26] <zcorpan_> dunno when it was added to webkit, but for firefox it was version 1.5 and opera version 8
  116. # [18:26] * Quits: gsnedders (gsnedders@217.42.133.228) (Quit: Don't touch /dev/null…)
  117. # [18:27] <robburns> zcorpan_: So how does it work? Is the string an XML well-formed string? Does setInnerHTML also work with an XML string?
  118. # [18:28] <zcorpan_> robburns: it's defined in the html5 spec :)
  119. # [18:28] * Joins: Lachy_ (chatzilla@124.170.105.252)
  120. # [18:29] <robburns> zcorpan_: Yeah, I'm waiting for the draft to load now :-)
  121. # [18:29] * Quits: Lachy (chatzilla@124.170.133.193) (Ping timeout)
  122. # [18:29] * Lachy_ is now known as Lachy
  123. # [18:31] <robburns> zcorpan_: I took a look at it and its just what I recall. However, I still think we should have DOM APIs that are more serialization agnostic and aware at the same time. When working with the DOM we should have methods for getting either serialization and for setting from either serialization (whatever name those methods have).
  124. # [18:32] <robburns> perhaps that means deprecating these other methods. We should take a systematic look at it.
  125. # [18:33] <zcorpan_> you can use dom core methods
  126. # [18:33] <zcorpan_> i don't see the benefit of deprecating these
  127. # [18:33] <zcorpan_> even if they're serialization specific
  128. # [18:34] <robburns> zcorpan_: I don't see the benefit of deprecating them either. However, after a systematic look at it, it might be worth it after all.
  129. # [18:34] <robburns> zcorpan_: I don't see the benefit of treating them as sacred either.
  130. # [18:35] <zcorpan_> robburns: document.write() and innerHTML in html has to work the way they do now for compat
  131. # [18:36] <robburns> zcorpan_: I understand that. Which is why they might end up deprecated after a systematic look at what methods authors actually need to manipulate documents
  132. # [18:40] <robburns> zcorpan_: It's just a normal process of development. As things change around HTML and XML its important to reassess the APIs to make sure they serve the needs of authors as these new concepts develop. Take document.createElement for example. At one time it made sense to put that method on the document interface. However, with namespaces and compound documents, it probably makes more sense to have createElement on the element interface instead.
  133. # [18:42] <zcorpan_> robburns: why would you want createElement on the Element interface? what would it do differently from the one on the Document interface?
  134. # [18:47] <robburns> zcorpan_ It would be useful on the element interface since the author may be interested in creating an element in the namespace of the root element in the scope or on the default namespace for the current scope.. The document cannot be aware of that current scope. The document.createElement can return an element in the null namespace or it could return an element based on the documentElement namespace.
  135. # [18:47] * Joins: gsnedders (gsnedders@217.42.133.228)
  136. # [18:47] <robburns> It could also return an element in a certain namespace based on media type and other criterion.
  137. # [18:48] <robburns> However, the ability to create an element with element.createElement that is created in the default namespace for the scope or the root namespace for the scope is a useful method for authors.
  138. # [18:49] <zcorpan_> why not use document.createElementNS in such cases?
  139. # [18:51] <robburns> zcorpan_: well that could be done, but it would require a list of prefaced methods to determine the namespace of the current scope or the current scopes root element namespace. I think createElement should be understood as a convenience method in the future (which is what its already evolving into).
  140. # [18:52] <robburns> the problem is that it doesn't have a clearly defined specification to keep it interoperable as new concept such as namespaces and compound documents have evolved.
  141. # [18:54] <Lachy> defining document.write() for use in HTML is difficult enough, defining it for XML would be simply impossible. See http://ln.hixie.ch/?start=1155195074&count=1 and http://ln.hixie.ch/?start=1091626816&count=1
  142. # [18:55] <Lachy> besides, document.write() is generally considered bad practice anyway.
  143. # [18:58] <robburns> Lachy: I'm not sure I consider document.write() bad practice, but if it is, then why not deprecate it in our draft for HTML documents as well. Why make no mention of it being bad practice?
  144. # [19:00] <robburns> Lachy: how different is documentWrite from setInnerHTML? If one is bad practice then why wouldn't the other be bad practice? Aren't they both meant to turn a string into a valid and well-formed document fragment, inserted into the document?
  145. # [19:01] <zcorpan_> robburns: innerHTML doesn't modify the input stream while the document is parsing. it modifies the dom directly just like dom core methods do
  146. # [19:01] <Lachy> document.write messes directly with the input stream during parsing. innerHTML creates a document fragment and inserts into the DOM
  147. # [19:03] <robburns> I see. What does document.write do once the document has been fully parsed. Does it cause a re-parse?
  148. # [19:03] <zcorpan_> robburns: it blows the document away, iirc
  149. # [19:04] <robburns> zcorpan_ What's the benefit to document.write over setInnerHTML?
  150. # [19:04] <zcorpan_> robburns: you can use innerHTML after the document has been loaded without blowing it away
  151. # [19:04] <zcorpan_> er
  152. # [19:05] <zcorpan_> sorry got the question backwards
  153. # [19:05] <robburns> Or a related question, what existing content would be broken if document.write just mapped to setInnerHTML (especially for an XML document)?
  154. # [19:05] <zcorpan_> you don't need to find a specific element to use document.write
  155. # [19:06] <Lachy> besides, how would you handle a case like this in XML? <script><![CDATA[ d.write('<p>'); d.write(myVar); d.write('<\/p>') ]]></script> - The end result is well formed, but the fragment in each call is not
  156. # [19:07] <robburns> Lachy: so document.write allows ill-formed strings and innerHTML does not. Is that right?
  157. # [19:07] <zcorpan_> robburns: e.g. ads usually use document.write because they don't know where the scripts will be included, but instead just add a string of markup to the input stream that works anywhere you put it
  158. # [19:08] <Lachy> innerHTML requires well formed strings when used in XML, not in HTML.
  159. # [19:08] <Lachy> d.write() doesn't require well formed strings (though it can't even be used in XML, so I don't really understand your question)
  160. # [19:10] <zcorpan_> robburns: in html, neither have any restrictions on what the string is, but innerHTML is parsed in isolation while document.write just modifies the input stream so is parsed as if it was in the document in the first place
  161. # [19:10] <robburns> Lachy: the discussion was about whether it could be made to in some way. Though if the big benefit of document.write is to be able to insert ill-formed strings into a document than I don't know if it would be worth the trouble. However, then my earlier question of why we don't make it clear that document.write is bad practice and show authors ways of accomplishing the same thing with innerHTML.
  162. # [19:12] <Lachy> but to use it in XML, it would require well formed strings. But to enforce that requirement, you'd effectively need to parse the string twice: once to ensure it was a well formed fragment *before* inserting the string into the stream, and then (if it is well formed) again as it got parsed into the stream.
  163. # [19:13] <Lachy> that would require invoking a separate instance of the parser to do the check and would likely be a huge performance hit
  164. # [19:14] <robburns> Lachy: if the document was well-formed without the document.write and the document.write string is also well-formed won't the result be well-formed? I guess authors may want to create ill-formed content that gets made well-formed by a scripts?
  165. # [19:14] <Lachy> what?
  166. # [19:15] <Lachy> what you just said doesn't make sense
  167. # [19:15] <robburns> Lachy: I'm asking why it needs to be checked for well-formedness twice. If the an XML document fragment is well-formed than inserting it into a well-formed document will also result in a wellformed document.
  168. # [19:15] <zcorpan_> robburns: not necessarily. e.g. you can only have one root element
  169. # [19:16] <Lachy> robburns, how does the scripting engine *know* that the string is well formed without checking it?
  170. # [19:17] <robburns> zcorpan_: right, but that means you can insert any elements before or after the root element regardless of what the string is.
  171. # [19:17] <robburns> Lachy: it checks it, it just doesn't need to check it twice, which is what i thought you were saying.
  172. # [19:18] <Lachy> the scripting engine would need to check it before passing it back to the input stream, where it would naturally get parsed again
  173. # [19:18] <robburns> On the other benefit of document.write: I've never needed to do this, but is there any way to use setInnerHTML in a script like document.write might be used and insert the result before or after the current script (without using an ID, but actually through introspection relative to where the script is located?).
  174. # [19:19] * Quits: edas (edaspet@77.194.100.53) (Quit: Quitte)
  175. # [19:20] <zcorpan_> while the document is being parsed?
  176. # [19:21] <Lachy> robburns, how would you handle the cases where the script element *is* the root element?
  177. # [19:25] <robburns> I guess than then the processor would need to check that particular situation and make sure that any document fragment was a single element and that the script element would be replaced by the document fragment's single root element. It still seems like a situation where the processor can branch for this contingency and doesn't seem to me to require another re-parse.
  178. # [19:25] <Lachy> robburns, try this in Opera (doesn't work in Firefox)...
  179. # [19:25] <Lachy> http://html5.lachy.id.au/output?type=application%2Fxhtml%2Bxml&data=%3Cscript+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%3E%0D%0Aalert%28%22View+Source%21%22%29%3B%0D%0A%2F%2Fdocument.write%28%22You+can%27t+do+this%21%22%29%3B%0D%0A%3C%2Fscript%3E%0D%0A
  180. # [19:25] <robburns> zcorpan_: not necessarily why the document is being parsed, just after building the DOM would accomplish the same thing with innerHTML
  181. # [19:26] <zcorpan_> robburns: i don't follow
  182. # [19:28] <Lachy> robburns, no, you can do that
  183. # [19:28] <Lachy> s/can/can't/
  184. # [19:28] <robburns> zcorpan_: I guess what I'm asking is just is there any method for a script to discover through introspection where it is running from in the document? So if a script is either linked or embedded as the first element of the body element (for example) that it could discover that fact without setting an ID.
  185. # [19:28] <robburns> ?
  186. # [19:29] <robburns> Lachy: OK
  187. # [19:29] <robburns> So that is a benefit in document.write (or a deficiency in the SCRIPT element). Not that setting an ID is a major burden, but it does come with possible name collision problems.
  188. # [19:30] <zcorpan_> robburns: not really. you can however know how much of the document has been parsed at the time the script is running, which in most cases might be exactly to the current script element, by using getElementsByTagName("*")
  189. # [19:30] <zcorpan_> the last element in that nodelist would then be the script element
  190. # [19:32] <robburns> zcorpan_: that's clever, but I wonder if that's really robust in the long run (like if UAs become more threaded .)
  191. # [19:32] <zcorpan_> it's not robust at all
  192. # [19:32] <Lachy> robburns, it's not entirely clear why one would want to do that anyway
  193. # [19:36] <robburns> Lachy: that seems to me the only benefit of document.write. In other words you can insert it into a document and it will add its string in the current script location. Using setInnerHTML could accomplish the same thing if the script could introspect to find out where its parent script element is located.
  194. # [19:38] <robburns> Lachy: on your example
  195. # [19:38] <robburns> http://html5.lachy.id.au/output?type=application%2Fxhtml%2Bxml&data=%3Cscript+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%3E%0D%0Aalert%28%22View+Source%21%22%29%3B%0D%0A%2F%2Fdocument.write%28%22You+can%27t+do+this%21%22%29%3B%0D%0A%3C%2Fscript%3E%0D%0A
  196. # [19:38] <robburns> I worked in Opera and Safari 3 the same. I wasn't sure what I was supposed to get from it though.
  197. # [19:39] <Lachy> if the document.write() line was uncommented, how would you expect it to work? (I left it commented because it would only cause scripting errors)
  198. # [19:44] * Joins: hasather (hasather@90.227.221.48)
  199. # [19:50] <robburns> Lachy: but would it work in a text/html processed document? Are you saying that it would be a valid text/html document because of the implied html, head and body? However, document.write could be designed to repair the document in the same way the HTML parser repairs the document. It could insert the needed ancestor elements to create a well-fomred (and possibly valid) document.
  200. # [19:51] <robburns> then pass that on to setInnerHTML
  201. # [19:52] <Lachy> it wouldn't quite be a valid document, since it's missing some required elements, but it would certainly work in text/html since it's parsing requirements are a lot more lenient.
  202. # [19:53] <Lachy> robburns, see http://html5.lachy.id.au/output?type=text%2Fhtml%3B+charset%3DUTF-8&data=%3Cscript%3Edocument.write%28%22document.write%28%29+works+in+text%2Fhtml%21%22%29%3B%3C%2Fscript%3E
  203. # [19:54] <Lachy> btw, you can make your own tests by going to http://html5.lachy.id.au/output
  204. # [19:54] <zcorpan_> or use data: uris :)
  205. # [19:54] <zcorpan_> http://software.hixie.ch/utilities/cgi/data/data
  206. # [19:56] <robburns> What's the difference between those two (Hixie's and Lachy's)? Lachy, is yours not generating data URIs?
  207. # [19:58] <Lachy> no, a data URI looks like this: data:text/plain,Hello!
  208. # [19:59] <Lachy> or this data:text/html;charset=utf-8,%3Ctitle%3Etest%3C%2Ftitle%3E%3Cp%3EHi!
  209. # [20:00] <Lachy> data URIs don't have a server involved, mine echos back from the server whatever content you post to it
  210. # [20:02] <Lachy> zcorpan_, I added support for an edit parameter, which gives you the code in the text box instead of as a file. e.g. http://html5.lachy.id.au/output?type=text%2Fhtml%3B+charset%3DUTF-8&data=Testing&edit
  211. # [20:05] <Philip`> Lachy: http://html5.lachy.id.au/output?type=text%2Fhtml&data=%0D%0ASecond+line&edit
  212. # [20:06] <robburns> I see. Those are some nice resource. I'll keep them in mind.
  213. # [20:06] <Lachy> that's due to the way HTML parses <textarea> it's appearing in the source
  214. # [20:07] <Lachy> hmm. I should probably check this thing in google code too
  215. # [20:08] <zcorpan_> Lachy: then have a LF at the start of the textarea by default? :)
  216. # [20:08] <Lachy> that would be too easy :-)
  217. # [20:09] <Philip`> It'd look nicer if the text box and text area were on separate lines
  218. # [20:09] <Lachy> zcorpan_, fixed
  219. # [20:09] <Lachy> Philip`, what do you mean?
  220. # [20:10] <Philip`> The Content-Type box is in the middle-left of my screen, and the big textarea is in the upper-right corner
  221. # [20:11] <Philip`> but it'd be better with the Content-Type box at the top-left corner, and the textarea in the middlish-left
  222. # [20:11] <Philip`> (It looks alright if I zoom in so the two boxes get text-wrapped)
  223. # [20:12] <Lachy> what the? the textarea is inside its own <p>
  224. # [20:12] <Lachy> why is it doing that for you?
  225. # [20:13] <Philip`> It's not in its own <p> in Opera
  226. # [20:13] <Philip`> (9.2)
  227. # [20:14] <Philip`> It works if you put a </option> in the last datalist item
  228. # [20:15] <Philip`> but otherwise it ignores all the tags up until the <textarea> and parses the non-tag stuff as text inside the option element
  229. # [20:15] <Lachy> ok, must be a bug in Opera
  230. # [20:16] <Philip`> Or a bug in HTML5's graceful degradation of <datalist>
  231. # [20:16] <Lachy> well, maybe. it depends if that bug was introduced before or after Opera implemented datalists.
  232. # [20:17] <Lachy> I added a <select> inside the datalist now, so that other browsers have the menu available for convenience
  233. # [20:21] <Philip`> Oh, <datalist> is implemented? It doesn't work at all in that example...
  234. # [20:21] * Joins: edas (edaspet@86.69.209.223)
  235. # [20:21] <Philip`> Oh, yes it does
  236. # [20:21] <Philip`> but it's non-obvious since it doesn't do anything until I start typing in the box
  237. # [20:21] <zcorpan_> </option> is a known bug in oprea
  238. # [20:23] <Lachy> Philip`, Opera's UI problems with datalist is another bug that needs to be fixed
  239. # [20:31] <Philip`> Bah, Opera has too many bugs :-p
  240. # [20:46] * Joins: Julian (chatzilla@80.143.140.180)
  241. # [20:50] <Dashiva> Philip`: We could simply remove all the features, would that make you happy? :P
  242. # [20:58] * Quits: edas (edaspet@86.69.209.223) (Quit: Quitte)
  243. # [21:11] * Quits: robburns (robburns@98.193.22.194) (Ping timeout)
  244. # [21:57] * Joins: deltab (deltab@82.36.30.34)
  245. # [22:12] * Quits: Julian (chatzilla@80.143.140.180) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
  246. # [22:29] * Joins: edas (edaspet@84.98.147.47)
  247. # [22:41] * Quits: edas (edaspet@84.98.147.47) (Quit: Quitte)
  248. # [22:48] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  249. # [22:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  250. # [23:00] * Quits: zcorpan_ (zcorpan@85.227.145.211) (Ping timeout)
  251. # [23:08] * Quits: hendry (hendry@89.16.172.32) (Quit: sleep)
  252. # [23:12] <gsnedders> Dashiva: why not take away the entire parser? won't that help? :P
  253. # [23:12] <Dashiva> gsnedders: Well, if you consider the parser a feature it would already be gone, and it you don't consider it a feature removing it would be an improvement :P
  254. # Session Close: Mon Sep 03 00:00:00 2007

The end :)