/irc-logs / w3c / #html-wg / 2008-06-27 / end

Options:

  1. # Session Start: Fri Jun 27 00:00:00 2008
  2. # Session Ident: #html-wg
  3. # [00:04] * Quits: ChrisWilson (cwilso@131.107.0.105) (Ping timeout)
  4. # [00:08] * Joins: ChrisWilson (cwilso@131.107.0.105)
  5. # [00:10] * Quits: Lionheart (robin@66.57.69.65) (Quit: Leaving.)
  6. # [00:20] * Joins: Zeros (Zeros-Elip@129.2.175.74)
  7. # [00:22] * Quits: ChrisWilson (cwilso@131.107.0.105) (Ping timeout)
  8. # [00:22] * Quits: heycam (cam@124.168.70.30) (Quit: bye)
  9. # [00:28] * Joins: ChrisWilson (cwilso@131.107.0.74)
  10. # [00:30] * Quits: matt (matt@128.30.52.30) (Quit: Terminated with extreme prejudice - dircproxy 1.0.5)
  11. # [00:44] * Quits: aaronlev (chatzilla@85.176.255.90) (Ping timeout)
  12. # [01:01] * Quits: smedero (smedero@192.223.6.251) (Quit: smedero)
  13. # [01:41] * Joins: scotfl (scotfl@70.64.14.62)
  14. # [01:51] * Quits: mjs (mjs@17.203.15.160) (Ping timeout)
  15. # [02:03] * Quits: tH (Rob@87.102.5.204) (Quit: ChatZilla 0.9.83-rdmsoft [XULRunner 1.8.0.9/2006120508])
  16. # [02:11] * Quits: aroben (aroben@71.58.56.76) (Connection reset by peer)
  17. # [02:55] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  18. # [02:56] * Joins: Lachy (Lachlan@85.196.122.246)
  19. # [03:03] * Quits: Zeros (Zeros-Elip@129.2.175.74) (Quit: This computer has gone to sleep)
  20. # [03:11] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  21. # [03:11] * Joins: Lachy (Lachlan@85.196.122.246)
  22. # [03:13] * Quits: ChrisWilson (cwilso@131.107.0.74) (Ping timeout)
  23. # [03:19] * Quits: billmason (billmason@69.30.57.192) (Quit: .)
  24. # [03:53] * Joins: heycam (cam@130.194.72.84)
  25. # [04:15] * Quits: adele (adele@17.203.14.204) (Ping timeout)
  26. # [05:33] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  27. # [06:09] * Joins: mjs (mjs@24.5.43.151)
  28. # [06:12] * Joins: adele (adele@24.7.125.179)
  29. # [06:12] * Quits: adele (adele@24.7.125.179) (Quit: adele)
  30. # [06:21] <marcos_away> Does anyone know where I can read up on the problems with <object> ?
  31. # [06:22] <Hixie> search for "object" among resolved bugs in mozilla's bug system :-)
  32. # [06:23] <marcos_away> k, thanks Hixie
  33. # [06:26] <marcos_away> I want to propose something similar for Widgets 1.0, but try to avoid some the complexities. For widgets I simply want a fallback model, so authors can nest <content>: e.g. <content src="..." type="image/svg"> <content src="" type="text/html"></content>
  34. # [06:26] <marcos_away> </content>
  35. # [06:59] * Joins: Navarr (navarr@76.240.60.84)
  36. # [07:00] <Hixie> marcos_away: in practice, few people bother to ever give multiple types of content
  37. # [07:00] <Hixie> marcos_away: you're better off just mandating specific formats
  38. # [07:01] <marcos_away> I know, but crazy vendors want me to include it so they can use their proprietary formats:(
  39. # [07:06] <Hixie> say no
  40. # [07:06] <marcos_away> There is even one that wants me to support XForms (shock!) :)
  41. # [07:06] <Hixie> in a widget?!
  42. # [07:06] <marcos_away> yep
  43. # [07:07] * marcos_away is now known as marcos_
  44. # [07:07] <Hixie> i'll go back to "say no" :-)
  45. # [07:08] <marcos_> hehe, you are probably right.
  46. # [07:33] <shepazu> it's possible that multiple types of content aren't supplied because there aren't reliable fallback mechanisms
  47. # [07:53] <marcos_> shepazu, please explain?
  48. # [07:56] <shepazu> marcos_: at least for the SVG community, there has been a long-standing complaint that you can't really provide a fallback image for SVG content reliably across browsers... not with iframe, object, or embed... I would like to be able to put up a table or a raster image in the fallback content, but it doesn't work in practice
  49. # [07:57] <shepazu> I'd have to look for my actually tests to report results, but as of a couple years ago, at least, it was totally non-interoperable
  50. # [07:57] <marcos_> Is that because SVG has a design flaw? (I don't know, I never used any SVG)
  51. # [07:57] <shepazu> no, I mean for HTML
  52. # [07:57] <marcos_> ah
  53. # [07:57] <shepazu> SVG's design flaws are a whole nother issue :)
  54. # [07:57] <marcos_> :)
  55. # [07:58] <shepazu> so, if I wanted to supply SVG for browsers that supported it, and HTML or rasters for those that didn't, I couldn't really do that reliably
  56. # [07:59] <shepazu> which is at least one reason people don't supply alternate content
  57. # [07:59] <shepazu> (for SVG, at least)
  58. # [08:14] <hsivonen> marcos_: I'd require support for HTML, and XHTML+SVG and add HTML+SVG once there's implementation experience from a full browser engine
  59. # [08:15] <marcos_> At this point, only "HTML" support is required.
  60. # [08:16] <marcos_> other types are optional
  61. # [08:16] <shepazu> that's unacceptable!!!
  62. # [08:16] <shepazu> you must make HTML optional, too :)
  63. # [08:17] <hsivonen> marcos_: chances are that engines that don't support SVG don't support HTML to a satisfactory extent, either
  64. # [08:18] <hsivonen> marcos_: so if in practice the level of HTML support varies, I don't see how a spec could force the situation not to vary
  65. # [08:18] <marcos_> Yeah, agreed. Hence my quoting of "HTML"
  66. # [08:18] <shepazu> ok, I was actually joking... but what about Batik supporting SVG Widgets... it doesn't have HTML support...
  67. # [08:19] <shepazu> but I doubt I could sell you on that :)
  68. # [08:19] <marcos_> The widget spec is will not test for HTML conformance, only for conformance to its packaging, dig sig, apis, etc
  69. # [08:19] <marcos_> Shepazu, that's why I wanted to add fall back support
  70. # [08:19] <hsivonen> shepazu: where would a Batik-based widget platform be used?
  71. # [08:20] <marcos_> <content src="some.svg" type="image/svg+xml"> <content src="some.html"/> </content>
  72. # [08:20] <hsivonen> marcos_: I highly doubt that people who are thinking in terms of developing a Dashboard widget would bother writing fallback for Batik, although they might want to bother with Opera and Gecko compat
  73. # [08:21] <shepazu> hsivonen: huh? anywhere the developer wants... there are actually lots of batik-based projects
  74. # [08:21] <shepazu> but I'm not seriously going to push that agenda, it was just a thought
  75. # [08:21] <hsivonen> shepazu: Is content for them deployed also for other engines, so that interop matters?
  76. # [08:22] <marcos_> hsivonen, agreed. But I've had requests to support proprietary formats. I'm just trying to work out a good way to do it.
  77. # [08:22] <hsivonen> (fwiw, I've used Batik, too, but in a scenario where I controlled the content myself)
  78. # [08:22] <shepazu> hsivonen: any SVG content that works in Batik should work in, for example, Opera, too
  79. # [08:23] <shepazu> and most of it in FF and WebKit as well
  80. # [08:23] <hsivonen> shepazu: or more to the point, are the people who'd develop widgets for Batik likely to write fallback for Vista widgets (if Vista added support for W3C packaging but not for SVG)?
  81. # [08:23] <shepazu> I mean, it all *should* work...
  82. # [08:24] <hsivonen> In practice, it was non-trivial to write content that worked across Batik, Prince, Opera, WebKit and Gecko
  83. # [08:24] <shepazu> dunno, I'm not working on a widget engine... but if there's a market there, someone may well exploit it
  84. # [08:25] <shepazu> seems silly to *require* HTML support for a packaging format :)
  85. # [08:25] <marcos_> You need some UI language for widgets
  86. # [08:25] <hsivonen> I'm very doubtful that the cost of implementing HTML vs. SVG or SVG vs. HTML fallback would be worth it
  87. # [08:26] <marcos_> The issue is not an economics one. It's just about developing a mechanism that works
  88. # [08:26] <shepazu> hsivonen: not sure I follow
  89. # [08:26] <hsivonen> marcos_: if the economics are against the use case for it, why bother?
  90. # [08:26] <marcos_> if nesting <content> elements solves the problem, then rich company X can build support for HTML and for their proprietary format.
  91. # [08:27] <hsivonen> shepazu: I have a hard time believing that writing dual HTML and SVG code paths would be so commonplace that it would be worthwhile to support packaging them together instead of offering separate widget downloads for Vista and Batik
  92. # [08:27] <marcos_> Eg. lets say M$ wanted to implement the widget spec, but allowed widget developers to build native Silverlight apps.
  93. # [08:27] <marcos_> But also supported HTML. They could do that easily.
  94. # [08:28] <marcos_> hsivonen, good point
  95. # [08:28] <hsivonen> marcos_: why would you do the packaging R&D for Silverlight widgets?
  96. # [08:29] <marcos_> It's not about silverlight or any other proprietary technology, it's just about supporting any technology. Even, lets say, HTML6 (pretending it gets a new MIME type)
  97. # [08:30] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  98. # [08:30] <shepazu> hsivonen: I thought we were talking about a widgets deployment format, not a whole browser?
  99. # [08:31] <marcos_> Well, you need a browser to render the widget's start file.
  100. # [08:31] <marcos_> browser = some user agent
  101. # [08:31] <marcos_> Realistically, it's going to be something like webkit or firefox
  102. # [08:31] <hsivonen> shepazu: we are, but I expect a widget developer to set out to write an HTML widget or an SVG widget instead of writing both HTML and SVG widgets and putting them in a fallback mechanism
  103. # [08:32] <marcos_> Modified webkit or firefox that support the additional APIs, I should say
  104. # [08:32] <shepazu> why? that seems a rather big assumption
  105. # [08:32] <hsivonen> shepazu: and when someone *does* write both HTML and SVG versions, because they want to target HTML-only (Vista) or SVG-only (Batik), they can offer two widget packages
  106. # [08:33] <shepazu> or, they could package them together...
  107. # [08:33] <hsivonen> shepazu: because developing dual code paths sucks, and people tend to have a primary development target
  108. # [08:33] <Hixie> marcos_: (btw, to answer your earlier question, now that i understand the context better -- the problems with <object> mostly came from the way it is intended to handle all kinds of content, e.g. plugins, iframes, images, etc -- not from the fallback behaviour)
  109. # [08:34] <marcos_> hsivonen, another use case is having different views (you might want an SVG clock, but a HTML view in a list of minimized running apps)
  110. # [08:34] <shepazu> if the only difference is the rendering format and some HTML/SVG-specific APIs, and the rest of the widget is shared code (like in good OO design), then packaging them together makes the most sense
  111. # [08:35] <hsivonen> marcos_: shouldn't that kind of widget require both HTML and SVG support and allow the user to navigate between two views?
  112. # [08:35] <marcos_> Hixie, thanks for the clarification.
  113. # [08:35] <shepazu> you don't want the user to have to decide which one to download
  114. # [08:35] <shepazu> the user just wants it to work
  115. # [08:36] <hsivonen> shepazu: it doesn't just work for a Vista user, if a significant proportion of widgets available require SVG support, and you have to download to package to see it fail
  116. # [08:36] <hsivonen> or for a Batik user if most widgets require HTML support, and you have to download the package to discover failure
  117. # [08:39] <hsivonen> anyway if someone want to package dual formats in one widgets, I expect sniffing createElementNS return values to be more reliable than expecting the widget container to know it capabilities and resolve declarative fallback correctly
  118. # [08:40] <hsivonen> (which poses the question of what format you use to bootstrap an initial document object)
  119. # [08:40] <marcos_> I'll reiterate, the use case is that company X is has created proprietary format Y. Company X wants wide adoption of its proprietary technology, but has been blocked from deploying unless it piggy-backs on the widget spec. Company X spent billions on its technology, and has large user base, but want to also be able to target HTML users.
  120. # [08:41] <shepazu> that raises an interesting point... marcos_, is there any way for a UA to discover whether it will (at least theoretically) support the content of the widget? like, IE might say, oh, I don't support this because it relies on SVG... but if it says that it wants SVG but has an HTML/Silverlight fallback, IE might say, "oh, ok, yeah, I can deal with this"... that way, the user would have realistic expectations... maybe this could be exposed in the manifest?
  121. # [08:41] * Joins: timeless (timeless@65.75.195.122)
  122. # [08:42] <marcos_> shapazu, that's the nested <content> proposal
  123. # [08:42] <hsivonen> shepazu: I'm very pessimistic about any requirement descriptions other than human-readable text in natural language
  124. # [08:42] <Hixie> marcos_: do you work for company X?
  125. # [08:43] <marcos_> nope
  126. # [08:43] <hsivonen> marcos_: I think "has created proprietary format Y" is the problem
  127. # [08:43] <marcos_> I wish I did, that would be cool.
  128. # [08:43] <Hixie> then why would you do something to help promote a proprietary format?
  129. # [08:43] <marcos_> Company X does not exist, btw
  130. # [08:43] <shepazu> Company X would be a great name for a startup... marcos, you interested?
  131. # [08:44] <marcos_> Shepazu, lets do it! our moto "to push our proprietary crap on everyone!"
  132. # [08:44] <shepazu> we could have a product called Foo
  133. # [08:44] <Hixie> if company X doesn't exist, then the problem is hypothetical, so it seems premature to try and solve it :-)
  134. # [08:44] <hsivonen> marcos_: I think you should support the use case only if you have a Game Theory scenario that shows you that not supporting proprietary formats leads to a worse overall outcome (e.g. by company X deploying a container that gets used outside format Y)
  135. # [08:46] <timeless> thx
  136. # [08:47] <hsivonen> timeless: ?
  137. # [08:47] <marcos_> Ok, I am secretly company X (but don't tell anyone)
  138. # [08:47] <shepazu> [off] marcos_, you just screwed up!
  139. # [08:48] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  140. # [08:48] <marcos_> doh!
  141. # [08:48] <timeless> ww
  142. # [08:49] <shepazu> yes, marcos_, it would be better to wait for a wider and more detailed study over a longer time scale :)
  143. # [08:50] <marcos_> I'm just preempting some feedback that I will get about this for the Widgets Requirements in the next few weeks
  144. # [08:50] * marcos_ can predict the future
  145. # [08:50] <shepazu> marcos_, if you get such feedback, you might find this helpful: http://ian.hixie.ch/bible/handling-people
  146. # [08:51] <Hixie> there's some great stuff in there
  147. # [08:51] <marcos_> I've read it many a times :)
  148. # [08:52] <marcos_> Shepazu pulled "Say it would be better to wait for a wider and more detailed study over a longer time scale."
  149. # [08:52] <marcos_> on me
  150. # [08:52] <shepazu> never!
  151. # [08:52] <marcos_> hehe
  152. # [08:53] <shepazu> marcos_, you're harboring a grudge against my group!
  153. # [08:53] <marcos_> Shapazu, you are nothing but a a publicity seeker!
  154. # [08:53] <shepazu> and you're just trying for a knighthood, vice-chancellorship, or similar!
  155. # [08:54] <shepazu> wait.
  156. # [08:54] <Dashiva> (a ph.d, actually)
  157. # [08:54] <marcos_> And, this one I know to be true, you used to be a consultant to a multi-national company!
  158. # [08:54] <Dashiva> The interesting part is that everything you guys have said is true :)
  159. # [08:54] <shepazu> au contraire! oh, wait... that's actually true. but it was a very small multi-national company!
  160. # [08:55] <marcos_> I insist that we talk about this through more appropriate "channels."
  161. # [08:55] <Dashiva> What's worse, a big company that's only a little multinational, or a small company that's very multinational?
  162. # [08:55] <shepazu> marcos_, there are security considerations in that suggestion
  163. # [08:56] <marcos_> I think we should for a committee. But it should have a least 5 people to discuss this.
  164. # [08:56] <shepazu> Dashiva: fwiw, I don't think marcos_ has a grudge against my group
  165. # [08:56] <timeless> [off] and openness concerns, how dare you change the channel!
  166. # [08:56] <shepazu> marcos_, I think you'll find the figures are open to other interpretations
  167. # [08:57] <Dashiva> shepazu: SVG is the main reason he's struggling with the fallback thing ;)
  168. # [08:58] <marcos_> it's true.
  169. # [08:58] <shepazu> Dashiva, we were a small company that had one person in each: US, Canada, Germany, Switzerland, England, and the Netherlands (IIRC)
  170. # [08:59] <hsivonen> shepazu: that makes it extremely multinational in proportion to the head count!
  171. # [08:59] * Joins: heycam (cam@210.84.41.18)
  172. # [08:59] <shepazu> that's fairly multinational, but not really in a representative fashion... noone from huge markets like Asia, very US-Euro-centric
  173. # [08:59] <shepazu> hsivonen: indeed!!
  174. # [09:00] <timeless> it's germanic!
  175. # [09:00] * Quits: mjs (mjs@24.5.43.151) (Ping timeout)
  176. # [09:00] <hsivonen> for a company to be even more relatively multinational, they'd have to hire people with multiple nationalities
  177. # [09:01] * Joins: mjs (mjs@24.5.43.151)
  178. # [09:01] <shepazu> hsivonen: we had that covered, too! we had 2 swiss guys, actually, and each had dual citizenship (one with Austria, one with Canada)
  179. # [09:02] <shepazu> we also had a blind african woman of chinese/indian descent
  180. # [09:02] <shepazu> ok, that's not true.
  181. # [09:02] <shepazu> only one of us was a woman, and she wasn't blind... she was blond, though
  182. # [09:02] * Quits: mjs (mjs@24.5.43.151) (Connection reset by peer)
  183. # [09:02] * Joins: mjs (mjs@24.5.43.151)
  184. # [09:03] <shepazu> which I think should count
  185. # [09:17] * Joins: ggDashiva (noone@195.18.164.170)
  186. # [09:20] * Joins: anne (annevk@212.242.58.15)
  187. # [09:25] <marcos_> "But so far the editor of the HTML5 draft has shown indifference (some might say hostility) toward RDFa and toward making any changes to trying to address that need." http://times.usefulinc.com/2008/06/24-uf-rdfa
  188. # [09:26] <marcos_> Surely not!
  189. # [09:26] <marcos_> :P
  190. # [09:29] <hsivonen> Web 2.0 outsourcing prevents the page from loading
  191. # [09:38] * Joins: Lionheart (robin@66.57.69.65)
  192. # [10:13] <MikeSmith> "The interim junior co-chair of the working group has thus far shown indifference (some might say hostility) toward the needs of those arriving with sketches of airplanes they'd like implementors to build for them."
  193. # [10:14] <Hixie> i believe that is a compliment
  194. # [10:15] <Hixie> (and a well-earned one, i might add)
  195. # [10:18] <hsivonen> MikeSmith: is that an actual quote?
  196. # [10:19] <MikeSmith> hsivonen: no, just something I can imagine somebody saying
  197. # [10:19] <anne> :p
  198. # [10:20] <MikeSmith> I figured I would get some reactions to the "shipbuilding" QA blog entry I wrote, but don't seem to be any so far
  199. # [10:21] <MikeSmith> http://www.w3.org/QA/2008/06/shipbuilding.html
  200. # [10:21] <MikeSmith> but John Boyer posted a comment to the dbaron interview
  201. # [10:22] <hsivonen> Hixie: I'm impressed by how well the foreign content stuff responds to bogus input
  202. # [10:22] <MikeSmith> http://www.w3.org/QA/2008/06/interview_david_baron_on_firef.html#c151036
  203. # [10:25] <Hixie> hsivonen: cool
  204. # [10:26] * hsivonen congratulates self for doing token-major insertion-mode-minor dispatching despite what the spec says
  205. # [10:26] <Hixie> :-)
  206. # [10:35] * Joins: tH (Rob@87.102.5.204)
  207. # [10:41] <takkaria> I think hubbub might end up with a mixed approach
  208. # [10:41] <MikeSmith> Hixie: so no more open issues for URLs? (except for the one mentioned in the note at the beginning of the URLs section)
  209. # [10:41] <takkaria> where character/doctype/eof tokens get dealt with token-major and everything else insertion-major
  210. # [10:42] <Hixie> MikeSmith: my main goal, defining how to handle errorneous URIs and how to handle non-ASCII content in URIs everywhere, is now done, yes.
  211. # [10:42] <MikeSmith> k
  212. # [10:45] * Hixie resists the temptation to write a smartass answer on mike's blog entry ("I considered your suggestion, but it's not really in line with our goals for this version, so I'm not going to do it for now.")
  213. # [10:46] <MikeSmith> my blog entry?
  214. # [10:46] <Hixie> shipbuildin
  215. # [10:48] <MikeSmith> ah
  216. # [10:55] <ggDashiva> John Boyer isn't really doing xforms a favor with the tone of that comment...
  217. # [11:08] * marcos_ so glad Hixie took the initiative to do the URL stuff... now he can just copy and paste into the widget spec :D
  218. # [11:10] <MikeSmith> about John's comment, this part: "the demand for XForms is such that IBM has decided not to wait for web browser makers to define the web. Just as Ajax libraries like Dojo are coming to define the new face of web application development"
  219. # [11:11] <MikeSmith> I've seen several different people saying things quite similar to that lately
  220. # [11:11] <MikeSmith> seems like they may have gotten together and decided to use it as a common message
  221. # [11:12] <MikeSmith> to suggest that browser vendors are no longer innovating and can be safely ignored (or something)
  222. # [11:13] <MikeSmith> which would seem like sort of a convenient view to have if you were working on specs without actively trying to get browser vendors involved in the work on those specs
  223. # [11:17] <takkaria> the thing is, John's comments don't actually refute what David says
  224. # [11:17] <takkaria> Mozilla obviously hasn't seen enough demand to balance the cost of writing/testing/offering/permanently supporting the code in Firefox
  225. # [11:18] <takkaria> because if they had, then they would be trying to meet it
  226. # [11:19] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  227. # [11:20] * Joins: Lachy (Lachlan@85.196.122.246)
  228. # [11:22] <takkaria> it also sounds like XForms is being deployed in intranet apps, not interweb apps, so it seems like a plugin would do there anyway
  229. # [11:23] <MikeSmith> takkaria: yeah, I think John doesn't address the issue that the cost of actually implementing is just one part of the overall cost. maybe just a small part of the cost, looking at it long-term
  230. # [11:23] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  231. # [11:23] <MikeSmith> I personally think a lot of Web developers would really like to have native XForms support and could come up with some great applications to make use of it
  232. # [11:24] <takkaria> I don't really know what can't be done now that could be done with XForms
  233. # [11:25] <takkaria> all their advertising is about schemas and XML
  234. # [11:25] <MikeSmith> I guess it's a matter of what could possibly be done more easily than it could be now
  235. # [11:25] <MikeSmith> yeah, it's definitely not to their advantage to advertise those aspects
  236. # [11:26] * Quits: mjs (mjs@24.5.43.151) (Connection reset by peer)
  237. # [11:26] * Joins: mjs (mjs@24.5.43.151)
  238. # [11:27] <MikeSmith> I think the big advantages from XForms would come only if it were implemented interoperably across browsers
  239. # [11:28] * marcos_ plugs http://standardssuck.org upcoming episode "W3C Digging the XML Grave" ... should be out later today!
  240. # [11:28] <takkaria> I guess I just don't see the need for a paradigm shift in the way forms are used on the web
  241. # [11:29] <hsivonen> I don't see a need for a paradigm shift, either.
  242. # [11:29] <takkaria> web forms 2 seems to hit the sweet spot, more-or-less
  243. # [11:29] <MikeSmith> so it would allow developers who wante to use declarative approach for buidling cross-browser apps. that is, leaving heavy lifting up to the browser instead of needing to do it themselves in JS code
  244. # [11:29] <hsivonen> however, for Ajax app, it makes sense to implement MVC in JS instead of relying on an XForms engine providing one blessed MVC engine
  245. # [11:30] <MikeSmith> I think XForms is meant to be useful for more than just forms
  246. # [11:30] <MikeSmith> it has evolved that way, anyway
  247. # [11:30] <hsivonen> marcos_: what's the grave? 5th ed.?
  248. # [11:32] <MikeSmith> takkaria: anyway, I'm playing devil's advocate here. it seems at this point that there's not much likelihood of XForms getting implemented natively across browsers is
  249. # [11:33] <takkaria> I guess I'm just not sold on declarative languages full stop. code and data aren't as distinct as people would like to think they are, IME, and web forms 2 seems to do about the right thing (move from JS->HTML for really common things)
  250. # [11:33] <hsivonen> the problem with being declarative is that once you escape to JS even a little (the XForms group showed interest in XHR for instance), the main selling points of being declarative get poisoned
  251. # [11:33] <hsivonen> so one might as well embrace JS from the getgo
  252. # [11:34] <hsivonen> (hmm. I guess I just ended up arguing against the WF2 repetition templates)
  253. # [11:35] * Joins: Lachy (Lachlan@213.236.208.22)
  254. # [11:35] <MikeSmith> yeah, the work on declarative approaches seems to be bases on a hypothesis that declarative approaches are absolutely better and that many or most developers would prefer them, given a choice
  255. # [11:36] <MikeSmith> but there does not seem to be a huge amount of data to support that hypothesis
  256. # [11:36] <MikeSmith> and some that seems to disprove it
  257. # [11:36] <MikeSmith> for example, the popularity of <canvas> among developers
  258. # [11:37] <hsivonen> it's a conspiracy perpetrated by CS curricula not starting with Prolog
  259. # [11:38] <hsivonen> hmm. my error messages in 'in frameset' suck
  260. # [11:38] <MikeSmith> hsivonen: WF2 repetition templates are sort of slated for removal at this point, are they not? seems like browser vendors have not shown much interest in supporting them
  261. # [11:38] <Philip> Most web developers have not partaken in CS curricula
  262. # [11:39] <hsivonen> MikeSmith: didn't Opera implement them? I have no idea about interest on part of other vendors.
  263. # [11:40] <Philip> If I remember correctly, the <datatemplate> stuff in the spec was an attempt at replacing the WF2 repetition feature
  264. # [11:41] * Quits: anne (annevk@212.242.58.15) (Ping timeout)
  265. # [11:41] <MikeSmith> many of the best developers (non-Web, C/C++ developers) I have worked with professionally have not partaken of CS curricula. they came from some other field and picked up programming initially as a scratch-an-itch means-to-an-end way to solve some other problem they needed to solve for their original work
  266. # [11:41] <Philip> (Opera does implement repetition like in http://olav.dk/wf2/demo/repetition.asp )
  267. # [11:42] <MikeSmith> hsivonen: I thought they were not implemented in Opera, but perhaps I'm wrong
  268. # [11:42] <MikeSmith> hsivonen: conspiracy perpetrated by CS curricula not starting with Prolog? what's special about Prolog in this regard?
  269. # [11:42] <hsivonen> MikeSmith: I may be wrong about Opera
  270. # [11:42] <hsivonen> MikeSmith: Prolog is declarative
  271. # [11:43] <Philip> MikeSmith: They are
  272. # [11:46] <Philip> The "Moving blocks" bit of http://olav.dk/wf2/demo/repetition.asp does expose a bug in Opera's redrawing of move-up/down buttons, though
  273. # [11:47] <Philip> I never paid much attention to Prolog, but I was taught some Verilog, which seems like a declarative language
  274. # [11:47] <mjs> if XForms can be usefully implemented in script then perhaps there is no need to implement it natively in browsers
  275. # [11:48] * Joins: matt (matt@128.30.52.30)
  276. # [11:49] <ggDashiva> prolog is an exercise in doubt
  277. # [11:50] <ggDashiva> You give the program some constraints and hope it doesn't do something really stupid when solving it
  278. # [11:50] <hsivonen> does XForms depend on the PSVI?
  279. # [11:51] * hsivonen considers the PSVI harmful
  280. # [11:51] <MikeSmith> mjs: given improvements in JS interpreter performance, maybe XForms implemented as a cross-browser JS library is more feasible now that it would have been before
  281. # [11:51] <MikeSmith> hsivonen: I think it does not
  282. # [11:51] <MikeSmith> it doesn't absolutely depend on schema support
  283. # [11:52] <hsivonen> MikeSmith: good
  284. # [11:52] <MikeSmith> yeah
  285. # [11:52] <MikeSmith> depending on PSVI would be a deal breaker for sure
  286. # [11:54] <MikeSmith> anyway, the general premise that declarative programming is something a lot of developers would seem to suggest we'd all already be using lots of great apps built using Prolog or whatever
  287. # [11:54] <MikeSmith> something a lot developers would want/prefer
  288. # [11:57] <Philip> It would suggest we'd all be writing declarative formulas into Excel
  289. # [11:57] <Philip> Oh, we are
  290. # [11:57] <MikeSmith> heh
  291. # [11:57] <MikeSmith> SQL
  292. # [11:58] <ggDashiva> Philip: Or that we're using the spreadsheet as a variable matrix and using it for regular imperative programming :P
  293. # [11:58] <MikeSmith> most people I work with don't use Excel for formulas. they use it as a pretty table editor
  294. # [11:58] <hsivonen> for some reason, theoretical purity of programming languages and doing real work don't go hand in hand. A lot of real work is done in C++ which isn't exactly the most pure language.
  295. # [11:59] <MikeSmith> "worse is better"
  296. # [12:00] <ggDashiva> In the ultimate parable, declarative programming is like wearing a straitjacket. You can't stab yourself in the foot anymore, but it feels kinda restrictive :)
  297. # [12:00] <takkaria> you said SQL, but SQL is an example of where people wilfully concatenate strings and all do manner of weird string handling, and then loop over the results and do something imperitive wit hthem
  298. # [12:00] <takkaria> and even SQL has functions and whatnot, doesn't it?
  299. # [12:01] <takkaria> to me it looks like declarative works in a very small and well-defined problem space, I haven't seen that it works too well outside of that
  300. # [12:01] <ggDashiva> _Pure_ functions don't conflict with declarativeness (I believe)
  301. # [12:01] * takkaria wonders if all the uses of his sweeping statement licence have been used now...
  302. # [12:01] * Philip offers takkaria a free 30-day licence extension
  303. # [12:02] <hsivonen> on the Web, there's always a trouble-maker who doesn't agree about what the problem space is
  304. # [12:19] * Joins: anne (annevk@93.163.61.34)
  305. # [12:35] * Joins: ROBOd (robod@89.122.216.38)
  306. # [12:47] * Quits: anne (annevk@93.163.61.34) (Ping timeout)
  307. # [13:03] * Joins: jgraham_ (jgraham@131.111.68.181)
  308. # [13:04] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  309. # [13:04] * Joins: Lachy (Lachlan@213.236.208.22)
  310. # [13:05] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
  311. # [13:14] * Quits: scotfl (scotfl@70.64.14.62) (Ping timeout)
  312. # [13:17] * Joins: scotfl (scotfl@70.64.14.62)
  313. # [13:38] * Joins: Lionheart (robin@66.57.69.65)
  314. # [13:56] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
  315. # [14:48] * Quits: gavin_ (gavin@99.253.193.147) (Ping timeout)
  316. # [14:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  317. # [14:54] * Joins: gavin_ (gavin@99.253.193.147)
  318. # [15:06] * Joins: myakura (myakura@222.145.138.216)
  319. # [15:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  320. # [15:50] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  321. # [16:20] * Joins: Lachy (Lachlan@85.196.122.246)
  322. # [16:21] * Joins: billmason (billmason@69.30.57.192)
  323. # [17:11] * Joins: anne (annevk@93.163.61.34)
  324. # [17:48] * Quits: rking3 (rking3@24.5.77.167) (Connection reset by peer)
  325. # [17:48] * Joins: rking3_ (rking3@24.5.77.167)
  326. # [18:08] * Parts: anne (annevk@93.163.61.34)
  327. # [18:12] * Joins: ChrisWilson (cwilso@131.107.0.103)
  328. # [18:23] * Joins: aroben (aroben@71.58.56.76)
  329. # [18:34] <Philip> DanC: "RESOLVED FIXED (hmm... how can I find out when it was resolved?)" - use the "View Bug Activity" link, which goes to https://bugzilla.mozilla.org/show_activity.cgi?id=284474 and shows the status changes
  330. # [18:35] <DanC> right; just found that. thanks.
  331. # [18:58] * Quits: myakura (myakura@222.145.138.216) (Quit: Leaving...)
  332. # [19:07] <DanC> hmm... Zarro Boogs found when I search webkit bugs for "IRI". am I doing it wrong?
  333. # [19:07] <DanC> https://bugs.webkit.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=WebKit&content=IRI
  334. # [19:12] <DanC> wild... Bug 19193: data:// URLs should not inherit charset from parent frame https://bugs.webkit.org/show_bug.cgi?id=19193
  335. # [19:13] <Philip> DanC: Looks like you're doing it right
  336. # [19:13] <Philip> though if you search for something like "uri utf" then there's https://bugs.webkit.org/show_bug.cgi?id=7461
  337. # [19:14] <DanC> hmm... "IE 7 beta preview2 reportedly [uses utf-8 all the time]". I wish that came with a link
  338. # [19:15] <Philip> Also https://bugs.webkit.org/show_bug.cgi?id=15119
  339. # [19:15] <Philip> (which is for the query part)
  340. # [19:16] <DanC> hmm... https://bugs.webkit.org/show_bug.cgi?id=7461#c4 suggests the problem is going away
  341. # [19:17] <Philip> 7461 seems to be about the path component, which all current browsers seem to always encode as UTF-8
  342. # [19:18] <Philip> (where "current" excludes FF2)
  343. # [19:18] <DanC> what's <rdar://problem/4306856> ? a reference to an apple bug?
  344. # [19:18] <Philip> I think that's some internal Apple thing
  345. # [19:20] * DanC chuckles @ "Ugh, I've got way too many coding styles in my head nowadays.
  346. # [19:20] <DanC> "
  347. # [19:22] <DanC> the code review bits of 15119 are kinda fun, but... I think I lost the main thread.
  348. # [19:22] <DanC> "Instead, it should do like the form encoder, which causes ICU to generate
  349. # [19:22] <DanC> entity names."
  350. # [19:22] <DanC> seriously?
  351. # [19:24] <Philip> Try searching for "☹" on http://www.baidu.com/
  352. # [19:24] <Philip> (which is gb2312)
  353. # [19:24] <Philip> It gets converted to &#9785; in the form submission
  354. # [19:26] <gsnedders> DanC: Radar is Apple's bug tracking software (private), and they have their own proprietary URI scheme for it, so yeah
  355. # [19:26] <Philip> Also try searching "æ" - in IE6 it gets converted into "&aelig;" in the form submission, in FF3/O9.5/S3.0 it gets converted into "&#230;"
  356. # [19:27] <Philip> (What does WebKit nightly do?)
  357. # [19:27] <Philip> Anyway, this is a whole new set of problems compared to URLs in <a href> :-)
  358. # [19:28] <Philip> Don't you love the web?
  359. # [19:28] <DanC> yes, hixie said he was leaving forms aside for now
  360. # [19:28] <DanC> I used to love the web. I'm not sure any more.
  361. # [19:29] <gsnedders> As I said to ChrisW ages ago: "Life is as logical as HTML."
  362. # [19:31] <Philip> It's like a hundred billion sausages
  363. # [20:13] * Joins: Julian_Reschke (chatzilla@80.143.232.121)
  364. # [20:13] * Julian_Reschke is now known as Julian
  365. # [20:35] * matt is now known as mattSWUpdate
  366. # [20:50] * mattSWUpdate is now known as matt
  367. # [20:53] * matt is now known as mattMoreUpdates
  368. # [21:03] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  369. # [21:04] * Joins: Lachy (Lachlan@85.196.122.246)
  370. # [21:21] * Quits: scotfl (scotfl@70.64.14.62) (Quit: scotfl)
  371. # [21:26] * mattMoreUpdates is now known as matt
  372. # [21:52] * Joins: aaronlev (chatzilla@92.228.71.242)
  373. # [21:52] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  374. # [21:53] * Joins: Lachy (Lachlan@85.196.122.246)
  375. # [21:58] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  376. # [21:58] * Joins: Lachy (Lachlan@85.196.122.246)
  377. # [22:11] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  378. # [22:12] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  379. # [22:12] * Joins: Lachy (Lachlan@85.196.122.246)
  380. # [22:13] * Joins: adele (adele@17.203.14.243)
  381. # [22:17] * Quits: ChrisWilson (cwilso@131.107.0.103) (Ping timeout)
  382. # [22:47] <Hixie> cvs.bin commit: [20:41:58] waiting for www-data's lock in /sources/public/html5/spec
  383. # [22:47] * Hixie twiddles thumbs
  384. # [22:50] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  385. # [22:54] * Joins: drry_ (drry@211.9.156.172)
  386. # [22:55] * Quits: drry (drry@211.9.156.86) (Ping timeout)
  387. # [23:08] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  388. # [23:08] * Joins: Lachy (Lachlan@85.196.122.246)
  389. # [23:10] * Quits: hober (ted@206.212.254.2) (Quit: ERC Version 5.3 (IRC client for Emacs))
  390. # [23:12] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  391. # [23:12] * Quits: Julian (chatzilla@80.143.232.121) (Ping timeout)
  392. # [23:15] * Joins: Lachy (Lachlan@85.196.122.246)
  393. # [23:22] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  394. # [23:23] * Joins: Lachy (Lachlan@85.196.122.246)
  395. # [23:38] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  396. # [23:39] * Joins: Lachy (Lachlan@85.196.122.246)
  397. # [23:44] * Joins: erik (erik@84.29.164.153)
  398. # [23:44] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  399. # [23:46] * Quits: erik (erik@84.29.164.153) (Quit: Bye bye)
  400. # [23:54] * Joins: Lachy (Lachlan@83.109.61.9)
  401. # Session Close: Sat Jun 28 00:00:00 2008

The end :)