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

Options:

  1. # Session Start: Sat Mar 24 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:11] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  4. # [00:14] * Quits: hendry (n=hendry@91.84.53.136) ("nn")
  5. # [00:22] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  6. # [00:24] * Quits: weinig (n=weinig@odin.landmark.edu)
  7. # [00:24] * Quits: nickshanks (n=nicholas@home.nickshanks.com)
  8. # [00:24] * Quits: epeus (i=KevinMar@nat/google/x-24c18160aee2934a) ("The computer fell asleep")
  9. # [00:38] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) ("This computer has gone to sleep")
  10. # [00:39] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  11. # [00:40] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  12. # [00:42] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  13. # [00:47] * Joins: mw22____________ (n=chatzill@cc1057475-a.odz1.ov.home.nl)
  14. # [00:47] * mw22____________ is now known as mw22
  15. # [01:05] * Parts: sayrer (n=chatzill@user-10876hc.cable.mindspring.com)
  16. # [01:16] <Philip`> Does anyone know if there's been work on relatively comprehensive tests for parts of <canvas>, more than the random collections on Hixie's and Anne's and Opera's sites?
  17. # [01:17] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) ("Leaving")
  18. # [01:17] <Philip`> I don't pretend to know what I'm doing, but I played around a bit with some tests for the first testable feature and found a case that gives six different results between four implementations and [my interpretation of] the spec
  19. # [01:17] <Dashiva> Which feature is that?
  20. # [01:17] <Philip`> so it seems like it could be a fruitful direction, if it's not repeating other people's work
  21. # [01:18] <Philip`> Just width/height
  22. # [01:19] <Philip`> (particularly when setting it to invalid values)
  23. # [01:19] <Philip`> (...which isn't very relevant in practice, but at least it's easy to test :-) )
  24. # [01:20] <zcorpan_> i don't know of any tests other than hixie's and anne's
  25. # [01:20] <zcorpan_> on <canvas>
  26. # [01:21] <Dashiva> I did some tests for Opera, but those were just to see which features were buggy during early implementation
  27. # [01:21] <Dashiva> They're probably long gone
  28. # [01:22] <Philip`> Ah, okay
  29. # [01:23] <Philip`> http://tc.labs.opera.com/html/canvas/ has a few more (~135), but that's the most I've found
  30. # [01:23] <othermaciej> we have some in the WebKit layout tests
  31. # [01:28] <Hixie> re the video states, i understand the proposed states
  32. # [01:29] <Philip`> http://trac.webkit.org/projects/webkit/browser/trunk/LayoutTests/fast/canvas - that looks like them
  33. # [01:29] <Hixie> i just need to look at them closely to see if the current proposal can be made better :-)
  34. # [01:29] <othermaciej> it wasn't obvious to me at first why some were needed
  35. # [01:29] <Hixie> taking into account everyone's feedback, etc
  36. # [01:29] <othermaciej> which is why I offered
  37. # [01:30] <Hixie> well e.g. ERROR could easily be merged with UNINITIALIZED, it doesn't have to be a separate state
  38. # [01:30] <Hixie> ERROR is an event, not a state
  39. # [01:30] <Hixie> it's a failure to enter another state.
  40. # [01:31] <othermaciej> part of the reason for the states is so that you can catch up if you attach a controller to an already in-use element
  41. # [01:31] <Hixie> sure
  42. # [01:32] <Hixie> you don't need ERROR for that
  43. # [01:32] <othermaciej> a controller would want to know if something hasn't started loading yet, or tried and failed
  44. # [01:32] <Hixie> i don't understand the use case for that particular one
  45. # [01:32] <Hixie> when would you have a controlled join something and then itself decide to start playback if nothing else had?
  46. # [01:33] <othermaciej> I mean for display, not for deciding to play
  47. # [01:33] <othermaciej> "haven't loaded anything" would presumably show different UI than "tried to load this and it broke"
  48. # [01:33] <Hixie> when would you have a controller join a video element and then display a generic error message?
  49. # [01:33] <Hixie> i can't imagine a case where that would happen
  50. # [01:34] <othermaciej> well, if you could have one join after the fact at all, you need to be able to represent the current state of the element enough to continue
  51. # [01:35] <othermaciej> maybe currentSrc being empty or not is enough to distinguish UNITIALIZED from ERROR, but that's a little weird
  52. # [01:35] <Hixie> i could see one join in order to catch cue points for advertising, but i couldn't see that controller care about error state vs not loaded state
  53. # [01:35] <Hixie> currentSrc wouldn't be initialised either
  54. # [01:35] <Hixie> there was an error
  55. # [01:35] <Hixie> thus there's no currentSrc
  56. # [01:36] <othermaciej> so in case of error you couldn't even tell what you tried and failed to load
  57. # [01:36] <Hixie> the error is almost certainly going to have been that you couldn't load anything in the first place
  58. # [01:36] <Hixie> but anyway
  59. # [01:36] <Hixie> like i said
  60. # [01:36] <Hixie> i need to look at this
  61. # [01:36] <Hixie> i haven't specced anything yet
  62. # [01:37] <Hixie> one possible solution is to have the state be STOPPED, but to have a lastError attribute
  63. # [01:37] <Hixie> (or UNINITIALISED, though i hate typing that)
  64. # [01:38] <othermaciej> STOPPED implies that it is what a media control "stop" button would put you in, which does not seem right to me (though most media controls these days don't even have stop really, just pause)
  65. # [01:44] <Lachy> UNINITIALISED is a bad name, the webkit proposal actually spells it UNINITIALIZED
  66. # [01:49] <Lachy> does the load() method need to be called by a script before the video will begin downloading?
  67. # [01:49] <Hixie> play() calls load() in the current proposal
  68. # [01:50] <Lachy> ok
  69. # [01:50] <othermaciej> I would expect auto-loading to be a more desired use case than load-on-demand
  70. # [01:51] <Lachy> how much space is the UA supposed to allocate to the video before it's begun loading it?
  71. # [01:51] <Lachy> without height and width attrs
  72. # [01:52] <othermaciej> you could use CSS, but we also proposed width and height attrs (in part for the before-it's-loaded case, and in part because you want a way to size that excludes controls)
  73. # [01:52] <Lachy> there are cases where autoloading isn't desired by the user
  74. # [01:53] <Hixie> (current spec doesn't yet define autoload="", but note that so for we've read requests for numerous users asking to NOT have load on demand, and only requests from authors asking for it)
  75. # [01:54] <zcorpan_> Kid looks nice.
  76. # [01:54] <othermaciej> having autoload be UA behavior instead of script leaves open the possibility of a UA preference
  77. # [01:54] <Hixie> regarding sizing, we'll have default size, css will size the content area, controls will be a pseudo or something, and i have to go
  78. # [01:54] <Hixie> bbl
  79. # [01:54] <Lachy> zcorpan_, what kid?
  80. # [01:54] <othermaciej> I don't think a UA could reasonably have a pref to ignore an explicit .load() call from script
  81. # [01:54] <zcorpan_> http://www.kid-templating.org/
  82. # [02:14] * Quits: smfr (i=smfr@nat/apple/x-d8130a80382439f7)
  83. # [02:22] * moeffju is now known as moeffju[ZzZz]
  84. # [02:24] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
  85. # [02:28] * Joins: weinig (n=weinig@odin.landmark.edu)
  86. # [02:34] * Joins: ericcarlson_ (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  87. # [02:41] * Quits: ericcarlson_ (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  88. # [02:44] * Joins: aroben_ (i=adamrobe@nat/apple/x-503cd1e2ff429226)
  89. # [02:44] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  90. # [02:45] * Quits: aroben (i=adamrobe@nat/apple/x-4503e90f9e2f3248) (Read error: 104 (Connection reset by peer))
  91. # [02:45] * Joins: aroben (i=adamrobe@nat/apple/x-821bf52c3e5d570b)
  92. # [02:47] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  93. # [02:52] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
  94. # [02:54] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
  95. # [02:54] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  96. # [03:02] * Quits: aroben_ (i=adamrobe@nat/apple/x-503cd1e2ff429226) (Connection timed out)
  97. # [03:17] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  98. # [03:34] * Joins: aroben_ (i=adamrobe@nat/apple/x-224203f8f52c8d46)
  99. # [03:46] * Quits: bzed (n=bzed@dslb-084-059-125-163.pools.arcor-ip.net) ("Leaving")
  100. # [03:49] * Quits: aroben (i=adamrobe@nat/apple/x-821bf52c3e5d570b) (Read error: 110 (Connection timed out))
  101. # [03:49] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  102. # [03:54] * Quits: aroben_ (i=adamrobe@nat/apple/x-224203f8f52c8d46) (Remote closed the connection)
  103. # [03:54] * Joins: aroben (i=adamrobe@nat/apple/x-0b7ac6dc37349a7f)
  104. # [03:54] * Quits: weinig (n=weinig@odin.landmark.edu)
  105. # [04:08] * Joins: weinig (n=weinig@odin.landmark.edu)
  106. # [04:08] * weinig is now known as weinig|away
  107. # [04:11] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  108. # [04:11] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com) (Read error: 104 (Connection reset by peer))
  109. # [04:12] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  110. # [04:22] * Joins: aroben_ (i=adamrobe@nat/apple/x-165f7d2199061fa5)
  111. # [04:32] * Joins: sayrer (n=chatzill@user-12ld2ss.cable.mindspring.com)
  112. # [04:36] * Quits: sayrer (n=chatzill@user-12ld2ss.cable.mindspring.com) (Client Quit)
  113. # [04:39] * Quits: aroben (i=adamrobe@nat/apple/x-0b7ac6dc37349a7f) (Read error: 110 (Connection timed out))
  114. # [05:08] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  115. # [06:02] * Joins: tantek (n=tantek@nmd.hissf.sjc.wayport.net)
  116. # [06:04] * zcorpan_ updated http://simon.html5.org/test/html/embedded/ to match current spec
  117. # [06:17] <Lachy> zcorpan_, we should add SVG to those tests
  118. # [06:17] <zcorpan_> Lachy: is it any different from application/xml?
  119. # [06:18] <Lachy> the XML you've used is XHTML, which isn't an image. SVG is.
  120. # [06:18] <zcorpan_> so svg should work with <img>?
  121. # [06:18] <Lachy> SVG should render inside <img>
  122. # [06:19] <Lachy> it should render in all of them
  123. # [06:20] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  124. # [06:20] <zcorpan_> what is svg? any xml with the root svg:svg?
  125. # [06:21] <Lachy> yes
  126. # [06:21] <Lachy> well, you should check the SVG spec to be sure
  127. # [06:23] <othermaciej> svg should have an image/svg+xml mime type
  128. # [06:23] <othermaciej> I don't think <img> should render application/xml with an SVG root element
  129. # [06:23] <Lachy> does it need that MIME type to work in <img>?
  130. # [06:23] <othermaciej> of course at present no browser renders SVG in <img>
  131. # [06:24] <othermaciej> we had experimental code to do it in WebKit but it is off for now
  132. # [06:24] <othermaciej> I think MIME type should be the trigger, yes, you should not have to parse just to know whether to display
  133. # [06:25] <Lachy> hmm. I guess switching on the MIME is more efficient in this case
  134. # [06:26] <zcorpan_> so xhtml as image/svg+xml should render in <img>?
  135. # [06:26] <zcorpan_> or would that be an invalid image, and thus fallback would be used?
  136. # [06:27] <Lachy> it should render the fallback. What happens with image/png using somehting that isn't an image?
  137. # [06:29] <zcorpan_> well, it will try to parse it as png or gif or jpeg or other supported image formats, if that fails render fallback
  138. # [06:29] <zcorpan_> but svg is just xml
  139. # [06:30] <zcorpan_> so you'd have to check the root element anyway
  140. # [06:30] <zcorpan_> no?
  141. # [06:30] <othermaciej> zcorpan_: SVG can legitimately include xhtml content
  142. # [06:30] <zcorpan_> oh sure
  143. # [06:30] <zcorpan_> but what if the root is not svg:svg?
  144. # [06:31] <othermaciej> I dunno
  145. # [06:31] <othermaciej> is that illegal per the MIME type?
  146. # [06:31] <Lachy> then it's another type of XML that includes SVG
  147. # [06:31] <othermaciej> if you send application/xhtml+xml and have a different namespace element as the root, should that not render?
  148. # [06:31] <Lachy> the root element determines the host langugage
  149. # [06:31] <othermaciej> in, say, an iframe?
  150. # [06:31] <Lachy> othermaciej, yes
  151. # [06:31] <othermaciej> the mime type determines what Document interfaces are present
  152. # [06:32] <othermaciej> so there might be legit reasons to use one that does not match your root element
  153. # [06:32] <Lachy> really? I thought the API was determined by the actual element used
  154. # [06:32] <zcorpan_> is there a spec for svg in <img>?
  155. # [06:33] <Lachy> not a good one
  156. # [06:33] * Quits: tantek (n=tantek@nmd.hissf.sjc.wayport.net) (Read error: 110 (Connection timed out))
  157. # [06:33] <Lachy> HTML4 says <img> is for use with any image type, and lists a few examples like GIF and JPG
  158. # [06:34] <zcorpan_> othermaciej: i thought the idea was as of html5 that the document would implement all interfaces supported, e.g. both HTMLDocument asd SVGDocument if the browser supports both HTML and SVG
  159. # [06:35] <othermaciej> zcorpan_: I do think we should do that, though I'm not sure HTML5 calls for it
  160. # [06:35] <Lachy> zcorpan_, are the interfaces compatible?
  161. # [06:35] <othermaciej> though I have not read super thoroughly
  162. # [06:36] * aroben_ is now known as aroben
  163. # [06:37] <zcorpan_> 2.1. Documents
  164. # [06:37] <zcorpan_> "Document objects must also implement the document-level interface of any other namespaces found in the document that the UA supports. For example, if an HTML implementation also supports SVG, then the Document object must implement HTMLDocument and SVGDocument."
  165. # [06:38] <Lachy> what if the 2 APIs define methods or properties with the same name, but which do different things
  166. # [06:39] <othermaciej> Lachy: I don't think they do at present, and presumably in such a case we would beat SVG WG over the head with a cluebat
  167. # [06:39] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cimg%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%20alt%3D%22FAIL%22%3E%0A%3Ciframe%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%3EFAIL%3C/iframe%3E%0A%3Cembed%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20he
  168. # [06:39] <Lachy> ight%3D%22400%22%20width%3D%22400%22%3E%3C/embed%3E%3Cnoembed%3EFAIL%3C/noembed%3E%0A%3Cobject%20data%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%3E%3C/object%3E
  169. # [06:40] <Lachy> the SVG working group have done some stupid things in SVG. Who knows what they might do
  170. # [06:41] <othermaciej> Lachy: they would probably take feedback from HTML WG more seriously than from individuals
  171. # [06:41] <othermaciej> because they are all procedural like that
  172. # [06:41] <Lachy> I heard they ignored feedback from the CSS WG, regarding some incompatibilites with their use of font-size
  173. # [06:45] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
  174. # [06:48] <zcorpan_> if we want svg to work in <img>, we need a spec for how it should work
  175. # [06:49] <Lachy> it should be addressed in HTML5
  176. # [06:49] <zcorpan_> yeah
  177. # [06:51] <zcorpan_> should it be able to run scripts? should scripts be able to access the parent document? what happens if the dom is modified so that the root is no longer svg:svg?
  178. # [06:51] <Lachy> good question
  179. # [07:01] <othermaciej> zcorpan_: (1) I don't think there should be any requirement on the root element, just the MIME type
  180. # [07:02] <othermaciej> zcorpan_: (2) I don't think user events should be passed in
  181. # [07:02] <othermaciej> zcorpan_: not sure about animation and scripting
  182. # [07:02] <othermaciej> zcorpan_: I am inclined to say to declarative SMIL animations and no to scripting
  183. # [07:02] <othermaciej> my 2c anyway
  184. # [07:02] <othermaciej> Lachy: I'm on the SVG WG now, so I can beat them from within if needed
  185. # [07:03] <othermaciej> although I hope olliej can do most of the dirty work and I can just register needed Formal Objections
  186. # [07:04] * Joins: zcorpan (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
  187. # [07:04] <zcorpan> so what happens with xhtml as image/svg+xml? render it or use fallback?
  188. # [07:06] <othermaciej> render it
  189. # [07:06] <zcorpan> ok
  190. # [07:06] <othermaciej> or generic xml as image/svg+xml
  191. # [07:06] <othermaciej> I know that is kind of crazy
  192. # [07:06] <othermaciej> but if SVG is allowed at all, you can already do <svg:svg><svg:foreignObject><html:whatever...>...
  193. # [07:07] <othermaciej> so ruling out other root elements does not achieve much, unless you ban foreignObject in SVG as IMG
  194. # [07:07] <othermaciej> ideally you also want SVG to work for CSS background images
  195. # [07:07] <othermaciej> we had code for that but it's off for now
  196. # [07:08] <zcorpan> but when the svg is root it's still defined how it should render as an image... having xhtml as a background image doesn't make sense
  197. # [07:09] <othermaciej> how is it more or less defined based on root?
  198. # [07:11] <zcorpan> svg says how to render svg images, and if it includes xhtml as fogeignObject doesn't affect the image's width/height etc
  199. # [07:12] <othermaciej> where does svg say how to render svg images?
  200. # [07:13] <zcorpan> dunno, i haven't read the svg spec carefully, but if it doesn't, what does it say?
  201. # [07:13] <othermaciej> it doesn't say how to render SVG in an html <img> as far as I know
  202. # [07:14] <othermaciej> no spec does
  203. # [07:14] <othermaciej> or as a CSS background image
  204. # [07:14] <zcorpan> indeed
  205. # [07:14] <zcorpan> but it says how svg images should render in general, ignoring <img>
  206. # [07:14] <zcorpan> right?
  207. # [07:14] <othermaciej> it says how SVG should render
  208. # [07:15] <othermaciej> when processed as a top-level XML document
  209. # [07:15] <othermaciej> but of course, xhtml+css already say that for xhtml
  210. # [07:17] <zcorpan> hmm, i guess you could specify a width and height of <html> and let it happily render as a background image, but i thought the intent was that document formats like html shouldn't work as backgrounds in css
  211. # [07:26] <othermaciej> yes, well, it's hard to draw bright lines
  212. # [07:27] <othermaciej> SVG WG would say that SVG isn't an image, it's an animation
  213. # [07:27] <othermaciej> even when static
  214. # [07:27] <othermaciej> so they wouldn't even want that as a background image
  215. # [07:27] * Quits: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  216. # [07:27] <zcorpan> animated gifs work fine as backgrounds, fwiw
  217. # [07:28] <zcorpan> both opera and firefox render xhtml as image/svg+xml in <embed> (and run scripts)
  218. # [07:33] <othermaciej> <embed> is pretty free-wheeling
  219. # [07:33] <othermaciej> but in general browsers don't compare root element to server-reported mime type
  220. # [07:34] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
  221. # [07:35] <zcorpan> you're right, i thought however we didn't want to render xhtml as backgrounds in css, and thus it would be required to check the root element. the mime could then be any xml, not just image/svg+xml
  222. # [07:37] <othermaciej> I think keying off the mime type and letting people cheat is ok
  223. # [07:37] <zcorpan> is it expensive to check the root?
  224. # [07:48] <othermaciej> well, you have to fire up the XML parser and let it run and know to bail out at some point
  225. # [07:48] <othermaciej> not that expensive but you go much deeper than purely by MIME type
  226. # [07:49] <othermaciej> here's the MIME type regsitration for image/svg+xml, you figure it out: http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/mimereg.html
  227. # [07:49] <othermaciej> "Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document."
  228. # [07:50] <othermaciej> it's pretty vague
  229. # [07:51] <zcorpan> yeah... pretty much "this is xml"
  230. # [07:53] <zcorpan> thing is if you allow xhtml to be rendered as background, how should repeated backgrounds be handled, etc? can you interact with <input>s? while it may be more expensive to check the root you get less cases you have to define
  231. # [07:54] <zcorpan> if it will be discarded then authors won't use it, so you can expect all xml as <img> or background to be svg anyway...
  232. # [08:06] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  233. # [08:07] * Quits: aroben (i=adamrobe@nat/apple/x-165f7d2199061fa5)
  234. # [08:18] <webben> i should think xhtml should be rendered in backgrounds, since xhtml is one way of including text in svg
  235. # [08:19] <webben> as for controls, i would render them as static backgrounds
  236. # [08:19] <webben> (assuming we're talking background-image here)
  237. # [08:21] <zcorpan> if you can render xhtml as a background, why not text/html too? text/plain?
  238. # [08:22] <webben> zcorpan, i'd have no objection to either
  239. # [08:22] <webben> zcorpan, but i don't think people are likely to use text/plain
  240. # [08:22] <webben> (no way to apply css to it, so the look is /totally/ unpredictable)
  241. # [08:24] <webben> basically i think anything can be a background, but it should be non-interactive
  242. # [08:24] <zcorpan> i don't think text/html should be usable as a background (as it is today in css)
  243. # [08:25] <webben> why?
  244. # [08:25] <zcorpan> it doesn't make sense
  245. # [08:25] <webben> how come?
  246. # [08:26] <webben> (i mean i agree one's unlikely to /want/ to use it, but that's different)
  247. # [08:26] <zcorpan> because it's a document with semantics, something you would apply css *to*
  248. # [08:28] <webben> AFAIK SVG can be a document with semantics which you apply CSS too as well, separating content (e.g. a diagram, buttons, text) from presentation.
  249. # [08:28] <webben> hence http://www.w3.org/TR/SVG/styling.html
  250. # [08:28] <zcorpan> yes. hence, using svg as a background is slightly bogus too :P
  251. # [08:29] <othermaciej> SVG at least *can* be used as a vector graphics format
  252. # [08:29] <webben> well, what one's really saying is make an image from this.
  253. # [08:29] <othermaciej> and the web could use a scalable vector format for use in images
  254. # [08:29] <webben> i don't see anything intrinsically wrong about making an image from anything
  255. # [08:29] <othermaciej> WebKit supports PDF for that, but PDF is surprisingly bloated
  256. # [08:30] <othermaciej> even simple PDFs are huge
  257. # [08:31] <webben> by definition if used as a background then the semantics are irrelevant clientside
  258. # [08:31] <webben> (although they might be relevant serverside, e.g. i18n of colors in a SVG graphic)
  259. # [08:42] * Parts: zcorpan (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
  260. # [08:59] <Lachy> allowing any format to be used as a background would be a nightmare for implementors
  261. # [08:59] <othermaciej> allowing SVG to be used as a background is a nightmare
  262. # [08:59] <othermaciej> but it's still useful
  263. # [09:00] <Lachy> even if it did make sense (which it doesn't), why would anyone want to use text/html, etc. as an image?
  264. # [09:00] <webben> Lachy, I dunno. Basically just requires the ability to fake a screenshot of displayed content.
  265. # [09:00] <Lachy> I realise SVG has implementation issues too, but it at least has a use case
  266. # [09:00] <webben> as screen capture type programs seem common, it doesn't sound like a huge nightmare
  267. # [09:02] <webben> Lachy, I'm not arguing anyone would want to. But they might possibly wish to use svg+xhtml, which amounts to something similar
  268. # [09:02] <webben> more to the point, if you can solve the probs with svg as background, then i think the text/html probs would be easy to resolve in the same way
  269. # [09:02] <Lachy> so the browser would have to render it, produce an image out of it and then use the resulting image as a background. That seems like a huge performance issue
  270. # [09:03] <Lachy> but why would it be worth the time of implementors trying to solve it, when no one will ever use it?
  271. # [09:03] <webben> Lachy, why is it different to SVG ... which the browser also has to render and produce a static image from?
  272. # [09:04] <webben> Lachy, I suspect we should be speccing support for a subset of formats for backgrounds, and allow implementors to support additional formats if they choose.
  273. # [09:04] <webben> text/html should be one of those additional formats
  274. # [09:05] <webben> my point is just that SVG actually has text/html's problems anyway
  275. # [09:05] <webben> and that svg+xhtml probably should be part of speced support
  276. # [09:06] <Lachy> I agree with SVG, but until there are use cases for other formats, arguing about whether or not they can or should be supported is pointless
  277. # [09:07] <webben> Lachy, well zcorpan was arguing in the opposite direction (you can't support text/html, therefore not xhtml either)
  278. # [09:08] <webben> but xhtml can be part of svg content
  279. # [09:14] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  280. # [09:14] <othermaciej> man, I love watching people try to educate Eric Carlsson about media
  281. # [09:15] <Lachy> othermaciej, who's Eric Carlsson?
  282. # [09:15] <othermaciej> he's probably forgotten more about media than they ever knew
  283. # [09:16] <othermaciej> I misspelled his name though
  284. # [09:16] <othermaciej> one s
  285. # [09:17] <Lachy> ok, still don't know who he is
  286. # [09:17] <hsivonen> othermaciej: are you referring to seeking over HTTP?
  287. # [09:18] <othermaciej> longtime QuickTime developer
  288. # [09:19] <othermaciej> that's the thread I was reading just now
  289. # [09:20] <Lachy> which mailing list? URL?
  290. # [09:20] <Lachy> oh, found his emails
  291. # [09:21] <webben> The ability to separate content from presentation in background graphics formats should ultimately help make authoring more accessible, so it's not all bad.
  292. # [09:22] <webben> (or perhaps i should say: form from style)
  293. # [09:24] <KevinMarks> Eric Rocks
  294. # [09:24] <KevinMarks> seeking over HTTP?
  295. # [09:24] <KevinMarks> hm
  296. # [09:33] <KevinMarks> http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html
  297. # [09:37] <hsivonen> a general problem with media files is that they are hairy and there's little expertise outside the group of actual implementors
  298. # [09:37] <hsivonen> so I wouldn't be too harsh on someone getting something wrong once in a while
  299. # [09:43] <othermaciej> it's ok to be mistaken based on lack of expertise, but not so much to be persistent about an error
  300. # [09:43] <hsivonen> sure
  301. # [09:43] <othermaciej> Silvia Pfeiffer is apparently a media expert of sorts however, per google
  302. # [09:54] <KevinMarks> OK, replied to that
  303. # [09:56] <othermaciej> wow, QuickTime vs Ogg circa 2001
  304. # [09:57] <othermaciej> KevinMarks: did you and I ever both work at Apple at the same time?
  305. # [09:57] <KevinMarks> Ogg owes more to WMV than to QT
  306. # [09:57] <KevinMarks> I was there 1998 to 2003
  307. # [09:57] <othermaciej> I started in 2001
  308. # [09:57] <othermaciej> so quite a while
  309. # [09:58] <othermaciej> I guess you must have been there when Safari came out then
  310. # [09:58] <KevinMarks> yes, though I was more on the hardcore video stuff by then
  311. # [10:01] <hsivonen> this whole thing with Ogg family vs. MPEG-4 family isn't about technical merit but about patentlessness merit.
  312. # [10:01] <hsivonen> and patentlessness trumps technical merit
  313. # [10:01] <hsivonen> as with Huffman coded JPEG vs. arithmetic coded JPEG
  314. # [10:02] <KevinMarks> thats not the level I was arguing on
  315. # [10:02] <othermaciej> we're not debating technical merit of Ogg
  316. # [10:02] <KevinMarks> well, I was
  317. # [10:02] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
  318. # [10:02] <othermaciej> oh
  319. # [10:02] <KevinMarks> Both ogg and QT can intheory include arbitrary codecs
  320. # [10:02] <othermaciej> I see your mail now
  321. # [10:03] <KevinMarks> however, QT can do it in practice too
  322. # [10:03] <hsivonen> s/patentlessness/only having RF-licensed or chronically unenforced patents/
  323. # [10:03] <KevinMarks> So QT with JPEG video and u-law audio would satisfy you?
  324. # [10:04] <hsivonen> KevinMarks: no. there has to be some level of technical suitability as well
  325. # [10:04] <othermaciej> QT isn't patentless, is it?
  326. # [10:05] <hsivonen> but sadly, royalty-free and not so efficient has to win over royalty-bearing and more efficient as the baseline format
  327. # [10:05] <othermaciej> (thought Apple has the only patents so in theory could donate them)
  328. # [10:05] <KevinMarks> the file format is as long as you leave out the pointless hint tracks
  329. # [10:05] <webben> what are hint tracks?
  330. # [10:05] <othermaciej> are there any other patents relevant to the MPEG-4 container format?
  331. # [10:06] <othermaciej> I know it is based on QT's format but no one has yet explained to me what is different
  332. # [10:06] <KevinMarks> which Singer patented, then watched Apple lawyers destroy interop by suing the 2 other server makers
  333. # [10:06] <KevinMarks> Singer can tell you
  334. # [10:06] <KevinMarks> broadly, C strings instead of P strings in several places
  335. # [10:06] <KevinMarks> and some extra headers that override the QT ones
  336. # [10:07] <hsivonen> FWIW, when Electronic Frontier Finland (EFFI, like EFF) gave recommendations about video formats for the Web, I was the principal author and the two formats we recommended were Ogg/Theora/Vorbis on licensing grounds and MP4/H.264/AAC on standard/installed base/quality combo grounds
  337. # [10:07] <othermaciej> too bad there is not one format that meets all those criteria
  338. # [10:08] <hsivonen> oh, and besides patents, there's another consideration in Theora's favor
  339. # [10:08] <KevinMarks> There is a plausible argument that Vorbis and Theora are unchallenged on licensing grounds because no-one big enough to be worth suing has adopted them
  340. # [10:08] <hsivonen> H.264 has an insane repertoire of profiles and levels
  341. # [10:08] <hsivonen> whereas with the currents impls if you say Theora, it is Theora
  342. # [10:09] <hsivonen> but QuickTime won't play all H.264
  343. # [10:09] <webben> hmm that does sound like a big advantage
  344. # [10:09] <hsivonen> and PSP and iPod play even less
  345. # [10:09] <KevinMarks> certainly when I was at Apple, my many attempts to get Vorbis into QT were rebuffed because of fears that Fraunhofer or Dolby would sue us
  346. # [10:09] <webben> keep things simple
  347. # [10:09] <hsivonen> and figuring the parameters out without it being your dayjob is *hard*
  348. # [10:09] <othermaciej> it's not that big, because you can pick a subset of H.264 profiles if you want
  349. # [10:10] <othermaciej> Simple and Advanced Simple are probably good enough
  350. # [10:10] <hsivonen> KevinMarks: the manager of Nokia's Maemo operation said that they are afraid of shipping Vorbis until their own people investigate whether there's some Fraunhofer stuff in there after all
  351. # [10:11] <webben> Maybe the key is to make sure that whatever formats we spec support for, the most obvious people who might sue should sign up to the WHATWG patent policy
  352. # [10:11] <othermaciej> people at Apple are still worried about Ogg patent risk
  353. # [10:12] <hsivonen> othermaciej: I assure you, that interoperating with QuickTime is *hard* if you don't have documented parameters that someone else has spent hours and hours testing
  354. # [10:12] <hsivonen> with e.g. x264 that is
  355. # [10:12] <othermaciej> interoperating in what way?
  356. # [10:12] <webben> othermaciej, from being sued by who?
  357. # [10:12] <othermaciej> encoding something qQuickTime can play?
  358. # [10:13] <hsivonen> othermaciej: using QuickTime as a decoder for stuff encoded using encoders that can potentially use optional features not supported by QuickTime
  359. # [10:13] <KevinMarks> who was it who submarined an mp3 patent on microsoft recently?
  360. # [10:13] <othermaciej> webben: lots of people have patents on audio/video codecs, and no one knows all the ones they exist or what they might apply to
  361. # [10:13] <hsivonen> Alcatel/Lucent
  362. # [10:14] <othermaciej> it's true that you'd have to define an H.264 profile set and not just the codec family
  363. # [10:14] <othermaciej> like 3GPP does
  364. # [10:14] <KevinMarks> see, phone companies a) have a lot of patents b) have a lot of lawyers and c) are getting desperate for revenue
  365. # [10:14] <hsivonen> I'm sorry to say, but I got a feeling like QuickTime was like the Internet Explorer of MPEG-4
  366. # [10:14] <hsivonen> when trying to interoperate, that is
  367. # [10:14] <webben> othermaciej, Well yes. I can see that. But do you mean Apple is worried about /any/ external format? Or are there special fears peculiar to Ogg?
  368. # [10:15] <KevinMarks> thats a little unfair, especially when the alternative is DiVX
  369. # [10:16] <hsivonen> KevinMarks: well, the DivX and XviD stuff is uncool in the sense that they don't use ISO packaging
  370. # [10:16] <KevinMarks> what they do with mp3 framing is particularly ugly as I recall
  371. # [10:16] <hsivonen> but anyway, the profiling and levels of H.264 are bad, bad, bad
  372. # [10:17] <KevinMarks> but yes Apple should do a better job of playing stuff back anyway
  373. # [10:17] * KevinMarks has perian installed
  374. # [10:19] <othermaciej> I would like it if a Mac could play all video formats commonly found on the web out of the box
  375. # [10:20] <webben> o/t: indeed, it would be nice if Apple could licence the Windows Media stuff and distribute OSX with all that stuff preinstalled.
  376. # [10:21] <KevinMarks> when Apple first did mpeg4 I said that it wsn't done until it played divx avi's
  377. # [10:21] <KevinMarks> however I was ignored
  378. # [10:22] <webben> it's rather weird since free *nix'es get criticized for not being desktop ready for not playing these formats as distributed.
  379. # [10:23] * Joins: ROBOd (n=robod@86.34.246.154)
  380. # [10:24] <othermaciej> wow, http://www.apple.com/quicktime/ is down
  381. # [10:24] <KevinMarks> it's up for me
  382. # [10:25] <othermaciej> it's alive now
  383. # [10:25] <othermaciej> that was weird
  384. # [10:27] <KevinMarks> akamai glitch?
  385. # [10:27] <othermaciej> could be
  386. # [10:31] <Lachy> I like Dean's idea of renaming <source> to <content>, it's a much better name
  387. # [10:32] <KevinMarks> no it isn't
  388. # [10:32] <Lachy> why not?
  389. # [10:32] <KevinMarks> content implies containment
  390. # [10:32] <KevinMarks> or happiness
  391. # [10:33] <Lachy> <content src> implies the content can be retrieved from the given location
  392. # [10:34] <othermaciej> if we have both a sequence of items and alternative items, I'd like it if the element names reflected that
  393. # [10:34] <othermaciej> if you wanted to overengineer it you could have both playlists and alternative lists which could nest each other
  394. # [10:34] <Lachy> <alt> is also better choice
  395. # [10:34] <KevinMarks> I liked your alt stuff maciej
  396. # [10:35] <Lachy> I'm not sure we need a way to markup playlists in HTML
  397. # [10:35] <KevinMarks> yes we do
  398. # [10:35] <Lachy> we have XSPF and a number of other playlist formats
  399. # [10:35] <othermaciej> some current uses of video want to play two videos in a row
  400. # [10:35] <KevinMarks> and it's called <li>
  401. # [10:36] <hsivonen> othermaciej: uses other than playing an ad from a different file first/last?
  402. # [10:36] <othermaciej> I'm not really sure <li> is good, as I suggested there, because it would render a list marker in non-<video> user agents
  403. # [10:36] <hsivonen> (though ads pay for stuff, so they are important)
  404. # [10:36] <KevinMarks> audio playlists are more common
  405. # [10:36] <othermaciej> hsivonen: first, last, between segments
  406. # [10:36] <othermaciej> it might not be needed, I dunno
  407. # [10:37] <othermaciej> but you can definitely do a smoother transition if you cue up the next item before the current one finishes
  408. # [10:37] <KevinMarks> playing ads is a crappy usecase
  409. # [10:37] <Lachy> it's a popular one though
  410. # [10:37] <othermaciej> on the one hand, kinda, on the other hand, I'd rather people play ads using HTML than using Flash
  411. # [10:37] <othermaciej> if they are going to do so anyway
  412. # [10:37] <KevinMarks> you are confusing common with popular there
  413. # [10:37] <Lachy> yes, sorry
  414. # [10:38] <KevinMarks> IE is common, Firefox is popular
  415. # [10:38] <hsivonen> :-)
  416. # [10:38] <KevinMarks> replace IE and Firefox with your own alt-cred badge of honour
  417. # [10:38] <othermaciej> well if you put it like that, I don't want to be common
  418. # [10:39] <KevinMarks> I choose my words very carefully...
  419. # [10:40] <KevinMarks> “10 percent of computer users are Mac users, but remember, we are the top 10 percent.” - Douglas Adams
  420. # [10:40] <othermaciej> hah
  421. # [10:40] <othermaciej> only the top 5 percent these days
  422. # [10:40] <othermaciej> or 6
  423. # [10:40] <othermaciej> depending on which survey you believe
  424. # [10:41] <KevinMarks> has cameo been getting to you again?
  425. # [10:41] * Joins: hendry (n=hendry@91.84.53.136)
  426. # [10:42] <KevinMarks> when we were inventing XSPF argued for it being HTML then
  427. # [10:43] <KevinMarks> Actually, i think there may be a broader use case than just playlists for a well-defined alternatives container
  428. # [10:43] <Lachy> This site uses javascript to let the user create their own play list of news videos (requires IE, sorry mac users) http://ninemsn.video.msn.com/v/en-au/v.htm
  429. # [10:44] <Lachy> it also plays an ad before the video
  430. # [10:46] <KevinMarks> You know, it's a shame Apple didn't patent popping up annoying ads up before playing the video; that would have discouraged everyone else...
  431. # [10:56] <KevinMarks> and we could then have rejected that usecase
  432. # [10:59] <KevinMarks> o O (hm, lets set up an organisation to patent things we don't want in standards)
  433. # [11:00] <othermaciej> we could call it MPEG FU
  434. # [11:03] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  435. # [11:05] <met_> whatwg.org has database problem http://forums.whatwg.org/ http://blog.whatwg.org/ doesn't work
  436. # [11:06] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
  437. # [11:06] <met_> 'mysql_connect() () Lost connection to MySQL server during query'
  438. # [11:07] <Lachy> I'm not able to lget anything, it's still trying to load
  439. # [11:08] <Lachy> the wiki is down too
  440. # [11:08] <Lachy> Hixie, yt?
  441. # [11:12] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  442. # [11:18] <annevk> I think that if you want to support SVG in <img> you probably have to support everything as image
  443. # [11:18] <annevk> including HTML, etc.
  444. # [11:19] <othermaciej> hello annevk
  445. # [11:19] <annevk> Though I think an initial implementation could do a check on the root element to just support SVG or something...
  446. # [11:19] <othermaciej> supporting svg in image opens the door to html in one way or another
  447. # [11:19] <othermaciej> but that doesn't mean you have to accept text/html
  448. # [11:20] <annevk> Well, you'd already support XHTML so supporting text/html... But yes, you wouldn't have to
  449. # [11:20] <othermaciej> even with an svg root element you can easily just fill it with a 100% by 100% foreignObject containing HTML
  450. # [11:20] <annevk> (And regarding the Document stuff. Both HTMLDocument and SVGDocument have a .title member.)
  451. # [11:21] <othermaciej> are they incompatible?
  452. # [11:21] <othermaciej> hmm
  453. # [11:21] <Lachy> hmm. it does seem like trying to turn <img> into <object>, which isn't a good idea
  454. # [11:21] <othermaciej> I guess they have different rules for where to get the title
  455. # [11:21] <othermaciej> that sucks
  456. # [11:21] <annevk> Lachy, no, you wouldn't support scripting etc. I think
  457. # [11:21] <annevk> othermaciej, I think they can be made compatible in some way
  458. # [11:22] <annevk> maybe by doing a check on the root element or something
  459. # [11:22] <Lachy> annevk, that would need to be defined. But if that is, then could <foreignObject> be ignored too?
  460. # [11:23] <Lachy> maybe the SVG working group should define a subset of SVG that UAs would need to support for use in <img> and CSS backgrounds, that excludes all the problematic stuff
  461. # [11:24] <annevk> That doesn't make sense for UAs
  462. # [11:24] <othermaciej> compatibility with HTML/CSS has not been that high on their list of priorities
  463. # [11:24] <annevk> Maybe for authors, but not for UAs
  464. # [11:24] <othermaciej> I am a member of the SVG WG now
  465. # [11:24] <annevk> Because UAs would be forced to render SVG in some different way depending on the context...
  466. # [11:24] <othermaciej> but I don't know if I will have time to make them do anything
  467. # [11:24] <Lachy> yeah, true
  468. # [11:24] <annevk> othermaciej, I saw, I hope you'll be controversial :)
  469. # [11:24] <othermaciej> olliej joined too
  470. # [11:25] <othermaciej> annevk: aren't I always?
  471. # [11:25] <annevk> :)
  472. # [11:25] <Lachy> othermaciej, if they never planned on being compatible with HTML/CSS, then how do they expect SVG to be adopted on a wide scale?
  473. # [11:25] <othermaciej> Lachy: by replacing HTML for all uses
  474. # [11:25] <Lachy> ha!
  475. # [11:26] <othermaciej> I'm slightly parodying their position
  476. # [11:26] <othermaciej> but not by much
  477. # [11:26] <annevk> They do want to replace CSS I believe for layout stuff
  478. # [11:26] <annevk> I saw some things on www-svg iirc talking about layout systems in SVG etc.
  479. # [11:27] <hsivonen> aargh. they really should focus on expressing the PDF imaging model in XML and leave it at that
  480. # [11:27] <hsivonen> I wonder if MARS has sane text/font support kludged into SVG
  481. # [11:28] <annevk> The W3C was initially against presentational formats and now they're doing it all over again with SVG...
  482. # [11:28] <annevk> Well, if they proceed with that plan anyway.
  483. # [11:28] <annevk> "SVG is the new <font>." would be my headline the day that happens.
  484. # [11:29] <hendry> annevk: nice
  485. # [11:29] <met_> Lachy database on whatwg.org works now
  486. # [11:31] <othermaciej> SVG already has text/font support kludged into itself
  487. # [11:31] <othermaciej> doesn't need any additiona kludging
  488. # [11:35] <annevk> Oh right, SVG fonts...
  489. # [11:35] <hsivonen> othermaciej: the problem with SVG's text is that it is the worst of both worlds (both being CSS and PDF)
  490. # [11:35] <hsivonen> othermaciej: no interop
  491. # [11:35] <hsivonen> othermaciej: OTOH, the PDF approach is actually interoperably implementable
  492. # [11:35] <annevk> Maybe we should introduce scripted fonts by means of a <canvas-font> element
  493. # [11:36] <othermaciej> hsivonen: unless you define all your own fonts in SVG!
  494. # [11:36] * annevk wonders if a <script> can mutate the font on the fly
  495. # [11:36] <othermaciej> I agree though, SVG text is not so great
  496. # [11:36] <annevk> in SVG
  497. # [11:36] <othermaciej> annevk: that depends on if their spec carefully defined the conformance requirements for dynamic updating
  498. # [11:36] <othermaciej> what do you think the odds of that are?
  499. # [11:37] <hsivonen> othermaciej: I thought SVG fonts are not per-glyph positioned by the generator but the interglyph layout is still left to the renderer
  500. # [11:39] <othermaciej> hsivonen: you define the glyphs, advances and kerning pairs, not sure what freedom that leaves to the renderer
  501. # [11:39] <hsivonen> with all the CTL stuff these days, there are two approaches that work for text in graphics: 1) standardising on the binary blob renderer implementation or 2) the generator sending an array of glyphs and the exact glyph positions
  502. # [11:40] <hsivonen> #1 doesn't work, because none of Microsoft, Apple and Adobe wants to freeze their renderer and share the source
  503. # [11:40] <othermaciej> I'm happy that in HTML you get to compete on text rendering quality
  504. # [11:40] <hsivonen> it works for HTML
  505. # [11:41] <hsivonen> but not for graphics where the text layout and the graphics need to coincide
  506. # [11:41] <othermaciej> I haven't actually seen an SVG where it is a practical problem
  507. # [11:41] <othermaciej> but I guess textArea is new and more potentially problematic
  508. # [11:41] <hsivonen> I have
  509. # [11:41] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  510. # [11:41] <hsivonen> Jacques Distler has use cases as usual
  511. # [11:41] <othermaciej> SVG does let you individually position each glyph if you want
  512. # [11:42] <hsivonen> also, in the summer, I tried to publish a diagram as SVG myself
  513. # [11:42] <othermaciej> although you can't control the rasterization of the glyphs (unless you are using an SVG font, and even then, only to the extent that path rendering is defined)
  514. # [11:42] <hsivonen> the only way to get sane results would have been converting text to paths
  515. # [11:43] <othermaciej> surprisingly, the SVG spec is not precise enough to tell you what bitmap results from displaying a particular SVG file at a particular size, even without any text involved
  516. # [11:43] <hsivonen> othermaciej: is it just antialiasing or something bigger?
  517. # [11:43] <hsivonen> bézier tesselation?
  518. # [11:44] <othermaciej> antialiasing and filters are two of the obvious issues
  519. # [11:44] <hsivonen> I'd expect implementations to want to be able to compete on anti-aliasing implementation details and performance
  520. # [11:45] <met_> annevk, do you know why <input type="number"> is different in Opera on Mac than on PC? On Mac it is missing the buttons Up/Down
  521. # [11:45] <othermaciej> method of scaling embedded raster images also not defined
  522. # [11:45] * moeffju[ZzZz] is now known as moeffju
  523. # [11:46] <annevk> met_, no
  524. # [11:47] <met_> annevk, just making some examples of WF2 and found this difference
  525. # [11:47] <met_> annevk, same for <input type="time">
  526. # [11:48] <annevk> maybe it's because on the Mac we're tied to native widgets or something?
  527. # [11:48] <annevk> I haven't done much UI testing
  528. # [11:48] <othermaciej> it's weird to me that WF2 has so many date/time controls and none for credit cards
  529. # [11:49] <met_> it's the only lack I have found
  530. # [11:49] <annevk> Actually, most of what we did went into technical testing
  531. # [11:49] <othermaciej> I know which I've had to input more times into web forms
  532. # [11:49] <webben> othermaciej, hmm ... but don't CC formats differ
  533. # [11:49] <webben> (e.g. codes on the back, expiry dates, start dates etc)
  534. # [11:50] <webben> and might they not change even more in the future?
  535. # [11:50] <Lachy> met_, I get the up/down buttons in Opera on Mac
  536. # [11:50] <annevk> I think those are pretty standard at the moment
  537. # [11:50] <met_> Lachy, what Opera version?
  538. # [11:50] <othermaciej> yes, most credit card inputs have at least three bits, the actual number, the security code, and the expiration date
  539. # [11:50] <annevk> otherwise I wouldn't be able to use my credit card accross the globe...
  540. # [11:51] <Lachy> credit cards are handled with <input type=text pattern=...>
  541. # [11:51] <annevk> Lachy, that doesn't help with auto-input by the UA
  542. # [11:51] <othermaciej> how does that let the UA put up a list of my credit cards instead of a text field?
  543. # [11:51] <Lachy> fine, <input role="credit-card"> ;-)
  544. # [11:51] <annevk> <input type=cc>
  545. # [11:51] <hsivonen> Lachy: hey, don't reinvent the eCom RFC!
  546. # [11:52] <annevk> prolly eCom could be used I suppose
  547. # [11:52] <annevk> giving meaning to name attribute values...
  548. # [11:52] <hsivonen> RFC 3106
  549. # [11:53] <Lachy> oh, sure, that RFC has been a huge success in the real world!
  550. # [11:53] <hsivonen> immense
  551. # [11:53] <Lachy> oh, </sarcasm>
  552. # [11:53] <webben> why has it failed?
  553. # [11:53] <annevk> Opera supports it iirc
  554. # [11:53] <Lachy> webben, do you know of any sites that use it?
  555. # [11:54] <annevk> I believe sites use it too, not entirely sure which though
  556. # [11:54] <webben> Lachy, No, I don't mean "hasn't it succeeded?" I mean /why/ has it failed.
  557. # [11:54] <hsivonen> webben: few people know about it. and the names are really ugly and non-obvious too
  558. # [11:55] <hsivonen> this one of those namespacing things
  559. # [11:55] <webben> one could solve problem 1 be mentioning it on the WHATWG microformat wiki
  560. # [11:55] <Lachy> I think microformats should come up with a way of identifying specific form semantics
  561. # [11:55] <hsivonen> can't standardize name='creditcard' because someone might use that field name for telephone numbers
  562. # [11:55] <webben> the namespacing seems non-problematic but the inconsistency is annoying: Ecom_BillTo_Postal_CountryCode
  563. # [11:55] <othermaciej> using class would be better than name
  564. # [11:55] <webben> note the weird use of underscores
  565. # [11:56] <othermaciej> you also want to relate the different controls that are related to one credit card
  566. # [11:56] <annevk> in that case we might as well use the type attribute
  567. # [11:56] <othermaciej> but <input type="something"> seems better when you may want a custom control though
  568. # [11:56] <othermaciej> having a non-heuristic way to identify related username and password fields on login and registration forms would be cool too
  569. # [11:56] <webben> a custom control that does what?
  570. # [11:57] <annevk> enables semantics the UA can use
  571. # [11:57] <annevk> for input and validation
  572. # [11:57] <othermaciej> the UA might be able to store your credit cards in secure storage
  573. # [11:57] <othermaciej> like the Keychain on Mac OS X
  574. # [11:57] <othermaciej> and let you pick one
  575. # [11:58] <othermaciej> instead of making you type
  576. # [11:58] <webben> oh i thought you meant a widget that looks different
  577. # [11:59] <webben> you'd still want additional fields for the other bit of the credit card
  578. # [11:59] <webben> so we really mean "creditcardnumber"
  579. # [11:59] <othermaciej> it might look different too, who knows
  580. # [11:59] <annevk> it doesn't really matter how you call it
  581. # [12:00] <othermaciej> anyway, now's not the time to make such suggestions
  582. # [12:00] <annevk> expiry date is <input type=month>
  583. # [12:00] <annevk> not sure about the three digit number, maybe <input type=password>
  584. # [12:00] <othermaciej> you would want to link it to the credit card number
  585. # [12:01] <webben> the problem is really that you need different sets of data for different cc's
  586. # [12:01] <othermaciej> field
  587. # [12:01] <othermaciej> so when you pick a credit card it can fill all three
  588. # [12:01] <othermaciej> (maybe not the 3-digit code, for security reasons)
  589. # [12:01] <annevk> that could be done through some extension i suppose
  590. # [12:01] <othermaciej> anyway if I were really proposing it I would work it out in more detail
  591. # [12:01] <webben> if we want fields linked together a microformat seems the way to go
  592. # [12:01] <annevk> there have been some suggestions for grouped fields
  593. # [12:02] <othermaciej> webben: you want them to be linked w/o constraining markup containership
  594. # [12:02] <othermaciej> microformats are bad at that, since there's no widely applicable HTML attribute that accepts an id of a related element
  595. # [12:03] <hsivonen> sadly, so far, rel='license' and XFN are the only microformats that are approachable without a longtime investment in gathering tacit knowledge inside the microformats community
  596. # [12:03] <annevk> yeah, too bad
  597. # [12:03] <webben> othermaciej, what's the usecase for not containing these controls in the same fieldset?
  598. # [12:03] <othermaciej> I wish they would write specs with meaningful conformance requirements and such
  599. # [12:04] * hsivonen too
  600. # [12:04] <met_> Lachy, just upgraded Opera to last weekly build and Up/Down are here, thanks
  601. # [12:04] <webben> well, one could make such specs a requirement for registering microformats with the WHATWG wiki
  602. # [12:04] <annevk> oh ok
  603. # [12:04] <annevk> cool
  604. # [12:04] <webben> and provide a spec template
  605. # [12:04] <annevk> prolly was a known issue then :)
  606. # [12:05] <hsivonen> webben: I think the microformats spec template is part of the problem
  607. # [12:05] <hsivonen> webben: usually the frustration comes when you take away the boilerplate and see what is left
  608. # [12:05] <webben> hsivonen, Do you mean a) having a template is bad; or b) that template is bad?
  609. # [12:06] <hsivonen> webben: the microformats wiki template is
  610. # [12:06] <hendry> cd
  611. # [12:06] <hendry> woops, wrong terminal
  612. # [12:06] <webben> well, WHATWG could improve on it
  613. # [12:06] <webben> maybe one could also require a conformance checker?
  614. # [12:07] <Lachy> microformats have a spec template?
  615. # [12:07] <hsivonen> webben: haha. good luck with that.
  616. # [12:08] <webben> hsivonen, Or, alternatively, maybe require an implemented reader for that format?
  617. # [12:09] <webben> (of course that works better for data formats than humanities ones)
  618. # [12:09] <hsivonen> webben: I specifically made sure I don't promise anyone that I'd implement an hCard or hCal checker, because I couldn't figure out what the conformance requirements are
  619. # [12:09] <hsivonen> webben: not good enough
  620. # [12:09] <hsivonen> webben: hint: RSS
  621. # [12:09] <Lachy> hsivonen, there aren't any conformance criteria.
  622. # [12:09] * webben doesn't get the hint
  623. # [12:09] <hsivonen> Lachy: whoo! implementation done :-)
  624. # [12:10] <hsivonen> webben: do with RSS whatever Radio Userland does is not good enough
  625. # [12:10] <Lachy> microformats seem to just describe what class names can be used with vague descriptions of their meaning, not specify how they should be used
  626. # [12:10] <webben> ah I see
  627. # [12:10] <Lachy> it's like XHTML2!
  628. # [12:11] <webben> well, HTML5 is also wary of telling agents what to do.
  629. # [12:11] <Lachy> HTML5 has very specific processing requirements
  630. # [12:11] <webben> for parsing, sure
  631. # [12:11] <Lachy> it doesn't define things like specific UIs
  632. # [12:11] <webben> doesn't XML have specific processing requirements in that sense too?
  633. # [12:12] <annevk> webben, it defines specific processing requirements for all things
  634. # [12:12] <annevk> not just parsing
  635. # [12:12] <webben> i'm not sure what we mean by "processing" here
  636. # [12:12] <annevk> At least, to me it's clear what Opera should implement (unless a part of the spec is not done)
  637. # [12:13] <hsivonen> webben: XML doesn't spec tree construction from the parse. it is implied
  638. # [12:14] <annevk> (and if it's unclear I mostly e-mail the list, although that's not the sole reason I e-mail the list)
  639. # [12:14] <webben> well, i suppose two things would be very useful with a microformat spec: define what fields must be present + suggest default styles (if any) for all currently speced CSS media types
  640. # [12:15] <webben> much the same as with HTML elements
  641. # [12:15] <annevk> that doesn't help much
  642. # [12:15] <annevk> it needs to define what happens when things are in error too
  643. # [12:16] <annevk> or when not all required fields are present, etc.
  644. # [12:16] <webben> hmm ... that's true
  645. # [12:16] <webben> well, one can't really extract data if not all required fields are present
  646. # [12:17] <annevk> that doesn't negate my argument
  647. # [12:18] <webben> you mean the spec needs to say whether to display the content or display an error?
  648. # [12:18] <webben> one could define a sane default for microformat treatment
  649. # [12:18] <webben> or maybe for unrecognized microformats
  650. # [12:19] <webben> and include erroneous ones in that treatment
  651. # [12:19] <webben> that would reduce the burden on spec creators
  652. # [12:20] <annevk> errors are almost the wrong solution (except in script)
  653. # [12:20] <annevk> read the HTML5 spec for an idea of what it could say
  654. # [12:24] * Joins: bzed (n=bzed@dslb-084-059-111-244.pools.arcor-ip.net)
  655. # [12:25] <webben> well, should WHATWG require such definitions for wiki inclusion?
  656. # [12:25] <annevk> the wiki stuff is just an experiment at this point
  657. # [12:26] <annevk> HTML5 itself doesn't even define what happens with competing class values
  658. # [12:39] * othermaciej is now known as om_sleep
  659. # [12:40] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
  660. # [13:14] * Joins: ROBOd (n=robod@86.34.246.154)
  661. # [13:20] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  662. # [13:20] <annevk> apparently we're old school: http://natalian.org/archives/2007/03/23/invasion-of-the-invited-experts/
  663. # [13:22] <Lachy> heh
  664. # [13:23] <annevk> for a bunch of students who weren't around when HTML4 evolved that's quite funny
  665. # [13:24] <Lachy> I started getting into the web around the time HTML4 came out, so I'm kind of old school, but not really old
  666. # [13:27] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  667. # [13:50] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  668. # [14:05] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
  669. # [14:14] * Joins: nickshanks (n=nicholas@home.nickshanks.com)
  670. # [14:15] * Quits: nickshanks (n=nicholas@home.nickshanks.com) (Remote closed the connection)
  671. # [14:23] * Quits: amethyyst (i=amethyst@66.252.28.22) (Read error: 110 (Connection timed out))
  672. # [14:59] * Joins: zcorpan (n=zcorpan@84-216-42-245.sprayadsl.telenor.se)
  673. # [15:36] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  674. # [15:37] * Joins: mw22____________ (n=chatzill@cc1057475-a.odz1.ov.home.nl)
  675. # [15:45] * Joins: nickshanks (n=nicholas@home.nickshanks.com)
  676. # [15:53] * Quits: mw22 (n=chatzill@cc1057475-a.odz1.ov.home.nl) (Read error: 110 (Connection timed out))
  677. # [15:56] * Quits: mw22____________ (n=chatzill@cc1057475-a.odz1.ov.home.nl) (Read error: 110 (Connection timed out))
  678. # [16:11] * Joins: mw22____________ (n=chatzill@cc1057475-a.odz1.ov.home.nl)
  679. # [16:11] * mw22____________ is now known as mw22
  680. # [16:23] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  681. # [16:25] * Quits: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com)
  682. # [16:28] * Joins: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com)
  683. # [17:22] * Joins: annevk2 (n=annevk@5352CE6F.cable.casema.nl)
  684. # [17:24] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  685. # [17:24] * Quits: annevk (n=annevk@5352CE6F.cable.casema.nl) (Read error: 110 (Connection timed out))
  686. # [17:44] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  687. # [17:48] * Quits: zcorpan (n=zcorpan@84-216-42-245.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  688. # [18:19] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  689. # [18:20] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) (Client Quit)
  690. # [18:20] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  691. # [18:22] * annevk2 wonders how error handling works for <img> with APNG...
  692. # [18:22] * annevk2 is now known as annevk
  693. # [18:24] <annevk> as in, what would it do for the error event and how would it effect .complete
  694. # [18:24] <Dashiva> For UAs that don't support it?
  695. # [18:25] <annevk> the APNG spec itself is pretty vague about the subject: http://wiki.mozilla.org/APNG_Specification#Error_Handling
  696. # [18:25] <annevk> Dashiva, that's prolly clear
  697. # [18:25] <annevk> but not really relevant as I'd expect all UAs to adopt this
  698. # [18:26] <Dashiva> APNG looks like a regular PNG with lots of trash data to non-supporting ones, as I understand it
  699. # [18:27] <Dashiva> So you're thinking it errors during the animation, and how the UA should handle that?
  700. # [18:27] <annevk> yes
  701. # [18:28] <Dashiva> As I see it, the apng spec defines internal error handling: display the default image if animation fails. Displaying the default image is then displaying the APNG according to spec, and not an error as far as the document is concerned
  702. # [18:41] <Dashiva> Hm, nobody replied to the call for a versioning doctype on public-html. Remarkable restraint :)
  703. # [18:42] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  704. # [18:43] <gsnedders> Dashiva: there are issues with what he says anyway… he talks about a SGML dialect of HTML5, and seeming we're not writing a delta spec…
  705. # [18:54] * Joins: zcorpan (n=zcorpan@84-216-42-245.sprayadsl.telenor.se)
  706. # [19:05] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  707. # [19:05] <annevk> versioning is silly on the web
  708. # [19:07] <annevk> as such, i don't want to get into silly versioning debates every other week
  709. # [19:07] * annevk wonders whether the guy who posted actually knows why doctypes are useful himself - as they're not
  710. # [19:07] <Lachy> oh gosh, the abbr vs. acronym debate has started on www-html now too!
  711. # [19:08] * annevk isn't subscribed to www-html anymore
  712. # [19:08] * Joins: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  713. # [19:09] <Lachy> it's not too high volume, sometimes it's entertaining to see what the XHTML2 WG are up to
  714. # [19:09] <annevk> oh, I do read it
  715. # [19:09] <annevk> well, the threads with interesting titles
  716. # [19:10] <annevk> XHTML2 is better followed on w3c-html-wg (member only) though and soonish on public-xhtml2 I suppose
  717. # [19:10] <Lachy> ah, well I'll have to subscribe to that one when I get access
  718. # [19:11] <annevk> you can't, but you can download the mboxes or read it through the online interface
  719. # [19:11] <Lachy> mboxes?
  720. # [19:12] <annevk> http://lists.w3.org/Archives/Public/public-html/mboxes/ for instance
  721. # [19:12] <Lachy> oh, I see. that's member only too
  722. # [19:12] <annevk> interesting
  723. # [19:13] <annevk> the URI architecture of the W3C site is confusing
  724. # [19:13] <annevk> it's cool in the sense that they actually keep them all working, but still...
  725. # [19:14] <Lachy> yeah, that's cool, though some of the really old ones are dead
  726. # [19:15] <annevk> gsnedders, http://php-html5lib.dashslot.net/trac/browser/trunk/src requires silly access to view the source code...
  727. # [19:15] <annevk> gsnedders, "FILE_VIEW privileges are required to perform this operation"
  728. # [19:15] <annevk> (the files in that directory, I mean)
  729. # [19:16] <gsnedders> annevk: work now?
  730. # [19:17] <annevk> gsnedders, yeah, cool
  731. # [19:24] <Dashiva> Hixie is a rather cunning fellow
  732. # [19:25] <Dashiva> Shooting my poor little green guys by blending into the darkness
  733. # [19:25] <met_> http://glazman.org/weblog/dotclear/index.php?2007/03/24/3375-html-wg-fun
  734. # [19:26] <annevk> help
  735. # [19:27] <annevk> oh well :)
  736. # [19:27] <Dashiva> I don't get which part of it is the fun
  737. # [19:28] <Lachy> Dashiva, I downloaded that game earlier to try it out. He told me about it once before, but never actually tried it
  738. # [19:28] <Lachy> I'm still trying to learn the rules
  739. # [19:29] <Dashiva> I've got the rules down, I'm working on how to play
  740. # [19:29] <Dashiva> In my first game, I focused too much on surviving, but you don't get any points for that...
  741. # [19:31] * aroben is now known as aroben|brb
  742. # [19:38] * annevk wonders why <audio> doesn't request Ogg Vorbis to be supported
  743. # [19:41] <Lachy> Dashiva, did you play against the computer first, or against real people?
  744. # [19:41] <Lachy> annevk, Vorbis is already a SHOULD requirement for video, there's no need to state it again for audio
  745. # [19:42] * annevk doesn't think that's obvious
  746. # [19:44] * Joins: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  747. # [19:45] * Quits: aroben|brb (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  748. # [19:48] <Dashiva> Lachy, annevk: Hixie said he was taking up the shared media interface apple's suggestion had. Could Vorbis be associated with that one, maybe?
  749. # [19:48] <annevk> he already did
  750. # [19:48] <annevk> and yes, I suppose...
  751. # [19:50] <Dashiva> Lachy: I did the tutorial, then a game with the guy who keeps putting up "play this if you're a newbie" challenges
  752. # [19:51] <Lachy> I only played the first level against the computer
  753. # [19:51] <Lachy> are you sure it wasn't Hixie you played against? He said he was looking for newbies
  754. # [19:53] <Dashiva> Yeah, it's Wolff's Flying Tigers doing it
  755. # [19:56] * Quits: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net) (Remote closed the connection)
  756. # [19:57] * Joins: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  757. # [20:34] * Joins: briansuda (n=briansud@dsl-219-147.hive.is)
  758. # [20:52] * moeffju is now known as moeffju[Away]
  759. # [20:54] * Quits: dolphinling (n=chatzill@155.42.85.193) ("pong timeout")
  760. # [20:56] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  761. # [21:01] * Quits: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  762. # [21:03] * Joins: gilles_drieu_ (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  763. # [21:03] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  764. # [21:18] * Quits: gilles_drieu_ (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  765. # [21:32] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  766. # [21:51] * om_sleep is now known as othermaciej
  767. # [21:59] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  768. # [22:00] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  769. # [22:00] * annevk sort of agrees with <html version=5> for validation purposes
  770. # [22:00] <annevk> otherwise it seems quite pointless
  771. # [22:01] <annevk> but even validation evolves...
  772. # [22:04] <othermaciej> when HTML6 comes out, even if it's 100% compatible, it won't be the case that valid HTML6 is valid HTML5 if it adds anything at all
  773. # [22:04] <othermaciej> so I guess I agree there
  774. # [22:06] <Dashiva> The main use I see for versioning is archaeology, if someone decides they want to parse an archaic HTML 3.2 document 50 years from now
  775. # [22:07] <Dashiva> For practical use, I don't see any browsers keeping parsers for older versions around
  776. # [22:09] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  777. # [22:09] <othermaciej> browsers don't currently have parsers for older versions
  778. # [22:10] * Joins: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  779. # [22:10] * Quits: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  780. # [22:11] * Joins: aroben (n=adamrobe@adsl-70-132-25-127.dsl.snfc21.sbcglobal.net)
  781. # [22:26] <hsivonen> aargh. versioning again and conformance checking as an excuse
  782. # [22:26] <hsivonen> I guess I should say something after a night's rest
  783. # [22:27] <othermaciej> sorry to feed the flames, I just don't actually get entirely why not versioning is good
  784. # [22:27] <othermaciej> to be fair, other people also raised profiling as an excuse
  785. # [22:28] <hsivonen> othermaciej: if HTML6 is so badly designed that *it* needs to be distinguished from HTML5, then HTML6 should have a version flag. HTML5 shouldn't pre-emptively
  786. # [22:28] * Joins: jkj2 (n=jirka@adsl-lib146-121-244-84.bluetone.cz)
  787. # [22:29] <hsivonen> and when HTML6 is out, authors should check new documents against it
  788. # [22:29] <othermaciej> hsivonen: I'm not sure it would be bad design - if any new elements or attributes are added, or the content model of any element is made looser, then you can't check an HTML6 document against an HTML5 checker
  789. # [22:29] <hsivonen> so if someone wants to deliberately check against HTML5 once HTML6 is current, it is reasonable to make them jump though a pop-up menu hoop
  790. # [22:30] <othermaciej> if it also deprecates HTML5 elements or attributes then vice versa would apply
  791. # [22:30] <hsivonen> othermaciej: well, the checkers would have to be updated to be HTML6 checkers once HTML6 is out
  792. # [22:30] <gsnedders> how many people here validate against HTML 3.2?
  793. # [22:30] <othermaciej> can we promise that all valid HTML 5 will remain valid HTML n for all future values of n?
  794. # [22:31] <jkj2> Hi, specifying version is especially important for HTML/XHTML editing tools, not for validation
  795. # [22:31] <hsivonen> if there's a good reason to deprecate something in HTML6, surely the burden of choosing something from an override pop-up should be on those who insist on using the deprecated stuff?
  796. # [22:31] <gsnedders> I think we mark something as a different version when there is need, when it isn't backwards compatible. HTML5 is backwards compatible, so there is no issue
  797. # [22:31] <othermaciej> gsnedders: HTML 4 is itself 10 years old
  798. # [22:31] <gsnedders> othermaciej: I'm well aware
  799. # [22:32] <othermaciej> I don't think versioning is very important, just not sure how people expect this to work with validation
  800. # [22:32] <hsivonen> jkj2: assuming that you want to artificially limit your authoring tool to a subset of what the authoring tool can support
  801. # [22:32] <othermaciej> "choose from a pop-up" or "link to a different validator url" seems reasonable
  802. # [22:32] <gsnedders> I think it's not enough just for validation
  803. # [22:32] <othermaciej> I can't believe it's 10 years old
  804. # [22:33] * Quits: briansuda (n=briansud@dsl-219-147.hive.is)
  805. # [22:33] <gsnedders> it's a problem for the validator, to allow validating against an obsolete spec, how you add a UI
  806. # [22:33] <othermaciej> no new HTML standard for a decade
  807. # [22:33] <gsnedders> 10 years seems so long for me… but I'm only 14 years old :P
  808. # [22:33] <hsivonen> jkj2: as far as the editor use case goes, the discussion reduces to the RELAX NG schema PI discussion
  809. # [22:34] <hsivonen> I think (X)HTML5 should not limit what PI you put on top to give guidance to your editor
  810. # [22:35] <gsnedders> why does it matter that much for the editor anyway?
  811. # [22:35] <gsnedders> how is the editor different from any other UA?
  812. # [22:35] <jkj2> hsivonen: if you are using some variant/version of HTML -- for example subset known to work on mobile devices or in your company CMS -- you want your editor to not to generate "unsupported" markup
  813. # [22:35] <hsivonen> gsnedders: suppose you have a CMS that bans you from including forms and you want to configure your editor to remove form features from the auto-complete options
  814. # [22:36] <hsivonen> jkj2: right. but that's the PI discussion. and I think the (X)HTML5 spec should neither forbid nor require such a PI
  815. # [22:36] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  816. # [22:37] <hsivonen> jkj2: BTW, I think the CMS case is legitimate but mobile profiles are a no-no in the WHATWG philosophy
  817. # [22:39] <jkj2> hsivonen: PI is not solution, because it links to particular schema. Schema selection should be possible to do in indirect way. Namespace + @version is good enough. NVDL can already assign schema based on namespace, and it is likely it will be extended to support namespace + attribute value dispatching.
  818. # [22:40] <hsivonen> jkj2: would you allow user-defined values in the version attribute, then?
  819. # [22:40] <hsivonen> version='foobar-cms-subset'
  820. # [22:40] <jkj2> hsivonen: I suppose that WHATWG and W3C philosophies will be merged somehow (if this is even possible) in HTML-WG
  821. # [22:40] <hsivonen> a priori prescribed modules and version subsets don't work
  822. # [22:40] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  823. # [22:40] * annevk would be entirely fine with having no versioning whatsoever
  824. # [22:40] * Joins: tantek (n=tantek@c-67-174-230-58.hsd1.ca.comcast.net)
  825. # [22:41] <hsivonen> if someone wants to subset XHTML5 in a non-prescribed way, they will
  826. # [22:41] <jkj2> sure, something like http://www.docbook.org/tdg5/en/html/ch05.html#s-notdocbook
  827. # [22:41] * annevk was previously convinced validation was a usecase (when CSS2 versus CSS2.1 was debated iirc)
  828. # [22:41] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  829. # [22:41] <hsivonen> enumerating permitted subsets normatively in advance is pointless
  830. # [22:42] <annevk> I'm not sure what the use of normative profiles is anyway
  831. # [22:42] <hsivonen> precedent: XHTML Mobile Profile does not follow the Modularization module boundaries but does its own thing
  832. # [22:42] <jkj2> I'm not enumarating anything. There should be just same basic syntax for content of version attribute
  833. # [22:42] <jkj2> s/same/some/
  834. # [22:43] <hsivonen> jkj2: so this version attribute vs. a PI between you and your editor is about whan NVDL can dispatch on?
  835. # [22:43] * annevk is convinced that we don't need to worry about versioning until HTML6 and that even then it's unlikely to be an issue
  836. # [22:44] <annevk> (as it would just point out a problem with HTML5 if there was a usecase)
  837. # [22:44] <jkj2> annevk: you are forgetting about XHTML serialization, aren't you?
  838. # [22:44] <annevk> no
  839. # [22:44] <annevk> that's handled by the namespace
  840. # [22:45] <jkj2> You expect that XHTML5 will have different namespace then XHTML 1?
  841. # [22:45] <annevk> no
  842. # [22:45] <annevk> XHTML1 still requires some silly DOCTYPE
  843. # [22:45] <annevk> so if you really want to distinguish that should be possible
  844. # [22:45] <jkj2> So, how you will recognize XHTML 1 from XHTML 5?
  845. # [22:45] <hsivonen> jkj2: a browser doesn't need to.
  846. # [22:45] <annevk> is this about browsers?
  847. # [22:46] <jkj2> I'm not talking about browser, browser doesn't take care.
  848. # [22:46] * annevk thought we already agreed that versioning is only relevant for conformance checkers (if it's relevant)
  849. # [22:46] <hsivonen> jkj2: an online conformance checker in the common case should be able to assume XHTML5 (unless the user manually overrides), because an online checker is an authoring aid and new authoring should use XHTML5 once it is out
  850. # [22:46] <jkj2> annevk: and content creation tools
  851. # [22:47] <annevk> content creation doesn't need to care about versions
  852. # [22:47] <hsivonen> jkj2: with content creation tools, you'd use a tool-specific PI if the tool wants to see one
  853. # [22:47] <annevk> it should just create content that fits the target audience
  854. # [22:47] <annevk> anyway, got to go
  855. # [22:47] <jkj2> hsivonen: so if I will use three different tools in my toolchain I will use 3 different PIs? Cool
  856. # [22:48] <jkj2> hsivonen: Moreover PIs doesn't survive SOAP transport
  857. # [22:49] <hsivonen> jkj2: I'd be willing to consider an authoring toolchain that includes SOAP transport badly astronauted
  858. # [22:50] <hsivonen> jkj2: and assuming a single PI or a single attribute without a priori enumerated subset names, your three tools will have to know about your particular subset name
  859. # [22:51] <jkj2> hsivonen: I'm also not big fan of WS stuff, but you would be surprised what you can see at various customer sites :-(
  860. # [22:52] <jkj2> hsivonen: sure, good tool has means of specifying which schema should be used depending on combination od namespace + root element name + attribute value + ...
  861. # [22:52] * Quits: zcorpan (n=zcorpan@84-216-42-245.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  862. # [22:53] <hsivonen> jkj2: I am less opposed to an optional attribute with user-specified content for the benefit of the users tool chain. I am more opposed to <html version='5'> as a normative requirement or as a solution to a perceived non-problem.
  863. # [22:54] <hsivonen> s/users/user's/
  864. # [22:54] <Dashiva> Putting the versioning in the document rather than the editor seems backwards to me. The versioning can only work if the editor supports the given version, which means the editor should be the place to choose a version
  865. # [22:54] <hsivonen> Dashiva: I also consider polluting the document instance with this stuff ugly
  866. # [22:55] <Dashiva> Hello dreamweaver
  867. # [22:58] <jkj2> Ugly, backwards -- ok, but many XML based languages specify its version and it works well
  868. # [23:00] <hsivonen> works well for what? for schema binding in editors?
  869. # [23:01] <jkj2> also, but mainly for language evolution (e.g. XSLT 1.0 & 2.0, XSL-FO 1.0 & 1.1)
  870. # [23:02] <hsivonen> I am not familiar enough with the version differences on those cases
  871. # [23:03] <hsivonen> are XSLT transformers expected to change their treatment of particularly named elements depending on what version was declared on the root element?
  872. # [23:04] <hsivonen> that is, will an XSLT 1.0 transformation execute wrongly on a transformer that implements 2.0 semantics?
  873. # [23:04] <hasather> hsivonen: I think so, yes, but I can't remember exactly
  874. # [23:04] <hsivonen> (I think I've see warnings to that effect in SAXON 8, but I don't remember the details)
  875. # [23:05] <hsivonen> hasather: strikes me as bad design of the new version then (on the face of it without knowing what was changed)
  876. # [23:05] <jkj2> XSLT 2.0 implementation will process XSLT 1.0 stylesheet in backward compatibility mode, which is 99,999999999% same as XSLT 1.0 processing
  877. # [23:05] <hsivonen> jkj2: why couldn't the last corner cases be made compatible and versioning trashed?
  878. # [23:06] * Quits: annevk (n=annevk@5352CE6F.cable.casema.nl) (Read error: 110 (Connection timed out))
  879. # [23:06] <jkj2> complex problems doesn't always have simple solutions
  880. # [23:08] <hsivonen> well, if the quirks mode has taught us anything about this issue with HTML, the conclusion should not be that more versioned modes are the solution. the conclusion should be that future versions of HTML and CSS must not make changes that are incompatible with real legacy content
  881. # [23:09] <jkj2> In HTML this is not as big problem, because HTML it is expected that unknown elements are ignored. And in case of semantics change, namespace should be changed.
  882. # [23:10] <hsivonen> or, rather, the element names, because boiling the whole language is bad
  883. # [23:10] <hasather> hsivonen: yea, that would've been bad design, but I might have been wrong about that
  884. # [23:10] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  885. # [23:10] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net) (Client Quit)
  886. # [23:11] <met_> XSLT history is much cleaner than HTML big chaos, not sure if HTML can go near it anyway
  887. # [23:11] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  888. # [23:11] <jkj2> met: you can't change history, of course, but you can prepare for future ;-)
  889. # [23:11] <hsivonen> oh, and SAXON 8 is evidence that versioning does not work with XSLT
  890. # [23:12] <jkj2> hsivonen: could you explain?
  891. # [23:12] <Dashiva> Has there been any discussion about adding crypto stuff to the spec, specifically some kind of common hash algorithm?
  892. # [23:12] <hsivonen> since SAXON 8 does not support both XSLT 1.0 and 2.0 but just says that it uses the 2.0 semantics and its your problem if you rely on 1.0 semantics
  893. # [23:12] <hsivonen> jkj2: so basically, XSLT versioning goes hand in hand with SAXON versioning
  894. # [23:13] <hsivonen> jkj2: if you want XSLT 1.0, you should use SAXON 6. if you want XSLT 2.0, you should use SAXON 8
  895. # [23:13] <hsivonen> but SAXON 8 appers not to do semantic switching on the version
  896. # [23:14] <met_> hsivonen, don't you mean XSLT 1.1 ?
  897. # [23:14] <hsivonen> met_: well, something like that. I looked at this stuff in November
  898. # [23:15] <met_> hsivonen, Saxon > 6 dropped XSLT 1.1, not XSLT 1.0
  899. # [23:15] <hsivonen> oh
  900. # [23:15] <met_> XSLT was not finished draft, part of history wich was dropped
  901. # [23:15] <hsivonen> well, my point stands that XSLT versioning is not a success of switching on a version attribute
  902. # [23:15] <jkj2> You use Saxon8 also on XSLT 1.0 stylesheets. You can even mix and match stylesheets modules in XSLT 1.0 and 2.0 together.
  903. # [23:16] <met_> met_ correction: XSLT *1.1* was draft
  904. # [23:17] <jkj2> hsivonen: you should compare with XSL-FO rather. It's usage is much more closer to HTML. (Some even think that it could replace HTML ;-D)
  905. # [23:17] * met_ do not think this way 8-)
  906. # [23:18] <hsivonen> well, either XSLT doesn't really need versioning, because the versions are compatible. or the versioning story is broken because SAXON tells me it doesn't guarantee that old semantics work. either way, not a versioning success.
  907. # [23:18] <hasather> hsivonen: the versions aren't compatible
  908. # [23:18] <hsivonen> jkj2: XSL-FO is also a no-no in WHATWG philosophy :-)
  909. # [23:19] <hasather> hsivonen: but you can use backwards compatible mode
  910. # [23:19] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  911. # [23:19] <hasather> btw, XPath may be incompatible even in backwards compatible mode, see http://www.w3.org/TR/xpath20/#id-incompat-in-true-mode
  912. # [23:19] * Joins: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net)
  913. # [23:20] <hasather> s/XPath/XPath 2.0/
  914. # [23:20] <jkj2> Yes, that's why I have said 99,999999999 instead od 100 % compatible
  915. # [23:21] <hasather> jkj2: I see, I wondered what you meant :)
  916. # [23:21] <hsivonen> cute. I try to avoid dealing with XSLT too deeply. I switched to SAXON 8 underneath Jing, saw warnings and switched back to SAXON 6 and decided not no use whatever performance goodness SAXON may have obtained in between
  917. # [23:23] <hsivonen> s/not no/not to/
  918. # [23:23] <jkj2> hsivonen: if you can live without key() function, you can try good old XT from Clark -- it is still fastest for many operations
  919. # [23:23] <hsivonen> jkj2: does it support TrAX?
  920. # [23:24] <hsivonen> there has to be a reason why Clark himself did not support XT in Jing
  921. # [23:24] <hsivonen> only SAXON 6 and Xalan
  922. # [23:25] <jkj2> hsivonen: good question -- I don't remember, but it was probably released before TrAX was standardized
  923. # [23:28] <othermaciej> if the W3C believes in the Semantic Web so much, why do they keep trying to replace HTML with purely presentation languages like SVG and XSL-FO?
  924. # [23:30] <jkj2> XSL-FO is not about Web, it's about print composition. (OK, yes there are features like collapsible menus meant for interactive display, but they were never implemented.)
  925. # [23:32] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  926. # [23:33] * jkj2 have to go
  927. # [23:33] * Parts: jkj2 (n=jirka@adsl-lib146-121-244-84.bluetone.cz)
  928. # [23:37] * Quits: gilles_drieu (n=gilles@c-71-202-63-48.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  929. # [23:38] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  930. # [23:38] <Hixie> othermaciej: same reason they're doing HTML5. The W3C leadership is more influenced by the desires of member companies than by their ideals.
  931. # [23:39] <Hixie> (not necessarily a bad thing)
  932. # [23:39] <othermaciej> Hixie: but a lot of advocates of SVG or XSL-FO are also proponents of things like RDF
  933. # [23:41] <hsivonen> othermaciej: separation of semantics and presentation: semantics in RDF and presentiation in XSL-FO :-)
  934. # [23:42] <othermaciej> that would be so awesome that I can't even think of anything to say
  935. # [23:48] <Dashiva> Where's the behavior? XSLT?
  936. # [23:54] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  937. # [23:58] * Quits: mpt (n=mpt@121-72-132-150.dsl.telstraclear.net) ("Leaving")
  938. # Session Close: Sun Mar 25 00:00:00 2007

The end :)