/irc-logs / freenode / #whatwg / 2006-12-01 / end

Options:

  1. # [10:26] -NickServ- This nickname is owned by someone else
  2. # [10:26] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
  3. # [10:26] [freenode-connect VERSION]
  4. # [10:26] * WhatBot (n=PircBot@net-153-119.mweb.co.za) has joined #whatwg
  5. # [10:26] * Topic is 'WHATWG -- http://www.whatwg.org/ -- (X)HTML5 -- Please leave your sense of logic at the door, thanks!'
  6. # [10:26] * Set by Lachy on Sun Nov 26 23:31:54 SAST 2006
  7. # [10:26] <Charl> ok let's test it and see if it works
  8. # [10:59] <hsivonen> morning
  9. # [11:00] <hsivonen> Lachy: If I guess correctly what Sam is going to suggest, I have intended to suggest the same thing
  10. # [11:00] <hsivonen> that is put <math> subtrees in the MathML namespace and <svg> subtrees in the SVG namespace
  11. # [11:00] <hsivonen> instead of hard-coding a list of MathML elements
  12. # [11:02] * Charl (n=charlvn@c1-146-1.wblv.isadsl.co.za) Quit ()
  13. # [11:10] <jgraham> hsivonen:That sounds more sensible to me. But I think there will be some stiff opposition
  14. # [11:10] * webben looks at the mailing list. Sees people /still/ trying to work out a way of making documents validate as XML and HTML. Sighs.
  15. # [11:18] * Charl (n=charlvn@c1-146-1.wblv.isadsl.co.za) has joined #whatwg
  16. # [11:45] <Lachy> hsivonen, I don't think that's what Sam is going to suggest. I think it's going to be about allowing xmlns attributes, but not xmlns:foo because he explicitly said no prefixes
  17. # [11:54] <Charl> ok whatbot seems to be behaving well, the stats work nicely
  18. # [11:54] <Charl> should i update the irc wiki page?
  19. # [11:55] <Lachy> Charl, yes
  20. # [11:56] <annevk> "appease the XML gods" fools!
  21. # [11:56] * annevk goes back to reading the log
  22. # [12:02] * ROBOd (n=robod@86.34.246.154) has joined #whatwg
  23. # [12:06] <annevk> hsivonen, you want to intertwine HTML with Math in some cases...
  24. # [12:07] <hsivonen> annevk: without <math> or <html> wrapper roots?
  25. # [12:07] <hsivonen> annevk: is that case common enough that it needs to be supported in text/html?
  26. # [12:08] <annevk> it might be
  27. # [12:08] <annevk> for <svg> certainly
  28. # [12:08] <annevk> you want <foreignObject><p>TEST</p></foreignObject> as well...
  29. # [12:08] <Lachy> if any form of namespace syntax is ever going to get added to HTML, it must not use the xmlns attribute
  30. # [12:09] <Lachy> that would only serve to further convince the XML camp that HTML is compatible with XML
  31. # [12:11] <annevk> Lets not waste our time on this... Did you get any further with the parser?
  32. # [12:12] <Lachy> annevk, <foreignObject><p ns="xhtml">TEST</p></foreignObject> would be the only type of namespacing I'd support, where the ns attribute would take one of a predefined set. That way, it can't get confused with xmlns and it's not compatible xml parsing
  33. # [12:12] <Lachy> that's just an idea though, which I got from http://ln.hixie.ch/?start=1151612438&count=1
  34. # [12:13] <Lachy> I've been reading through the Dive Into Python tutorial today, up to chapter 3 so far.
  35. # [12:15] <annevk> did you see the link I gave?
  36. # [12:15] <annevk> it shows a simple example of invoking various functions based on the state
  37. # [12:15] <Lachy> the one about constants?
  38. # [12:15] <annevk> no, the one on diveintopython
  39. # [12:16] <annevk> so you don't need a long switch case statement
  40. # [12:16] <Lachy> oh, yes, but I didn't understand the syntax well enough at the time. I'll rearead it now that I have a better idea
  41. # [12:17] <annevk> "test %s" % foo
  42. # [12:17] <annevk> replaces the %s with whatever value foo might have
  43. # [12:17] <annevk> you can also have tuples there...
  44. # [12:17] <annevk> "%stest%s" % (foo, bar)
  45. # [12:18] <Lachy> yes, that's the section I've just been reading up on in the last half hour
  46. # [12:20] <Lachy> so, basically, in principle, it's like what I was doing with the associative array of functions, where I dynamically call it based on the value of a variable
  47. # [12:20] <annevk> "This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it."
  48. # [12:20] <annevk> lol
  49. # [12:21] <annevk> Lachy, yeah, although I suppose the states would have to be strings in order to get meaningfull function invocations
  50. # [12:22] <Lachy> yes, so we can most likely use that method for what we need
  51. # [12:22] * mpt (n=mpt@121-72-128-96.dsl.telstraclear.net) Quit ("This computer has gone to sleep")
  52. # [12:25] <Lachy> This looks like a very convenient way of declaring constants http://diveintopython.org/native_data_types/declaring_variables.html#odbchelper.multiassign.range
  53. # [12:36] <annevk> http://www-xray.ast.cam.ac.uk/~jgraham/html5/ has some code
  54. # [12:36] <annevk> that's cool
  55. # [12:36] <annevk> hsivonen, yeah, I know what browsers do when they encounter a doctype
  56. # [12:37] <annevk> hsivonen, in gecko you can see it in the dom viewer quite easily iirc
  57. # [12:37] <annevk> I suppose it's prolly better if Opera throws for the entity &test; so we can remove some DOM Core features
  58. # [12:38] <annevk> BTW, regarding the XOM/DOM thing
  59. # [12:38] <annevk> I think we should whatever makes most sense for Python
  60. # [12:39] <Lachy> yes
  61. # [12:41] <hsivonen> annevk: that would most likely be ElementTree
  62. # [12:42] <hsivonen> disclaimers about my lack of experience apply
  63. # [12:42] <hsivonen> Kid templating uses ElementTree
  64. # [12:43] <annevk> yeah, perhaps
  65. # [12:43] <ROBOd> good eday to all!
  66. # [12:43] <ROBOd> i see that Hixie accepted Sam's proposal. well done
  67. # [12:43] <hsivonen> ROBOd: gday
  68. # [12:43] <annevk> Hixie just has a lack of faith
  69. # [12:44] <ROBOd> annevk: what do you mean? why lack of faith?
  70. # [12:44] <annevk> hsivonen, ElementTree doesn't have support namespaces ?!
  71. # [12:45] <hsivonen> annevk: really? not good!
  72. # [12:45] * annevk reads http://effbot.org/zone/element.htm
  73. # [12:45] <ROBOd> i was just reading now http://blog.whatwg.org/html-vs-xhtml < this should be "featured" in the FAQ - it's important reading for everyone interested of HTML5
  74. # [12:46] <Lachy> yes, it will be eventually. I'll just add a link to it for now
  75. # [12:47] <hsivonen> annevk: I believe ElementTree handles namespaces the RDF way
  76. # [12:47] <ROBOd> Lachy: very good article
  77. # [12:47] <hsivonen> that is nsuri#localName in one string
  78. # [12:47] <Lachy> thanks :-) (though hsivonen deserves some credit too)
  79. # [12:48] <annevk> hsivonen, that's not really acceptable
  80. # [12:48] <hsivonen> annevk: why not?
  81. # [12:48] <annevk> i don't like that
  82. # [12:48] <Lachy> what's the RDF way?
  83. # [12:49] <annevk> it requires knowledge of the namespaces that are available
  84. # [12:49] <hsivonen> annevk: because you hate RDF? It is easier than passing around (nsuri, localName)
  85. # [12:49] <hsivonen> annevk: huh?
  86. # [12:49] <hsivonen> how do you mean available?
  87. # [12:49] <annevk> used
  88. # [12:50] <hsivonen> I don't follew
  89. # [12:50] <hsivonen> follow
  90. # [12:50] <annevk> http://example.org/#foo
  91. # [12:50] <annevk> http://example.org/##foo
  92. # [12:51] <annevk> and it requires additional functions to get the localname or namespace
  93. # [12:51] * raspberry-lemon (n=lemon@63.99.9.18) has joined #whatwg
  94. # [12:51] <hsivonen> annevk: why don't you dispatch on the full name?
  95. # [12:51] <annevk> anyway, It's prolly not really worth it to discuss this now
  96. # [12:53] <annevk> it also seems you can't use it for XML then since it doesn't support qnames
  97. # [12:53] <annevk> and adding those would not make it look pretty
  98. # [12:53] <hsivonen> annevk: if you need to know the qName, you have a bug
  99. # [12:53] <annevk> XPath?
  100. # [12:54] <hsivonen> XPath matches on the uri, localName pair, I believe
  101. # [12:54] * Charl (n=charlvn@c1-146-1.wblv.isadsl.co.za) Quit (Client Quit)
  102. # [12:54] <annevk> XPath uses qnames...
  103. # [12:54] <Lachy> you only need to know the qname when serialising as XML, but when reserialising from HTML, there won't be any prefixes
  104. # [12:54] <annevk> sure
  105. # [12:54] * Charl (n=charlvn@net-153-111.mweb.co.za) has joined #whatwg
  106. # [12:55] <hsivonen> annevk: I use different qNames in XPath and in the documents that I match. matching happens on nsuri, localName
  107. # [12:56] <annevk> there has to be a reason c14n can't normalize to something without changing the qnames
  108. # [12:57] <hsivonen> without?
  109. # [12:57] <annevk> http://www.snellspace.com/wp/?p=546#comment-4751
  110. # [12:57] <webben> amara and 4suite support namespaces
  111. # [12:57] <annevk> hsivonen, yes
  112. # [12:57] <webben> (and just because I'm too stupid to get them to work doesn't mean you guys won't be able to :) )
  113. # [12:57] <annevk> euh, no
  114. # [12:57] * annevk is confused now
  115. # [12:58] <hsivonen> annevk: I don't see the relevance of the URL
  116. # [12:58] <annevk> did I mention already this shouldn't be discussed now?
  117. # [12:58] <hsivonen> fine
  118. # [12:58] <annevk> hsivonen, that URL is totally unrelated
  119. # [12:58] <annevk> it mentions that Wordpress is borked
  120. # [12:58] <annevk> comment 1
  121. # [12:58] <hsivonen> not news :-)
  122. # [12:58] <webben> dog bites man
  123. # [12:59] <annevk> hmm, that's a show in the Netherlands...
  124. # [12:59] <annevk> actually
  125. # [12:59] <annevk> the show is called man bites dog
  126. # [12:59] <annevk> nm me
  127. # [13:01] * annevk goes to fetch some lunch
  128. # [13:02] * webben (n=benjamin@91.84.22.233) Quit ("Leaving")
  129. # [13:20] * webben (n=benjamin@91.84.22.233) has joined #whatwg
  130. # [13:31] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) Quit ()
  131. # [13:35] <annevk> so the tokenizer http://www-xray.ast.cam.ac.uk/~jgraham/html5/tokeniser.py from jgraham uses the classes construct I proposed earlier. but we figured out that it would never work because the parser and tokenizer need to be integrated
  132. # [13:35] <annevk> I suppose one could be a subclass of the other, but I'm not sure if that's worth it
  133. # [13:46] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) has joined #whatwg
  134. # [13:46] <Lachy> you mean the tokeniser and tree builder need to be integrated?
  135. # [13:47] <Lachy> we only need them to be integrated in a way that allows the tree builder to update the content model flag, I think
  136. # [13:48] <annevk> also for things like document.write I suppose
  137. # [13:48] <annevk> if ever
  138. # [13:48] <Lachy> I had a thought about that, but haven't investigated it yet, but when we call e.g. tree.startElement(), we could have the return value indicate the content model flag. Not sure if that would work or not
  139. # [13:48] <Lachy> we're not writing a scripting engine yet, we don't need to worry about doc.write()
  140. # [13:48] <annevk> we should at least take innerHTML into account
  141. # [13:49] <annevk> that's used for some conformance criteria even
  142. # [13:49] <annevk> and it's a nice way to provide serialized versions of the document
  143. # [13:52] <Lachy> to support document.write(), we need to allow a scripting engine to inject markup back into the stream.
  144. # [13:52] <Lachy> innerHTML is different though
  145. # [13:55] * Lachy looks up innerHTML to see what it would take to support it
  146. # [13:57] <hsivonen> annevk: do you mean you want to allow Python apps to call innerHTML on your tree?
  147. # [13:57] <annevk> yes
  148. # [13:57] <annevk> either on a document node or element node
  149. # [13:58] <annevk> there needs to be a way to go from the tree to a string again
  150. # [14:00] <hsivonen> annevk: shouldn't you use a full-document serializer for that?
  151. # [14:00] <Lachy> yes, we should
  152. # [14:00] * virtuelv (n=arve@pat-tdc.opera.com) has joined #whatwg
  153. # [14:01] <Lachy> innerHTML would be nice, but we don't need to worry about it until we start implementing the DOM API. The tokeniser will work with innerHTML similar to the way it parses anything else (except for a few special things, like setting the content model flag)
  154. # [14:01] <Lachy> that's for setting innerHTML, btw
  155. # [14:03] <Lachy> on getting, we'd need to have a serialiser that it can make use of
  156. # [14:03] <annevk> hsivonen, as long as it's compatible with innerHTML... sure
  157. # [14:03] <annevk> innerHTML is the serializer we need
  158. # [14:03] <annevk> I'm not sure why anything else would be relevant, but perhaps I'm just misunderstanding what you guys are suggesting
  159. # [14:03] <Lachy> innerHTML is just an API that accesses the serialiser
  160. # [14:06] <hsivonen> perhaps Hixie already specced innerHTML on the document node to do what I want a full-doc serializer to do
  161. # [14:06] <annevk> I think so
  162. # [14:07] <annevk> otherwise my suggestion wouldn't make sense
  163. # [14:08] <Lachy> annevk, see http://www.xom.nu/apidocs/nu/xom/canonical/Canonicalizer.html
  164. # [14:08] <Lachy> the write() method gets passed a Node, which then serialises that node
  165. # [14:09] <Lachy> innerHTML just access such an API by passing it a reference to the node upon which it was invoked
  166. # [14:10] <Lachy> in XOM, the Document is a Node as well, so the write() function accepts either elements or Document
  167. # [14:16] <annevk> fair enough, Node.innerHTML
  168. # [14:18] <annevk> WhatBot, pointer?
  169. # [14:18] <annevk> WhatBot, help
  170. # [14:19] <annevk> WhatBot, you're not silly at all!
  171. # [14:23] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) Quit ()
  172. # [14:33] <Lachy> annevk, http://lachy.id.au/temp/HTMLReader.py
  173. # [14:34] <annevk> I think you want the states as strings...
  174. # [14:34] <Lachy> there are some nice features in jgraham's parser that we should copy across, though all the DOM stuff in his parser.py shouldn't be in the parser
  175. # [14:35] <annevk> jgraham has things like "DATA":self.dataState
  176. # [14:35] <Lachy> yeah, we probably do, although I like what jgraham did in tokeniser.py with the states dictionary
  177. # [14:35] <annevk> I couldn't get that to work
  178. # [14:35] <annevk> though
  179. # [14:35] <annevk> it says that self is not defined
  180. # [14:35] <annevk> perhaps it should happen when you initialize the object
  181. # [14:36] <Lachy> is self equivalent to this in other languages?
  182. # [14:36] <annevk> yup
  183. # [14:36] <annevk> that works
  184. # [14:37] <annevk> Lachy, please join #whatwg-paste
  185. # [14:44] <annevk> Lachy, so what does XMLReader do?
  186. # [14:44] <annevk> Lachy, does it output a tree or just startDocument etc. ?
  187. # [14:48] <Lachy> when you create an XMLReader, you need to set various handlers. e.g. setContentHandler(handler)
  188. # [14:49] <Lachy> The content handler needs to implement this interface http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html
  189. # [14:49] <Lachy> as the XMLReader parses the document, it emits events by calling contentHandler.xxx(), where xxx is the appropriate method.
  190. # [14:50] * csarven (i=nevrasc@modemcable081.169-202-24.mc.videotron.ca) has joined #whatwg
  191. # [14:50] <Lachy> it calls contentHandler.startDocument() first, then contentHandler.startElement(...) for every start tag, etc.
  192. # [14:51] <annevk> kk
  193. # [14:51] <annevk> I like the idea of having HTMLParser on top of HTMLReader and try to work with callback functions if that's feasible
  194. # [14:53] <Lachy> I don't understand what you mean. HTMLParser and HTMLReader are just different names for the tokeniser, aren't they?
  195. # [14:53] <annevk> the former would do tree construction and use HTMLReader as baseclass
  196. # [14:57] <Lachy> http://lachy.id.au/temp/source/ specifically, see parse.php and XMLParser.php
  197. # [14:58] <hsivonen> http://hsivonen.iki.fi/code/api/fi/iki/hsivonen/xml/checker/table/package-summary.html
  198. # [14:58] <hsivonen> in case anyone is interested in taking a look at the table integrity checker internal
  199. # [14:59] <hsivonen> s
  200. # [14:59] <hsivonen> the javadoc links to HTMLified source
  201. # [15:00] * jgraham_ (n=jgraham@xpc9.ast.cam.ac.uk) has joined #whatwg
  202. # [15:01] <jgraham_> So, according to thee logs, Anne said <annevk> so the tokenizer http://www-xray.ast.cam.ac.uk/~jgraham/html5/tokeniser.py from jgraham uses the classes construct I proposed earlier. but we figured out that it would never work because the parser and tokenizer need to be integrated
  203. # [15:02] <jgraham_> Is it not enough just to have the parser hold a ref to the tokeniser so it can adjust its state? Does it need to do more than change the content model flag?
  204. # [15:03] <jgraham_> (Oh and I know the DOM stuff needs to be (re)moved, that was just a really basic tree implementation to get me going). I was wondering about using elementtree
  205. # [15:04] <Lachy> jgraham, I don't understand why you have classes for each token. Do you create a token object for each one and emit that?
  206. # [15:04] <annevk> jgraham, well yeah, but then you don't need classes for tokens anymore
  207. # [15:04] <annevk> jgraham_, you construct the "DOM stuff" right away
  208. # [15:05] <jgraham_> Yeah. One class per token type. It just seemed conceptually simple.
  209. # [15:05] <annevk> but those token types don't survive for a second... :)
  210. # [15:06] <Lachy> ok. looking back at the JS implmentation I started a few months ago, it looks similar to what I was trying to do as well. But I prefer to just use SAX-like events instead of creating a token object
  211. # [15:07] <jgraham_> Maybe I haven't read the spec closely enough... why do they need to survive? Or are you just worried that it means creating and destroying a lot of objects?
  212. # [15:08] <Lachy> well, yeah, sort of. It just seems unnecessary to create, say, a StartTag token, when you can just call handler.startElement(...)
  213. # [15:11] <jgraham_> Well sometimes you need to keep tokens around for a little while (e.g. when you want to reprocess the current token). Also, the tokeniser seems to create a stack of tokens in some instances...
  214. # [15:11] * jgraham_ hasn't looked at the tokeniser for a little while
  215. # [15:13] <Lachy> neither have I, I need to reread that part of the spec and also improve my knowledge of python
  216. # [15:17] <jgraham_> I think elementtree output would be nice but it's pretty different from the standard DOM
  217. # [15:19] <jgraham_> apart from the think where namespaces are stored as "{nsURI}localName", you'd have to deal with the different way of storing text
  218. # [15:20] <jgraham_> e.g. <span>foo <em>bar</em> baz</span> has " baz" in the tail attribute of the em element...
  219. # [15:20] <annevk> ?
  220. # [15:22] <annevk> oh, they store text that way?
  221. # [15:23] <annevk> that sounds rather bad
  222. # [15:23] <jgraham_> iir correctly the sample above has Span.text="foo " Em.text="bar" Em.tail=" baz" - tail holds all the text after the element closes but before the next sibling opens or parent closes
  223. # [15:23] <Lachy> jgraham, wow. that's really bad
  224. # [15:24] <jgraham_> It often works quite well, actually. But less so for prose-orientated documents
  225. # [15:24] <Lachy> well, unless .tail is just the equivalent of .nextSibling in the DOM
  226. # [15:24] <Lachy> does the parent element still have refences to all of its child nodes?
  227. # [15:25] <jgraham_> I don't think it really considers text as nodes in the tree, just attributes of elements
  228. # [15:25] <jgraham_> or attributes of nodes, if you like
  229. # [15:25] <Lachy> oh, that's crap
  230. # [15:26] <jgraham_> Well like I sid, it works really nicely in python in practice, but it's not trivial to map onto the DOM model
  231. # [15:33] <jgraham_> annevk: the reason that you couldn't get the "DATA":self.dataState thing to work is because it doesn't. I don't quite know what I had in my head (I've been using this pattern quite a bit in the code).
  232. # [15:33] <jgraham_> I'm pretty sure I can fix it up so it does work though :)
  233. # [15:36] <annevk> jgraham_, I made it work...
  234. # [15:36] <annevk> jgraham_, put the states in __init__
  235. # [15:37] <jgraham_> Yeah, I that will work, obviously. I had it in my head you could avoid that somehow though. Maybe I'm imagining things ;)
  236. # [16:16] * Charl (n=charlvn@net-153-111.mweb.co.za) Quit ()
  237. # [16:33] * jgraham_ (n=jgraham@xpc9.ast.cam.ac.uk) Quit ("Leaving")
  238. # [16:37] <Lachy> I've added a new question about treating HTML as XML to the FAQ
  239. # [16:37] <Lachy> http://blog.whatwg.org/faq/ (see the last question)
  240. # [16:38] <Lachy> any suggestions for improving it would be appreciated
  241. # [16:49] <annevk> do not
  242. # [16:50] <Lachy> annevk, do not what?
  243. # [16:50] <annevk> you forgot not in your last e-mail
  244. # [16:51] <Lachy> where abouts. Can you quote the sentence where I made the mistake?
  245. # [16:52] <annevk> not anymore
  246. # [16:52] * Lachy is confused
  247. # [16:55] * Charl (n=Charl@196.21.192.15) has joined #whatwg
  248. # [17:21] <annevk> Charl, cool bot
  249. # [17:21] <annevk> Lachy, I removed the e-mail
  250. # [17:22] <Lachy> what e-mail?
  251. # [17:22] <annevk> see above
  252. # [17:22] <Lachy> ?
  253. # [17:22] <annevk> ??
  254. # [17:23] <annevk> a: you forgot not in your last e-mail
  255. # [17:23] <annevk> l: where abouts. Can you quote the sentence where I made the mistake?
  256. # [17:23] <annevk> a: not anymore
  257. # [17:23] <Lachy> which e-mail are you referring to?
  258. # [17:23] <Lachy> yeah, I have no idea what you meant by that
  259. # [17:23] <annevk> I said not anymore because I removed the e-mail...
  260. # [17:23] <Lachy> from where?
  261. # [17:23] <annevk> inbox
  262. # [17:24] <annevk> dude!
  263. # [17:24] <Lachy> right, so one of the e-mails I setnt to whatwg?
  264. # [17:25] <annevk> the last one
  265. # [17:26] <Lachy> oh, I see "I really do [not] understand the desire to do so."
  266. # [17:30] <Charl> annevk: thanks, i think whatbot is doing well for its first day :) (sorry for slow reply, hacking code..)
  267. # [17:42] <Hixie> for those of you writing a tokeniser in python, my guess would be that the easiet implementation would use "yield"
  268. # [17:42] <Hixie> since then you never have to unwind the tokeniser stack
  269. # [17:43] <Lachy> wjat
  270. # [17:43] <Lachy> what's yeild
  271. # [17:44] <Lachy> do you mean this http://docs.python.org/ref/yield.html
  272. # [17:45] <Hixie> yes
  273. # [17:47] <annevk> yeah, I suppose that makes sense
  274. # [17:48] <Hixie> though fwiw, i don't think my tokeniser ever has to emit more than two tokens at once, so i just have two tokens, "current" and "next"
  275. # [17:50] <Lachy> I'm trying to find an example that shows how to use it, and which explains it more clearly than that documentation
  276. # [17:52] * ROBOd (n=robod@86.34.246.154) Quit ("http://www.robodesign.ro")
  277. # [17:53] <annevk> surch for generators and python
  278. # [17:53] <annevk> or something
  279. # [17:55] * annevk has to go change for the Opera Christmas party
  280. # [17:56] * annevk is prolly online again tomorrow
  281. # [17:56] <Lachy> ok, I've found an example and sort of understand it now
  282. # [17:58] <Lachy> so would we use that to iterate through each character in the file stream? or something else?
  283. # [18:09] <Lachy> Hixie, could you perhaps add a note to the spec in the start tag syntax section pointing out the use of the trailing slash does not permit the use of an XML parser to parse and HTML document and link to the parsing section where it defines that?
  284. # [18:10] <Hixie> nah
  285. # [18:11] <Hixie> i don't think that would help anyone
  286. # [18:11] <Lachy> ok, it's just that all these people with the idea that they can do so is just irritating
  287. # [18:11] <Hixie> for someone to be reading that part of the spec, they have to either have read the relevant part that says it's not XML, or they'll miss the note in the same way
  288. # [18:11] <Hixie> yeah, i agree
  289. # [18:16] <raspberry-lemon> why was the trailing slash thing added?
  290. # [18:17] <Hixie> to make it easier for authors to migrate from XHTML
  291. # [18:17] <raspberry-lemon> ah
  292. # [18:17] <Hixie> and because trailing slashes have this "designer label" quality these days
  293. # [18:17] <Hixie> basically
  294. # [18:17] <raspberry-lemon> yeah
  295. # [18:18] <Hixie> Lachy: i updated the spec's way of having spaces in start attributes. it's not what you proposed, but i think it's ok. (basically i added more steps and modified the attribute syntax section)
  296. # [18:20] <Lachy> I think the discussion on the list is showing that people going to consider it an Appendix-C-like extension designed as a means to help them continue migrating from HTML to XHTML, rather than from XHTML1 to HTML5
  297. # [18:20] <Hixie> possible
  298. # [18:20] <Hixie> they'll be sadly mistaken :-)
  299. # [18:21] <Lachy> I'm writing an FAQ entry for it now. I'll include those reason in it.
  300. # [18:21] <Hixie> cool
  301. # [18:21] <Hixie> Charl: yt?
  302. # [18:22] <Charl> Hixie: hi am here now
  303. # [18:22] <Hixie> Charl: hey dude
  304. # [18:22] <Hixie> so i was thinking about the status thing
  305. # [18:22] <Charl> yeah, let's get that going
  306. # [18:22] <Hixie> i think it would make sense to also have the "SCS" flags as part of it
  307. # [18:23] <Hixie> to mark which sections are "self-contained"
  308. # [18:23] <Hixie> so that they can be implemented separately
  309. # [18:23] <Hixie> that way i can remove the SCS stuff from the spec :-)
  310. # [18:23] <Charl> ah, that sounds interesting
  311. # [18:23] <gsnedders> Lachy: I'll send you an update to that PCRE, as I realised several bugs in it a day or two ago
  312. # [18:24] <Lachy> don't worry about it
  313. # [18:24] <Lachy> we're not going to implement it
  314. # [18:24] <Charl> Hixie: since that's already there, i think i should start by getting the script to be able to insert those
  315. # [18:25] <Charl> Hixie: am going to be offline during the weekend unfortunately - is it ok if i speak to you about that on Monday?
  316. # [18:25] <Lachy> Once hsivonen updates the validator so the trailing slash isn't flagged as an error, I'll just remove the script and accept that WP is a broken CMS
  317. # [18:26] <Hixie> Charl: sure thing dude.
  318. # [18:26] <Hixie> Charl: there's no rush really.
  319. # [18:27] <Hixie> Charl: though it would be nice to have it up and running by the end of the year, since i expect the w3c to start moving faster in january
  320. # [18:27] <Charl> Hixie: cool, we'll get it sorted long before then :)
  321. # [18:27] <Hixie> :-)
  322. # [18:27] <Lachy> Hixie, has any progress been made on the charter since that first draft?
  323. # [18:28] <Hixie> Lachy: i've been told so, but i haven't seen it or heard anything but rumours
  324. # [18:28] <Lachy> ok.
  325. # [18:28] <Hixie> Lachy: i highly doubt the progress will be enough to make the whatwg move lock-stock-and-barrel to w3c
  326. # [18:28] <Hixie> basically i intend to continue the whatwg work unless the w3c provides a community environment as open as the whatwg
  327. # [18:29] <Hixie> which i don't see happening, they just don't understand openness, sadly
  328. # [18:29] <Lachy> ok, good
  329. # [18:29] <Lachy> well, good that you'll continue, bad that they don't understand opennes :-(
  330. # [18:29] <Hixie> yeah
  331. # [18:30] <Lachy> I think the start tag syntax still needs to be made a little clearer
  332. # [18:30] <webben> Presumably it doesn't need to be a total dichotomy.
  333. # [18:30] <webben> That is the W3C actually has submissions from outside all the time.
  334. # [18:31] <Hixie> webben: oh i'll be in their htmlwg either way
  335. # [18:31] <webben> All the W3C really needs to do is not try and reinvent Web Forms 2.0 with yet-another-intermediate technology.
  336. # [18:31] <Hixie> or not change wf2 in stupid ways
  337. # [18:31] <webben> And all WHATWG really needs to do is not to let too big a gap grow between XHTML 5 and the rest of the XML world.
  338. # [18:31] <Lachy> Perhaps you could add something to setp 5 that explicitly refers the additional requirements for unquoted attribute values and empty attributes
  339. # [18:32] <webben> There's no particular reasons why all specs should be developed in-house as it were
  340. # [18:32] <Hixie> webben: we'll see
  341. # [18:33] <Lachy> if browser vendors just don't implement their corrupted version of WF2+XForms (if they go ahead with it), won't that just make it irrelevant like XHTML2?
  342. # [18:33] <Hixie> yup....
  343. # [18:34] <Hixie> Lachy: spec updated
  344. # [18:34] <Lachy> so does it really matter in the end, as long as it keeps the XForms people away from the real spec, they can play with their own version as much as they like
  345. # [18:35] <Lachy> that's good now :-)
  346. # [18:35] <webben> Of course it matters. Because that scenario would be a waste of the W3C's time.
  347. # [18:36] <webben> (which, given they're slow, short of staff, and short of money, is precious)
  348. # [18:36] <webben> Maybe what's really needed is a demonstration of alternate serialization to WF2 and XForms
  349. # [18:37] <webben> That would probably get IBM on board.
  350. # [18:37] <webben> (AFAICT they seem to be a key opponent of WF2 in its current form)
  351. # [18:37] <webben> Is such serialization currently possible, or would it be very difficult?
  352. # [18:38] <Hixie> IBM is a large company with many employees
  353. # [18:38] <Hixie> they don't always agree
  354. # [18:38] <webben> hmm... okay s/IBM/the IBM XForms guys/g
  355. # [18:42] <Hixie> heh
  356. # [18:43] <Lachy> "However, a start tag must never be omitted if it has any attributes." What if it has attributes, but which are explicitly set to the default values?
  357. # [18:43] <Hixie> then it has attributes, and mustn't be omitted
  358. # [18:44] <Lachy> oh, nevermind, I just realised that it does make a difference to the DOM if they're omitted
  359. # [18:44] <Hixie> what is WITH people and xmL:id
  360. # [18:45] * Lachy looks for e-mail referring to xml:id...
  361. # [18:45] <Hixie> michel's recent one
  362. # [18:45] <Hixie> michel's a great guy btw
  363. # [18:45] <Hixie> been sending great feedback
  364. # [18:48] <Lachy> yeah, he's ok. he's not one of the "kooks" :-)
  365. # [18:50] <hsivonen> IIRC, anne likes xml:id. or at least used to like ;-)
  366. # [18:54] <Lachy> Hixie, xml:id is already mentioned in the spec
  367. # [18:55] <Hixie> crap
  368. # [18:56] <Hixie> better take that out
  369. # [18:56] <Hixie> :-)
  370. # [18:56] <Lachy> only twice, though
  371. # [18:56] <Hixie> oh it's just as parantheticals
  372. # [18:56] <Hixie> that's ok
  373. # [18:56] <Hixie> jesus, annevk needs to work on his tact
  374. # [18:57] <Hixie> "You're still not getting it, do you?" sounds like the kind of thing i would write when i was his age, which is why the w3c staff all hate me now. :-P
  375. # [18:59] <Lachy> heh
  376. # [19:02] <hsivonen> BTW, I think there's a right reason and a wrong reason for wanting the intersection of HTML5 and XHTML5 syntaxes not to be empty
  377. # [19:02] <hsivonen> the right reason is Sam's reason: being able to use one code path for *producing* both
  378. # [19:03] <hsivonen> the wrong reason is being supposedly able to use one code path for *consuming* both
  379. # [19:03] <Hixie> you can do sam's thing with just minor things in the header
  380. # [19:03] <Hixie> if you avoid troublesome things like xml:base, xml:lang/lang, <noscript>
  381. # [19:03] <Hixie> document.write
  382. # [19:04] <Hixie> .tagName
  383. # [19:04] <Hixie> etc
  384. # [19:04] <Lachy> the problem with that "right reason", though, is that has proven fatal with all the people failing to produce XHTML 1.0 properly as text/html.
  385. # [19:04] <hsivonen> like I said on the list, the problem with Sam's case is the "professional driver on closed road thing": those who imitate him can and will get confused and break stuff
  386. # [19:05] <Hixie> yup
  387. # [19:05] <hsivonen> s/ thing"/" thing/
  388. # [19:05] <Lachy> If people wish to use the one code path to develop both, they need to write in one syntax and use a program to serialise to the other
  389. # [19:05] <Hixie> yup
  390. # [19:05] <Hixie> i think we're close enough to allowing #1 to not need to go any further
  391. # [19:06] <Lachy> agreed
  392. # [19:06] <Lachy> the sooner we can get some tools made available that do actually transform one serialisation into the other, the sooner people might actually start to understand the whole concept
  393. # [19:14] * rhymes (n=rhymes@host221-72-dynamic.54-82-r.retail.telecomitalia.it) has joined #whatwg
  394. # [19:18] <webben> Hixie, what is a "code path"?
  395. # [19:19] <webben> Hixie, is this a really complicated way of saying you need to be able to serialize both from the same source?
  396. # [19:20] <webben> or more than that...?
  397. # [19:22] <Lachy> webben, it's just a way of saying the way in which you write your code. So if you want to follow one code path to write both HTML and XHTML, they either have to be the same syntax or be easy to transform from one to the other.
  398. # [19:22] <webben> How many cases are there currently (if any) where XHTML5 can fully represent an idea that HTML5 cannot?
  399. # [19:23] <webben> (excluding pulling in stuff from other namespaces)
  400. # [19:23] <Lachy> <p><ul>...</ul></p> is one
  401. # [19:23] <webben> ah ... what about <p><blockquote>...</blockquote></p>?
  402. # [19:24] <Lachy> same for <ol>, and other structured inline-level elements
  403. # [19:24] <Hixie> a "code path" is a set of steps through some code. so e.g. the program: if (a) { doA(); } else { doB(); } has two codepaths, one for if a is true, and one for if it is false.
  404. # [19:24] <Lachy> http://whatwg.org/specs/web-apps/current-work/#structured
  405. # [19:25] * Hixie wonders where he used the term "code path"
  406. # [19:25] * webben doesn't quite understand. Surely you'd only ever want to produce XHTML5 /or/ HTML5 as one or another code path.
  407. # [19:25] <webben> e.g. if ancient user ancient, produce HTML5 and if new user agent produce XHTML5
  408. # [19:25] <Hixie> webben: some people want to send XHTML to mozilla and HTML to IE
  409. # [19:26] <Hixie> but they don't want to write their code twice
  410. # [19:26] * rhymes (n=rhymes@host221-72-dynamic.54-82-r.retail.telecomitalia.it) Quit ()
  411. # [19:26] <Hixie> they want to have most of the code be the same for both
  412. # [19:26] <Hixie> in totally unrelated news, why did PG&E (the electric company) just randomly give me $90 this month. wtf.
  413. # [19:26] <webben> heh count your blessings :)
  414. # [19:26] <Hixie> oh i'm not complaining
  415. # [19:27] <Lachy> PG&E?
  416. # [19:27] <webben> Could we counter the <p> problem by introducing an equivalent alternative e.g. <para> ?
  417. # [19:27] <Lachy> ah Pacific Gas and Electric
  418. # [19:27] <Hixie> problem?
  419. # [19:28] <webben> problem == something you can do in XHTML5 not HTML5 hence making more code paths
  420. # [19:28] <Lachy> no, that wouldn't work
  421. # [19:28] <webben> Lachy, why?
  422. # [19:28] <Lachy> it would be treated like any unknown element and isn't backwards compatible
  423. # [19:29] <webben> hmm ... how about a microformat class="para" applied to div ?
  424. # [19:29] <Lachy> and authors wouldn't use it
  425. # [19:29] <Lachy> no
  426. # [19:29] <Lachy> <p> is for paragraph
  427. # [19:29] <Lachy> not div or any other element
  428. # [19:29] <webben> but then paragraph means something different in XHTML5 from HTML5.
  429. # [19:29] <webben> paragraph in HTML5 actually means "block of text"
  430. # [19:30] <webben> (like in HTML4)
  431. # [19:30] <Lachy> no, it means the same thing. The difference is that, for backwards compat reasons, the HTML serialisation can't produce the same result as the XML serialisation in some cases
  432. # [19:30] <webben> So what would a CMS do then? Throw up an error?
  433. # [19:31] <Lachy> the same is true for <noscript> in the other direction. i.e. it can be represented in HTML, but not in XHTML
  434. # [19:31] <Lachy> an error for what?
  435. # [19:31] <webben> Lachy, yeah but <noscript> is semantically unimportant
  436. # [19:31] <Hixie> webben: it just means that for certain things, the CMS shouldn't allow it if it is ever going to serialise to HTML form
  437. # [19:31] <webben> Lachy, that's just code stuff ... no relation to real-world ideas like paragraphs
  438. # [19:34] <webben> <p>foo<blockquote><p>foo</p></blockquote></p> is okay in HTML5 isn't it?
  439. # [19:34] <Lachy> Hixie, in those cases, it just makes the HTML serialisation a slightly lower quality alternative than the original XML serialisation. A CMS shouldn't prevent it from occurring, though it may choose to warn the user
  440. # [19:35] <Lachy> s/user/author
  441. # [19:35] <Hixie> fair enough
  442. # [19:36] <Hixie> webben: yes
  443. # [19:38] <webben> but <p><blockquote><p>foo</p></blockquote></p> would be wrong ... is that right?
  444. # [19:38] <Hixie> no that's allowed too
  445. # [19:39] <Hixie> somewhat pointless, but allowed
  446. # [19:39] * webben is now confused
  447. # [19:39] <webben> (again) ;)
  448. # [19:39] <Hixie> Lachy: pick a TBW section for me to work on next :-)
  449. # [19:39] <webben> what would I need to do to my blockquote example to break it?
  450. # [19:39] * Hixie has run out of things on his 2006Q4 todo list for HTML5 :-/
  451. # [19:39] <Hixie> webben: something like:
  452. # [19:39] <Hixie> um
  453. # [19:40] <Hixie> <ol> <li> foo <blockquote> ... would be illegal
  454. # [19:40] <Hixie> <ol> <li> <p> foo </p> <blockquote> ... would be fine
  455. # [19:40] <Hixie> <ol> <li> <p> foo <blockquote> ... would be fine too
  456. # [19:40] <Hixie> no wait
  457. # [19:40] <Hixie> la la la
  458. # [19:40] <Hixie> that's all wrong
  459. # [19:40] <Hixie> try again
  460. # [19:41] <webben> isn't the first example legal even in HTML4?
  461. # [19:41] <Hixie> "<aside> foo <p>..." would be illegal
  462. # [19:41] <Hixie> not everything allowed by HTML4 is allowed in HTML5
  463. # [19:41] <Hixie> especially when it comes to elemenst that in HTML4 had the content model %flow
  464. # [19:41] <Hixie> html5 is "stricter"
  465. # [19:42] <Lachy> Hixie, how about either http://www.whatwg.org/specs/web-apps/current-work/#scripting0 or http://www.whatwg.org/specs/web-apps/current-work/#classes
  466. # [19:42] <Hixie> aw man, that's like the two hardest sections!
  467. # [19:42] <Hixie> ok
  468. # [19:43] <Lachy> I thought classes would be the easiest?
  469. # [19:43] <Hixie> not sure what classes has to say
  470. # [19:43] <Hixie> that's the problem :-)
  471. # [19:43] <Lachy> but I knew scripting would be hard, though
  472. # [19:43] <Hixie> i can't require a wiki entry for every class value
  473. # [19:43] <Hixie> that would be stupid
  474. # [19:43] <Hixie> given how often people invent new ones
  475. # [19:43] <Hixie> though it would be fun to try
  476. # [19:44] <webben> Hixie, you can have a big bold thing about using structural/semantic names
  477. # [19:44] <webben> and then recommend the wiki if you want anyone else to understand those names
  478. # [19:44] <webben> (and a long spiel about avoiding classes like "red" and "nav-left"
  479. # [19:44] <Lachy> I think one of the studies of just a few hundred pages that I read revealed something like 5000 class names, from memory. I can't remember which study that was
  480. # [19:45] <Lachy> maybe I'm exagerating that number a bit though
  481. # [19:45] <webben> Lachy, dreamweaver and friends inflate these things though
  482. # [19:45] <Hixie> Lachy: yeah my own study revealed six bazillion :-P
  483. # [19:45] <webben> and class="MSWordGarbarge679970"
  484. # [19:46] <Lachy> hahahaha!
  485. # [19:46] <webben> you'd expect the set to be large, if only because of multiple languages
  486. # [19:46] <Lachy> if you want something easiser, you could try image maps
  487. # [19:47] <Hixie> nono
  488. # [19:47] <Hixie> classes is fine
  489. # [19:47] <Hixie> just not sure what to say
  490. # [19:47] <webben> Hixie, you could make some recommendations about what make good classnames from a scripting/css perspective too
  491. # [19:47] <Lachy> oh, ok
  492. # [19:47] <webben> Hixie, you need to clarify what UAs should do with classes
  493. # [19:47] <Hixie> "nothing"
  494. # [19:47] <Hixie> that's already in the spec
  495. # [19:47] <Hixie> this section would be predefined class names
  496. # [19:47] <webben> Hixie, I've been having correspondence with someone subscribed to www-html who's convinced UAs should be reading them out or something
  497. # [19:47] <Hixie> like hCard's
  498. # [19:48] <Hixie> well there are weirdos everywhere
  499. # [19:48] <Hixie> especially www-html :-P
  500. # [19:48] <webben> Hixie, I think he simply didn't realize that screen readers do nothing of the sort.
  501. # [19:48] <webben> and misunderstood the stuff about semantic class names
  502. # [19:48] <Lachy> would it be out of scope for us to take the hCard and hCalendar specs and rewrite them with actual conformance and processing requriements?
  503. # [19:48] <webben> so I think there is room for being clear
  504. # [19:49] <Hixie> you don't think http://www.whatwg.org/specs/web-apps/current-work/#metadata is clear enough?
  505. # [19:49] <Hixie> Lachy: i intend to do so eventually if nobody else does... but i don't want to, i'd like microformats.org to do it
  506. # [19:50] <Lachy> I think you'll be waiting a while for that
  507. # [19:50] <webben> Hixie, no, not really.
  508. # [19:50] <Hixie> webben: hmm, ok
  509. # [19:50] <Hixie> right, gotta go. bbl.
  510. # [19:50] <Lachy> unfortunately, very few people heavily involved with microformats actually have any experience writing good specifications.
  511. # [19:50] <webben> Hixie, although it's close
  512. # [19:50] <webben> Hixie, maybe you should just expand that a bit and link to it from #classes
  513. # [19:51] <webben> Lachy, I think that would be a good idea.
  514. # [19:51] <webben> Lachy, if you look at what XHTML2 is doing, about the only roles I have much hope for are the ones they or WAI are actually including in the spec
  515. # [19:51] <webben> if you include hcard and hcalendar UAs will be much more likely to do something useful with them
  516. # [19:51] <Lachy> are you referring to the role attribute?
  517. # [19:52] <webben> Lachy, yes
  518. # [19:52] <Lachy> oh, no.
  519. # [19:52] <Lachy> the role attribute is useless
  520. # [19:52] <webben> Lachy, I'm not sure if you're agreeing or disagreeing with me.
  521. # [19:53] * Lachy is rereading what you wrote...
  522. # [19:53] <webben> As it stands as a method of extension, role suffers the same defects as class pretty much.
  523. # [19:53] * webben wrote a long whinge to www-html about how underspecified the whole structure is.
  524. # [19:53] <webben> Lachy, but Mozilla, Orca, Window-Eyes, etc are implementing the WAI stuff.
  525. # [19:54] <webben> actually I wrote two long whinges, but the first one didn't accomplish anything
  526. # [19:54] <Lachy> most of the roles they're specifying in the specs are already covered by either new elements, link relationships or other semantics already in HTML5
  527. # [19:55] <webben> Lachy, The contrast I was drawing was between stuff in the spec and stuff not in the spec. The first has much higher status.
  528. # [19:55] <webben> And that means more implementations, which in turn makes things more useful.
  529. # [19:55] <Lachy> what name do you use in your e-mails? I can't find any e-mails in my www-html archive from you
  530. # [19:55] <webben> sorry Benjamin Hawkes-Lewis
  531. # [19:55] <webben> bhawkeslewis at googlemail
  532. # [19:56] <Lachy> ah, yes, I have those
  533. # [19:56] <webben> might also be one from benjaminhawkeslewis at hotmail
  534. # [19:56] <Lachy> @googlemail.com
  535. # [19:56] <webben> that's the one
  536. # [19:56] <Lachy> is that like gmail?
  537. # [19:56] <webben> Lachy, it's what Google have to use in UK because of a trademark dispute
  538. # [19:56] <webben> if you send to bhawkeslewis at gmail.com that will reach me too
  539. # [19:57] <Lachy> tradmark with who?
  540. # [19:57] <webben> Lachy, some tiny company offering gmail ... hold on I'll dig the link
  541. # [19:57] <webben> Lachy, http://news.bbc.co.uk/1/hi/business/4354954.stm
  542. # [20:00] <Lachy> I got into a discussion about role on the w3c-wai-ig list a few weeks ago, and the conclusion I drew from that was that all the use cases and examples they have for role, with the exception of role="search" are already covered in HTML5
  543. # [20:00] <Lachy> and role=search could be addressed by an <input type="search"> value
  544. # [20:02] <webben> Lachy, Yeah. It's really with the extension methods I'm worried about. (Especially accessibility arising there from.)
  545. # [20:02] <webben> *accessibility issues
  546. # [20:02] <webben> I have the same reservations about microformats. (I still think they're a good idea. But they worry me.)
  547. # [20:04] * webben headdesks as ffmpeg fails to build yet again.
  548. # [20:05] <webben> Role /really/ worries me though. As it's become a block to adding certain semantics, yet I can't see how those semantics are going to be accessible if extended via role.
  549. # [20:06] <webben> (It's the contrast between the "add spoiler as a role" attitude of the www-html list and the actual work going into DHTML accessibility at Mozilla that draws the starkest contrast for me.
  550. # [20:07] * ROBOd (n=robod@86.34.246.154) has joined #whatwg
  551. # [20:09] <Lachy> the problem with extending via role is that it's done using RDF. But, as far as implementations are concerned, they're still not going to be able to do anything useful with it based on that RDF, so the RDF is effectively useless
  552. # [20:10] <Lachy> plus there's the whole namespace issue as well
  553. # [20:14] <Charl> k i need to go now - have a good weekend all!!! :)
  554. # [20:14] * Charl (n=Charl@196.21.192.15) Quit ()
  555. # [20:15] <webben> Lachy, "as far as implementations are concerned, they're still not going to be able to do anything useful with it based on that RDF" ... that is /precisely/ the problem
  556. # [20:15] <Lachy> :-)
  557. # [20:16] <webben> unless they can come up with a XML description format capable of building interfaces or something it won't work
  558. # [20:16] <webben> but there doesn't seem to be any recognition of that
  559. # [20:17] <webben> (if they were sensible they might think about trying to adapt XUL or something I suppose.)
  560. # [20:17] <webben> but to work with clients varying from phones to emacs to ie
  561. # [20:17] <webben> it would probably need to be a higher-level description
  562. # [20:19] <webben> starting with some way of prioritising semantics
  563. # [20:24] * Lachy finally finished getthing through all the whatwg mail
  564. # [20:29] <ROBOd> Lachy: i am also reading the whatwg emails myself ... and i just want to tell you about something you've said
  565. # [20:29] <ROBOd> "It would be theoretically possible [to parse HTML as XHTML], but totally impractical in the real world. You can do whatever you like in your own authoring environment where you have control over exactly what goes into your documents, but XML parsing for HTML on the web is totally impractical and I really do understand the desire to do so."
  566. # [20:30] <ROBOd> the sole purpose of me wanting to have the trailing slash of was for internal stuff
  567. # [20:31] <ROBOd> *not* to parse documents in the wild, on the web. in my case, it's all about internal processing on the server and validation
  568. # [20:32] <ROBOd> desiring to do XML parsing for HTML on the web is generally silly
  569. # [20:33] <ROBOd> unless two sites, for example, have precise rules over their own content - but that's completely out of reach for the spec
  570. # [20:36] <webben> ROBOd, but this is an exchange format
  571. # [20:36] <Lachy> ROBOd, but my main points are that a) The XHTML serialisation is defined for XML processing
  572. # [20:36] <webben> isn't XML better suited for behind-the-scenes processing anyhow?
  573. # [20:37] <ROBOd> webben: internally, i find it desirable to have the same code, to parse it all as XML, and to serialize it either as XHTML or HTML.
  574. # [20:37] <ROBOd> webben: exactly, all XML internally, and out ... whatever i want
  575. # [20:38] <webben> ROBOd, well people here are talking about building a working transformer
  576. # [20:38] <Lachy> b) what you do on your own system isn't really subject to interoperability contstraints and isn't really relevant and...
  577. # [20:38] <webben> I think that makes more sense than changing the spec /just/ for that
  578. # [20:38] <ROBOd> webben: i'm rather too busy to follow all of the discussion on this channel
  579. # [20:39] <webben> ROBOd, Sorry, that wasn't meant to be accusatory... just letting you know. :)
  580. # [20:39] <ROBOd> webben: oh, i know that wasn't accusatory. i was just letting you know ;). and thanks
  581. # [20:40] <Lachy> c) because of (a) there is no reason to do (b) anyway, and allowing it at all would be harmful on the web, just like allowing XHTML as text/html has been
  582. # [20:41] <Lachy> if that doesn't make sense, keep in mind that I'm getting quite tired :-)
  583. # [20:41] <raspberry-lemon> uh, which spec change are you all talking about?
  584. # [20:41] <ROBOd> Lachy: i don't think allowing XHTML as text/html has been very bad.
  585. # [20:41] <Lachy> raspberry-lemon, the trailing slash one
  586. # [20:41] <webben> raspberry-lemon, the trailing slash /> in empty elements
  587. # [20:41] <raspberry-lemon> oh yeah
  588. # [20:42] * raspberry-lemon is really happy about that
  589. # [20:42] <webben> ROBOd, that's because (as far as I can understand) you're using a "what-works" model of authoring.
  590. # [20:42] <Lachy> ROBOd, it's been proven harmful in the last few days. If people never served XHTML as text/html, we would have never even been having this discussion about introducing XML syntax into HTML, despite it being completely usless
  591. # [20:44] <ROBOd> webben: not sure what you define as "what-works". i use almost-valid HTML4 Strict (no presentational tags, of course, with CSS, non intrusive JS sometimes), with trailing slashes for void elements (hence almost-valid code)
  592. # [20:44] <Lachy> if if we didn't even allow the XML syntax, people wouldn't even be able to process HTML5 as XML at all (unless they don't use void elements)
  593. # [20:44] <webben> ROBOd, Well. If it's "almost-valid" it's non-standard. So presumably your test is "does it work for my purposes in my test cases".
  594. # [20:44] <Lachy> the more I think about it, the more I'm really startin to like the idea to change the doctype to prevent XML parsing of HTML5 all together
  595. # [20:44] <ROBOd> webben: that is not exactly "what works" IMHO, since "what works" are those table-CSS sites, invalid, with XHTML DTD, served as text/html
  596. # [20:45] <raspberry-lemon> Lachy: it's not just about parsing, though
  597. # [20:45] <webben> ROBOd, Those only work in a very restricted testing environment.
  598. # [20:45] <Lachy> raspberry-lemon, what else is it about?
  599. # [20:45] <raspberry-lemon> a *lot* of the tools written during the last couple of years add trailing slashes for void elements
  600. # [20:45] <webben> They're pretty horrendous to maintain, modify, and use with alternative UAs.
  601. # [20:46] <webben> raspberry-lemon, yeah ... but those are for generating a different markup format.
  602. # [20:46] <ROBOd> webben: "Those", which?
  603. # [20:46] <webben> ROBOd, sorry "those table-CSS..."
  604. # [20:46] <Lachy> broken authoring tools can be fixed. They are not an excuse for introducing the syntax.
  605. # [20:47] <ROBOd> webben: oh ... well ... "those table-CSS" *do work* in todays modern UAs
  606. # [20:47] <raspberry-lemon> they won't be fixed, though
  607. # [20:47] <Lachy> a *lot* of tools add XHTML DOCTYPEs too, but that's not a major problem
  608. # [20:47] <raspberry-lemon> and people will be forced to use them for a long time
  609. # [20:47] <webben> ROBOd, Except they don't. Indeed, people need new tools just to get around the breakage. e.g. to linearize tables.
  610. # [20:48] <ROBOd> webben: they are patched sooo much until they work ... more or less ... as intended by the (confused) author
  611. # [20:48] <webben> ROBOd, As authors don't test with odd UAs or odd UA configurations, breakages are not notices and no fixes are made
  612. # [20:49] <ROBOd> webben: true
  613. # [20:49] <Lachy> raspberry-lemon, new tools are being developed to support HTML5 properly. There's already a validator well under development, I'm in the process of writing a CMS that will author in XHTML and serialise as HTML5, and plenty of parsers are being written
  614. # [20:50] <ROBOd> webben: nonetheless, it doesn't compare to what i do :P. i don't do ... patching ... i don't do guess work. except for the guess work I do with IE6+ CSS rendering
  615. # [20:50] <webben> ROBOd, I wasn't trying to say that your techniques were that intrinsically broken. (I wouldn't have allowed them the label "what works" if I thought that.)
  616. # [20:51] <webben> ROBOd, but I'd put all non-standards authoring in a different camp to standards-based authoring.
  617. # [20:51] <webben> non-standards authoring /can/ work in most cases ... can even be generally accessible ... I just think it's much more risky and fragile.
  618. # [20:52] <ROBOd> webben: my definition of "what works" is ... quite bad... "intrinsically broken"
  619. # [20:52] <webben> ah okay
  620. # [20:52] <webben> we're operating from slightly different definitions then :)
  621. # [20:52] <ROBOd> hehe
  622. # [20:53] <ROBOd> webben: what hsivonen has defined as bozos ... somehow is too general, IMHO
  623. # [20:53] <webben> ROBOd, I suppose what I would object to (however futilely) is your use of a doctype.
  624. # [20:53] <ROBOd> since he wants everyone to use a complete parser, serializer, server-side DOM for everything the web app outputs
  625. # [20:54] <webben> ROBOd, I think doctypes should really be approached as contracts rather than hacks to force one or another type of CSS rendering.
  626. # [20:54] <webben> ROBOd, ah ... I'd probably agree with him there.
  627. # [20:55] <webben> ROBOd, I think such systems would ultimately be better safeguards for content.
  628. # [20:55] <ROBOd> doing what hsivonen suggests is technically excellent, but cannot be expected to be done with small web apps, with small web sites, by beginners, or even by experts in small stuff
  629. # [20:55] <webben> ROBOd, Oh I think it can. But as with absolutely everything in this industry ... nobody's built the requisite tools
  630. # [20:56] <ROBOd> webben: i agree, they'd be ultimately better ... but doesn't that add lot of work? currently
  631. # [20:56] <ROBOd> specialised tools, libraries ... can make things much easier, but they are not yet available
  632. # [20:56] <webben> ROBOd, Yes. I don't mean to imply that I expect every webdev to invent this wheel by themselves.
  633. # [20:57] <ROBOd> and those who don't ... are not bozos :)
  634. # [20:57] <webben> (not least because I'd be guilty of patent hypocrisy)
  635. # [20:57] <ROBOd> some of them *are* bozos, but not all
  636. # [20:57] <webben> I just think that's what we need to be working towards collectively.
  637. # [20:57] <ROBOd> yes
  638. # [20:58] <webben> After all we already have tools and libraries that abstract away other (arguably more complex) spheres and make them appear simple
  639. # [20:58] <ROBOd> agreed
  640. # [20:59] <webben> The tragedy is the current set of tools borrowed the UI of word processors (which maps poorly to the web) but not their rigid approach to the document format.
  641. # [21:12] <Lachy> I can't belive what sam has just written here. :-( http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
  642. # [21:25] <Hixie> ok. change of policy. while i'm still going to reply to all the feedback sent to whatwg@whatwg.org, when people are just replying to other people and not making any actual suggestions, i'm not even going to pretend to intend to reply to them.
  643. # [21:25] <webben> argh "if documents bodies which were simultaneously both valid HTML5 and valid XHTML5"
  644. # [21:25] <Lachy> I thought you had that policy already
  645. # [21:26] <Hixie> yeah i guess i did
  646. # [21:32] <Lachy> Hixie, which browsers have trouble with a slash immediately following an empty attribute?
  647. # [21:32] <Lachy> if any?
  648. # [21:32] <Hixie> Lachy: oops, i was confused
  649. # [21:33] <webben> Is there any chance of getting back numbering attributes for lists?
  650. # [21:33] <Hixie> aren't they already there?
  651. # [21:34] <Lachy> which ones? start="" and value="" or type="a"?
  652. # [21:34] <webben> i was looking at 3.9.1 for ol
  653. # [21:34] <webben> all i see is start
  654. # [21:34] <Lachy> <li value="">
  655. # [21:34] <webben> i mean an attribute to specify decimal vs alphabetic vs roman whatever
  656. # [21:34] <Lachy> ah, the type attribute
  657. # [21:34] <Hixie> that's in CSS
  658. # [21:35] <Lachy> the only problem with having the number format in CSS is tha it makes it difficult to refer to an item by number.
  659. # [21:35] <webben> Exactly.
  660. # [21:35] <webben> Which breaks e.g. legal documents
  661. # [21:36] <webben> As i mentioned in my post to the list on annotations
  662. # [21:36] <Lachy> e.g. to say "see point 1.a. in the list"
  663. # [21:36] <Lachy> because, without stylesheets, that a. will default to decimal (or other browser config)
  664. # [21:36] <webben> Nothing terribly wrong with having CSS change these things ... but it should definitely be possible to be part of the markup semantics
  665. # [21:37] <webben> (same problem arises with notes)
  666. # [21:37] <webben> or indeed anything else you might want to count
  667. # [21:38] <webben> Lachy, is this "type" attribute in the HTML5 spec at all, or was that what it was called in old HTML?
  668. # [21:38] <Lachy> it was deprecated in HTML4 and it has not been added to HTML5
  669. # [21:39] <webben> I see.
  670. # [21:39] <webben> that's bad.
  671. # [21:40] <Hixie> eh
  672. # [21:40] <Hixie> there isn't that much need for it
  673. # [21:40] <Hixie> i agree there are edge cases like legal docs where it has arguably good use cases
  674. # [21:40] <webben> I fail to see how legal docs are an edge case. They do exist on most websites.
  675. # [21:41] <Hixie> yeah but nobody reads them
  676. # [21:41] <Hixie> so who cares :-)
  677. # [21:41] <webben> (i was about to admit that nobody reads them ;)
  678. # [21:41] <Hixie> and most legal documents you read don't actually refer to specific sections so much
  679. # [21:41] <webben> Hixie, eh? yes they do
  680. # [21:41] <webben> at least when i read statutes they do.
  681. # [21:41] <Hixie> not most legal docs
  682. # [21:41] <Hixie> statutes do, sure
  683. # [21:42] <Hixie> but those are the edge case
  684. # [21:42] <Lachy> but the way to make a reference in HTML is to use <a href="#section">
  685. # [21:42] <Hixie> yeah
  686. # [21:42] <Hixie> there needs to be better support for this
  687. # [21:42] <Hixie> but type="" isn't it, imho
  688. # [21:42] <webben> Lachy, yes but such documents have a deadtree serialization
  689. # [21:42] <webben> so do books with numbered sections ... etc etc
  690. # [21:42] <Hixie> css print should for sure support references for that
  691. # [21:43] <webben> But not everything uses CSS.
  692. # [21:43] <webben> so you end with a discrepancy.
  693. # [21:43] <Lachy> has there been any proposals to handle that use case in CSS?
  694. # [21:43] <webben> I don't see how CSS could handle it.
  695. # [21:43] <webben> Given that CSS is not an essential part of documents.
  696. # [21:44] <Lachy> CSS handles the number style, so it should also handle the reference style
  697. # [21:44] <webben> ah I see what you mean
  698. # [21:44] <webben> But it can't magically make all representations the same.
  699. # [21:45] <Lachy> not yet, but a solution might be found one day
  700. # [21:45] <webben> Or we could use something that's already implemented.
  701. # [21:46] <webben> Given the whole point of CSS is separation I don't see how such a solution would work.
  702. # [21:46] <webben> Because any solution would involve breaking that separation.
  703. # [21:47] <webben> Now one might, it's true, want to change how things are numbered universally. But I think that's a job for transformation tools. /Not/ CSS.
  704. # [21:48] <webben> fixing <ul><li>2.i And as specified in 4.1 [...] </li> [...] </ul> is going to be pretty messy
  705. # [21:48] <Hixie> <ul><li>2.i And as specified <a href="#4i">below</a> [...] </li> [...] </ul>
  706. # [21:48] <Hixie> ...with generated content in CSS
  707. # [21:49] <webben> I still think that's the wrong solution :(.
  708. # [21:55] <webben> did anyone happen to have any thoughts on the feasibility of noteset ?
  709. # [21:55] <webben> I hadn't really been thinking in terms of backwards compatibility
  710. # [21:55] <Lachy> what's noteset?
  711. # [21:56] <webben> sorry, this was in my post on annotations
  712. # [21:56] <Lachy> I don't remember it, maybe it was one that I skipped
  713. # [21:56] <webben> it needs more refinement no doubt, i'm just wondering about the technical possibilities
  714. # [21:56] * Hixie has been shunting all annotation discussion into a folder to be opened much later :-)
  715. # [21:57] <Hixie> i'm trying to get to feature freeze for HTML5 here :-P
  716. # [21:57] <Hixie> and people keep suggesting new things :-P
  717. # [21:57] <webben> Hixie, are you serious? I wasn't aware you were seeking a feature freeze
  718. # [21:57] <webben> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008190.html
  719. # [21:58] <webben> i suppose "Complex annotations" wasn't exactly a subject title likely to pull in the readers
  720. # [21:58] <Lachy> webben, we have to get to feature freeze somewhere, or it'll never get finished
  721. # [21:58] <Hixie> i'm trying to reach feature freeze by december 31st so that the spec can then be cleaned up and completed before the w3c can get their act together
  722. # [21:58] <webben> a fait accompli
  723. # [21:58] <Hixie> so that if they do end up screwing us over, we at least have one stable spec to hang our hats on
  724. # [21:58] <webben> why not just finish WF2 ?
  725. # [21:59] <Hixie> WF2 is part of HTML5
  726. # [21:59] <webben> rather than HTML5 as a whole
  727. # [21:59] <Hixie> and is basically done already
  728. # [21:59] <webben> oh, I thought the idea was to have WF2 first then WA1 later
  729. # [21:59] <Hixie> it is
  730. # [21:59] <Hixie> WF2 is done :-)
  731. # [21:59] <Hixie> it's already a W3C spec and everything
  732. # [21:59] <Lachy> When will WF2 be merged into the WA1 document?
  733. # [21:59] <Hixie> dunno
  734. # [21:59] <Hixie> depends what happens with wf2 at w3c
  735. # [22:00] <Hixie> probably in january
  736. # [22:00] <Lachy> ok
  737. # [22:00] <Hixie> but maybe on monday :-)
  738. # [22:00] <webben> it's still wd on the w3c site
  739. # [22:00] <Lachy> that's just going to make the whole spec twice as big as it currently is
  740. # [22:00] <Hixie> webben: yeah, it won't go any further for a while, w3c is slow.
  741. # [22:00] <Hixie> Lachy: yeah, tell me about it
  742. # [22:01] <hsivonen> ROBOd: I haven't defined anyone as a bozo. Tim Bray has. I provide advice on avoiding that label.
  743. # [22:01] <webben> heh
  744. # [22:01] <Hixie> hey hsivonen, what's the name of the relax ng syntax that isn't xml?
  745. # [22:02] <hsivonen> Hixie: RELAX NG Compact Syntax (.rnc)
  746. # [22:02] <Hixie> ta
  747. # [22:03] <hsivonen> ROBOd: http://hsivonen.iki.fi/validator/ does not have a server-side DOM. It has a SAX pipeline with XHTML internally and an HTML5 serializer at last opportunity
  748. # [22:03] <hsivonen> ROBOd: my advice says stack or a tree
  749. # [22:03] <hsivonen> ROBOd: and the runtime stack can be the stack
  750. # [22:06] <webben> I keep trying to do these things with XSLT. Maybe that's my problem.
  751. # [22:06] <webben> Maybe I should be trying to learn Sax instead.
  752. # [22:06] <Hixie> oh lordy
  753. # [22:07] <Hixie> to paraphrase someone whose name i forget: some people, when faced with a problem, think they'll use xslt. now they have two problems.
  754. # [22:07] <Lachy> :-D
  755. # [22:07] <webben> Well XSLT is horrible to begin with. What's worse is all the XSLT processors seem to apply the same instructions differently.
  756. # [22:08] <Hixie> (oh yes, that was jwz and regexps)
  757. # [22:08] <Lachy> is your problem with XSLT the fact that its incredibly complex, difficult to learn, difficult to use and just badly designed?
  758. # [22:08] <Hixie> yes
  759. # [22:08] <Hixie> oh sorry, was i supposed to pick just one?
  760. # [22:08] <Lachy> no, all of the above is fine
  761. # [22:09] <Hixie> tantek can criticise xslt much better than i can
  762. # [22:10] <webben> when you're trying to manipulate and output xslt, do folks find sax makes them happy? Or is just another form of hell?
  763. # [22:10] <webben> *xml not xslt
  764. # [22:11] <webben> how similar are the implementations for example
  765. # [22:11] <Hixie> never used sax myself
  766. # [22:11] <Hixie> then again, i've never output xml from anything but a tree
  767. # [22:11] <Hixie> as far as i recall
  768. # [22:11] <Lachy> I'm working with sax at the moment to implement in my CMS. I'm finding it very easy to work with
  769. # [22:11] * mpt (n=mpt@121-72-128-96.dsl.telstraclear.net) has joined #whatwg
  770. # [22:11] <hsivonen> webben: some things are extremely easy in SAX and complicated with trees. some things are complicated in SAX and easy in trees
  771. # [22:12] <tantek> xslt has very poor performance characteristics for any realtime (read: human) applications
  772. # [22:12] <webben> What does it have /good/ performance characteristics for?
  773. # [22:13] <tantek> unknown
  774. # [22:13] <Lachy> when you want to transform some XML into another format, what tool do you recommend instead of XSLT?
  775. # [22:14] <Hixie> actually yeah, performance is the reason google stopped using xslt on at least one of our products
  776. # [22:14] * hsivonen notes that http://hsivonen.iki.fi/validator/html5/ uses an XSLT engine behind the scenes for some stuff, but if it becomes a performance problem, it can be replaced with a hand-written SAX checker once the spec is stable
  777. # [22:16] * webben seems to remember trying to implement a simple XSLT in Ruby and it taking like 4 seconds per request.
  778. # [22:16] <webben> can't remember which Ruby library I was using
  779. # [22:16] <Hixie> can someone think of any non-HTML-related examples of people using the wrong tool for a job?
  780. # [22:16] <webben> presumably one of the pretty but slow ones
  781. # [22:17] <webben> Hixie, do you mean w/in the field of programming or just generally in life?
  782. # [22:17] <Hixie> either
  783. # [22:17] <hsivonen> Hixie: just about any formal language wrangling by a person who has never heard of parser generators
  784. # [22:18] <hsivonen> (yeah, yeah, I have a hand-written parser, but I did analyze using Antlr, SableCC and JavaCC first)
  785. # [22:18] * webben spent ages implementing a parser for the Accept header once, proved more complicated than I expected.
  786. # [22:19] <webben> Then I discovered a decent Ruby lexing tool ... but that was of course too poorly documented for a newbie like me to actually use
  787. # [22:20] <webben> somewhere around that point i gave up and went looking for a language with decent unicode support built in
  788. # [22:21] <webben> Wrong tools. I suppose politics furnishes /loads/ of examples. Unfortunately people are unlikely to agree on which ones are the examples.
  789. # [22:21] <hsivonen> Hixie: using Word for graphics
  790. # [22:21] <webben> ah yeah
  791. # [22:21] <webben> good example
  792. # [22:22] <webben> for most stuff ... paper forms in offices
  793. # [22:22] <Lachy> hsivonen, using Word. period. ;-)
  794. # [22:22] <webben> especially the ones where you employ teams of people to copy the paper forms onto broken database systems
  795. # [22:23] <webben> most office work is a case of the wrong tools actually
  796. # [22:24] <webben> because it all involves this doubling up of deadtree/software solutions which manages to rob both of their benefits
  797. # [22:24] <Hixie> hmm
  798. # [22:24] <webben> plus office politics is not exactly a productive force
  799. # [22:25] <webben> Excel for databases
  800. # [22:25] <webben> that's quite a common one
  801. # [22:25] <Hixie> your paper example made me think of people using books as paperweights
  802. # [22:25] <Hixie> which is the ideal example for my e-mail
  803. # [22:25] <webben> cool :)
  804. # [22:27] <webben> People watching sports on teletext.
  805. # [22:27] <webben> s/People/Brits/ s/sports/cricket/
  806. # [22:28] * mpt (n=mpt@121-72-128-96.dsl.telstraclear.net) Quit ("This computer has gone to sleep")
  807. # [22:42] * Lachy doesn't understand the paper weights analogy in the e-mail
  808. # [22:43] <webben> HTML is not meant to be parsed as XML. Books are not meant to be used as paperweights.
  809. # [22:44] <webben> (main problem with this is that you should never parse XML as HTML, whereas one may use books as paperweights)
  810. # [22:44] <webben> but it's still funny
  811. # [22:44] <Lachy> It's this sentence that I have the most trouble with:
  812. # [22:44] <Lachy> What you are asking is equivalent to asking bookmakers to make their books heavier and less prone to opening in air currents, because then they would be better paperweights.
  813. # [22:45] <Lachy> specifically, the last bit
  814. # [22:45] <webben> Lachy, because if they open then they catch the air and get pulled away
  815. # [22:45] <webben> and hence cease to be effective paperweights
  816. # [22:47] <Lachy> but the first part says "... make their books heavier and less prone to opening..." and the second part says "... then they would need better paperweights" That just doesn't make sense to me
  817. # [22:47] <webben> eh?
  818. # [22:48] <webben> "because then they would be better paperweights" is the imputed reasoning behind asking bookmakers to ...
  819. # [22:48] <webben> where are you getting "need" from?
  820. # [22:48] <Lachy> if the books are heavier, then there is no need for paperwieghts
  821. # [22:48] <Lachy> maybe it's just the way it's been written, I just don't get it.
  822. # [22:48] <webben> Lachy, I think Hixie means books used to hold other papers down.
  823. # [22:49] <Lachy> oh, wait, I get it now!
  824. # [22:49] <webben> Lachy, if the books are heavier then they are worse books
  825. # [22:49] <webben> :)
  826. # [22:49] <Lachy> I've been misreading it all this time
  827. # [22:50] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) has joined #whatwg
  828. # [22:51] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) Quit (Client Quit)
  829. # [22:51] <Lachy> I misread it as "then they would NEED better paperweights", rather than "... BE better paperweights"
  830. # [22:51] * Kanashii (n=Kanashii@ppp108-141.lns2.bne4.internode.on.net) has joined #whatwg
  831. # [22:52] <webben> ah
  832. # [22:58] <Lachy> added a new question about trailing slashes. (second last question) http://blog.whatwg.org/faq/
  833. # [23:12] <hsivonen> looks like Sam is interested in the parsing side after all
  834. # [23:14] <raspberry-lemon> Lachy: nice
  835. # [23:14] <Lachy> he seems to be interested in making XML usable as tag soup and tag soup usable as XML. It just doesn't make sense to me.
  836. # [23:16] <raspberry-lemon> as happy as i am about the /> syntax being allowed, i see the point about making sure people understand that it's not necessary, useful or even a good idea
  837. # [23:16] <gsnedders> just a quick question: "For a spec to become a REC, it requires two 100% complete and fully interoperable implementations" - does any implementation count, or only one that has a large user base?
  838. # [23:17] <hsivonen> gsnedders: any
  839. # [23:17] <gsnedders> hsivonen: right. thanks.
  840. # [23:18] <Lachy> the proposed charter for the new HTMLWG in the W3C said of at least 10% market share each, I think. I'm not sure how realistic that is, though.
  841. # [23:18] <hsivonen> gsnedders: assuming that it is shipping (not beta) and available to public to acquire a copy of
  842. # [23:18] <Lachy> http://www.w3.org/2006/11/HTML-WG-charter.html
  843. # [23:18] <raspberry-lemon> wow, i don't see that happening at all
  844. # [23:18] * ROBOd (n=robod@86.34.246.154) Quit ("good night all")
  845. # [23:19] <Lachy> perhaps, in 15 years time, when this is even close to becoming a rec, IE won't hold such a monopoly and the major browsers will have around 20% to 30% each
  846. # [23:21] <hsivonen> any public data on what opinion Howcome and Brendan have on the HTML WG charter?
  847. # [23:25] <webben> what defines the market
  848. # [23:25] <webben> e.g. maybe IE isn't in the market for XHTML5
  849. # [23:29] <webben> (just as it isn't in the market for TEI)
  850. # [23:29] <raspberry-lemon> what's TEI?
  851. # [23:30] <Lachy> webben, I think they would be. They're planning to implement XHTML in IE8 and, it's likely that they'll also follow Moz, Opera and Safari implementations
  852. # [23:30] <Lachy> TEI = Text Encoding Initiative
  853. # [23:30] <raspberry-lemon> ah :)
  854. # [23:30] <Lachy> it's an XML format, that's all I know.
  855. # [23:33] <webben> If we don't count /beta/ implementations, how can we count /planned/ implementations?
  856. # [23:37] <Hixie> "Does HTML allow the use of the empty element syntax from XML on void elements?" is not a frequently asked question. :-)
  857. # [23:37] <webben> heh
  858. # [23:37] <Hixie> "Is it <img/> or is it <img> that is right?" might be
  859. # [23:37] <webben> "Should I close empty elements with /> or > ?"
  860. # [23:38] <Hixie> or that, yeah
  861. # [23:38] <Lachy> that's a better way of asking it
  862. # [23:39] <Lachy> updated.
  863. # [23:40] <Hixie> i love how you're filling in the faq from the bottom up :-)
  864. # [23:41] <Hixie> in general you might want to consider how the faq sounds to newbies who have no idea what you're talking about
  865. # [23:41] <Lachy> I know, that's why I want feedback from more people
  866. # [23:41] <Hixie> e.g. "No, absolutely not." sounds a bit pompous to a newbie :-)
  867. # [23:41] <Lachy> ok
  868. # [23:42] <Lachy> I'm trying to answer the first question now, though
  869. # [23:42] <Lachy> What is the WHATWG and why did it form?
  870. # [23:42] <Hixie> hm
  871. # [23:42] <Hixie> tough one
  872. # [23:43] <Hixie> these days it's a community, i guess
  873. # [23:43] <raspberry-lemon> i mentioned whatwg and html in another channel and was met with "oh no not another bunch of w3 wannabes" :/
  874. # [23:43] <raspberry-lemon> s/html/html5
  875. # [23:43] <Hixie> and it formed when mozilla, opera, and apple got together after the web apps and compound documents workshop and said "what?!" to the response from the w3c
  876. # [23:44] <Hixie> raspberry-lemon: heh
  877. # [23:45] <Hixie> the w3c having said "XForms and XHTML2 are going to replace HTML4"
  878. # [23:45] <Lachy> newbies aren't going to know what the web apps and compound documents workshop is
  879. # [23:45] <Hixie> it formed "after a W3C Workshop in 2004"?
  880. # [23:45] <Hixie> you can then link that to the page for that workshop
  881. # [23:45] <webben> You could summarise the cause of the split
  882. # [23:46] <webben> -- need for backwards compatibility + namespaces + ??
  883. # [23:46] <Hixie> if i knew the cause of their madness...
  884. # [23:46] <webben> well from your POV obviously
  885. # [23:46] * mpt (n=mpt@121-72-128-96.dsl.telstraclear.net) has joined #whatwg
  886. # [23:46] <webben> or maybe not present it as a split at all
  887. # [23:46] <hsivonen> http://ln.hixie.ch/?start=1086387609&count=1
  888. # [23:47] <webben> just emphasize that you're creating a spec with a given set of aims
  889. # [23:47] <hsivonen> http://www.w3.org/2004/04/webapps-cdf-ws/minutes-20040601.html
  890. # [23:47] <hsivonen> http://www.w3.org/2004/04/webapps-cdf-ws/minutes-20040602.html
  891. # [23:47] <hsivonen> (from the .bib for my thesis)
  892. # [23:48] <webben> hsivonen, you're writing a thesis about the split?
  893. # [23:48] <Hixie> that was a weird meeting
  894. # [23:48] <Hixie> Sun, Microsoft, Opera, and Mozilla were agreeing
  895. # [23:48] <Hixie> and everyone else was telling us we were on crack
  896. # [23:48] <Hixie> and we were all like "uh hello"
  897. # [23:48] <hsivonen> webben: no. about the conformance checking service.
  898. # [23:48] <hsivonen> webben: but I am expected to explain the context of the work
  899. # [23:48] <Hixie> "it's SUN and MICROSOFT and MOZILLA and OPERA agreeing here. You cannot FIND four companies that are LESS LIKELY to agree with each other"
  900. # [23:49] <Hixie> "this should tell you something"
  901. # [23:49] <hsivonen> webben: that is, what and why this HTML5 thing is
  902. # [23:51] <Hixie> my favourite part of that meeting, though, was when someone said "But we all agreed that HTML was dead back at the Future of HTML meeting in 1998!"
  903. # [23:51] <Hixie> and I replied "well I can't speak to that, I was still in high school in 1998"
  904. # [23:55] <Hixie> well Lachy, i'm afraid that my solution to the "Classes" section was to drop the section for now.
  905. # [23:56] <Lachy> ok
  906. # [23:56] <Hixie> we really just need to drop profile=""
  907. # [23:56] <Lachy> yes, agreed
  908. # [23:56] <webben> Why?
  909. # [23:56] <Hixie> and switch to first-come-first-served class semantics registration on the wiki
  910. # [23:56] <Lachy> because no-one uses it
  911. # [23:56] <webben> dc metadata
  912. # [23:56] <webben> lots of people use dc
  913. # [23:56] <Hixie> most people using dc metadata do not give the profile="" attribute (I checked)
  914. # [23:56] <hsivonen> webben: in theory. not as practiced
  915. # [23:56] <Lachy> no-one uses it for any real purpose
  916. # [23:56] <webben> is dc on the wiki?
  917. # [23:56] <webben> if not, it needs to be
  918. # [23:56] <Lachy> why?
  919. # [23:57] <Lachy> what tools actually do anything useful with such metadata?
  920. # [23:57] <Hixie> classes aren't yet in the wiki :_)
  921. # [23:57] <Lachy> why should authors bother with it?
  922. # [23:57] <Hixie> when they are, i'm sure dc people will register the dc types
  923. # [23:57] <hsivonen> Lachy: shh. inconvenient question. :-)
  924. # [23:58] <Hixie> hah
  925. # [23:58] <webben> Lachy, There are tools for such metadata. There's an extension for Firefox.
  926. # [23:58] <webben> (whether it checks profile or not I have no idea)
  927. # [23:58] <Hixie> heh, the defined-classes section was dropped in rev 404
  928. # [23:58] <webben> it's the same with microformats
  929. # [23:58] <Lachy> I really don't understand dc. I leared about it back in school and again in uni, but have yet to find anything that it's actually useful for
  930. # [23:58] <webben> Lachy, Are you a librarian?
  931. # [23:58] <Lachy> no
  932. # [23:58] <Lachy> do librarians actually use it?
  933. # [23:59] <Hixie> surprisingly many people actually specify DC data
  934. # [23:59] <Hixie> dunno if anyone makes use of it
  935. # [23:59] * gsnedders cuts in… DC meaning Dublin Core?

The end :)