/irc-logs / w3c / #html-wg / 2007-04-23 / end

Options:

  1. # Session Start: Mon Apr 23 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:38] * Quits: Deeder (Deeder@86.198.254.100) (Client exited)
  4. # [00:41] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
  5. # [00:44] * Joins: h3h (bfults@66.75.149.197)
  6. # [01:02] <xover> hsivonen: "having the best solution already" _is_ the issue.
  7. # [01:06] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  8. # [01:08] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
  9. # [01:26] * Joins: heycam (cam@130.194.72.84)
  10. # [01:33] * Parts: hasather (hasather@81.235.209.174)
  11. # [01:36] <gavin> xover: are you saying that it's impossible for the whatwg to have found the best solutions for a given problem?
  12. # [01:39] <gavin_> note: that isn't to say that any solution is set in stone
  13. # [01:40] <Zoffix> I think he ment that there is always room for improvement.
  14. # [01:42] <gavin_> has anyone argued that there isn't? :)
  15. # [01:49] * Joins: karl (karlcow@128.30.52.30)
  16. # [01:55] * Joins: kazuhito (kazuhito@210.232.34.13)
  17. # [02:00] <Hixie> gsnedders: according to my research, about 0.0014% XHTML is served as XML
  18. # [02:00] <Hixie> (iirc)
  19. # [02:12] <zcorpan> is that counting text/html pages with known xhtml doctypes as "xhtml"?
  20. # [02:13] <zcorpan> or <html xmlns>?
  21. # [02:15] <Lachy> zcorpan, he said "served as XML", so it would seem that it doesn't include text/html pages
  22. # [02:15] * Quits: olli- (olli@80.203.95.229) (Ping timeout)
  23. # [02:16] <zcorpan> Lachy: he said 0.0014% of "xhtml" is served as xml
  24. # [02:16] <Hixie> that's just pages served with an XML MIME type, not text/htlm
  25. # [02:16] <zcorpan> what's the rest?
  26. # [02:16] <zcorpan> ah
  27. # [02:17] <Hixie> let me rephrase that
  28. # [02:17] <Hixie> it's not 0.0014% of xhtml
  29. # [02:17] <zcorpan> then 0.0014% of xml is xhtml
  30. # [02:18] <Lachy> I took it as meaning 0.0014% of pages on the web are served as XML
  31. # [02:19] <karl> what is |page on the Web|?
  32. # [02:19] <xover> gavin: I'm saying the attitude that they have the best solution already is what makes people reticent.
  33. # [02:20] <karl> family of XHTML + HTML ? (excluding RSS for example)
  34. # [02:20] <Lachy> that's what I assumed
  35. # [02:23] * zcorpan awaits clarification
  36. # [02:29] <gavin_> xover: ah, that I can understand. I don't think that is a concern unless people think that "they" are unreasonable and unable to objectively consider different opinions.
  37. # [02:29] <karl> http://krijnhoetmer.nl/irc-logs/html-wg/20070422#l-225
  38. # [02:29] <karl> big problem with this hack
  39. # [02:30] <karl> because it relies on a lack of strictness of a browser
  40. # [02:30] <karl> which means if/when the browser is fixed. the hack doesn't work anymore.
  41. # [02:32] * zcorpan has configured his registry to make application/xhtml+xml equivalent to application/xml, so their hack doesn't work for me
  42. # [02:34] <zcorpan> the page displays in ie but it's treated as generic xml, thus no default styles, no links, no extracted semantics or anything
  43. # [02:34] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  44. # [02:38] <Lachy> that hack of theirs doesn't even work in IE7
  45. # [02:38] <Lachy> only IE6
  46. # [02:40] * Joins: gavin_ (gavin@74.103.208.221)
  47. # [02:40] <zcorpan> so, if the url ends in .html and there's a <meta charset>, then ie6 will treat it as text/html? correct?
  48. # [02:40] <Lachy> somehow I'm not particularly surpirsed that the XHTML2 WG's conclusion isn't something like "IE doesn't support XHTML, we should provide an HTML alternative", but rather "IE doesn't support XHTML natively, what bugs can we exploit to work around it and maintain our illusion that XHTML can be used on the web?"
  49. # [02:41] * Joins: anne5 (annevk@203.17.70.52)
  50. # [02:44] <zcorpan> can someone translate matthew's last email?
  51. # [02:46] <Lachy> the one that starts with "Dan who?"?
  52. # [02:46] <anne5> "important work by the SVG WG"?
  53. # [02:46] <anne5> guess they haven't published that yet
  54. # [02:46] * anne5 hides
  55. # [02:46] <zcorpan> "Yeah, Dave Hyatt is just going to have to realize that because of his participation in the Conspiracy of Light back on Babylon 5, his career in the Earth Alliance military is over."
  56. # [02:47] * heycam looks behind couches and in cupboards :)
  57. # [02:47] <zcorpan> http://www.w3.org/mid/462C01C7.8070903@earthlink.net
  58. # [02:47] <Lachy> oh right, just received it
  59. # [02:48] <Lachy> I think it was supposed to be a joke
  60. # [02:49] * zcorpan doesn't understand the joke
  61. # [02:49] <zcorpan> but i'll leave it at that
  62. # [02:53] <zcorpan> is the former intended to refer to whatwg, and the latter to apple/safari?
  63. # [02:53] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  64. # [02:59] <Philip`> I'm thinking it means 'because of his participation in the WHATWG, his career in the HTML WG is over' (since it was in a response to a comment that sort of (but not really) disagreed with having Dave due to his past WHATWG involvement). But I don't think it's the greatest example of clear communication
  65. # [03:00] <zcorpan> ah, right
  66. # [03:00] <zcorpan> and indeed
  67. # [03:01] <anne5> if that's a policy that should also go for all people who gave us HTML4 :p
  68. # [03:02] <Lachy> right, because we don't want people with actual experience working on this spec do we? :-)
  69. # [03:03] <anne5> ok, HTML4 might be a bad example
  70. # [03:03] <anne5> if you put it like that
  71. # [03:04] <Lachy> acutally, anne5, I was responding to the general idea of not having Dave work on the spec, not your comment about HTML4 editors
  72. # [03:06] <anne5> I don't really like the editor thread at all... People are just complaining a bit without actually finding proper solutions
  73. # [03:06] <karl> maybe, some people are expressing concerns because it is another browser persons for editing. Concerns are always interesting they express feelings from one part of the community.
  74. # [03:06] <anne5> Maybe I'm too practical
  75. # [03:06] * Lachy wonders why people refuse to take a spec seriously unless it has a W3C logo on it (see www-html)
  76. # [03:07] <Dashiva> Because everyone knows xhtml2 is much more useful in the real world than quirks mode html
  77. # [03:07] <anne5> Because everyone uses e-mail which was specced by ...
  78. # [03:08] <karl> anne5, Lachy, there is something you keep forgetting. it is a question of community, or more exactly communities.
  79. # [03:08] <karl> being practical is a good way for doing work, not for juding, or you will hit the social interactions wall quite fast.
  80. # [03:08] <anne5> karl, I find it really hard to understand what you keep saying in this channel now and then
  81. # [03:08] <Lachy> right, and the WHATWG community is much larger and has more involvement from the community than many W3C specs
  82. # [03:09] <anne5> fwiw
  83. # [03:09] <Hixie> zcorpan: sorry, my battery ran out mid-conversation and i had to go home to get power again!
  84. # [03:09] <anne5> anyway, time to travel for 30-35 hours... yay
  85. # [03:09] <Hixie> zcorpan: it was 0.0014% of pages that I surveyed used an XML MIME type
  86. # [03:09] <karl> Lachy: the whatwg mailing list is one view.
  87. # [03:09] <zcorpan> Hixie: ok, thanks
  88. # [03:10] <zcorpan> so the amount of xhtml on the web is a subset of that
  89. # [03:11] <karl> anne5: :)
  90. # [03:11] <Hixie> yeah
  91. # [03:11] <Hixie> zcorpan: about 15% of pages had xmlns="...xhtml" attributes on the <html> element
  92. # [03:12] <h3h> wow, higher than I'd expect
  93. # [03:12] <karl> Hixie: did the sample contain the RSS feed? or just html/xhtml type (with the bias on what is a real html/xhtml)
  94. # [03:12] <Hixie> and about 50% had doctypes of any kind
  95. # [03:12] <karl> s/feed/feeds/
  96. # [03:12] <Hixie> karl: i believe i specifically excluded RSS, but i'd have to go to work to check
  97. # [03:12] <karl> ok thanks
  98. # [03:12] <Hixie> it's hard to tell what is one or the other, in practice
  99. # [03:13] <Hixie> (q.v. the algorithm in the html5 spec)
  100. # [03:13] <karl> yes it's what I thought too :/
  101. # [03:13] <h3h> google doesn't index feeds though, does it?
  102. # [03:14] * Quits: anne5 (annevk@203.17.70.52) (Ping timeout)
  103. # [03:14] <h3h> and even so, .0014% seems low if it includes feeds
  104. # [03:14] <Hixie> most feeds are served as text/plaoin or text/html
  105. # [03:14] <h3h> heh. nice
  106. # [03:16] <h3h> Hixie: how feasible is it to be hired into your "team" at Google?
  107. # [03:17] <karl> http://www.google.com/intl/en/jobs/index.html
  108. # [03:17] <h3h> yeh, no open req for "work with Hixie on HTML5"
  109. # [03:17] <Hixie> heh
  110. # [03:17] <h3h> and I sincerely doubt there ever will be
  111. # [03:17] <h3h> that's the kind of job you have to grease your way into
  112. # [03:18] <karl> h3h: if you have the desire to work for Google in the first place. But that's another topic ;)
  113. # [03:18] <h3h> oh I do indeed have that desire :)
  114. # [03:18] <karl> plus the fact that you can easily contribute publicly to this work
  115. # [03:18] <h3h> "easily" is relative
  116. # [03:19] <h3h> especially when working a more-than-full-time job
  117. # [03:19] <zcorpan> hi! html5 is teh coolest shit!! i want to work with hixie at google so i can make up tags
  118. # [03:19] <Hixie> yeah if you want to be paid by google to work on this stuff, i recommend going about it the way i did
  119. # [03:19] <karl> h3h: yes it takes time
  120. # [03:19] <Hixie> that is, spend years working with browser vendors, writing tests, working with working groups, etc
  121. # [03:19] <h3h> and start your own working group to fill the gaps in the web :)
  122. # [03:20] <xover> Or just send `em a resume; at the rate they're amassing employees... :-)
  123. # [03:20] <h3h> indeed
  124. # [03:21] <Zeros> That's just what we need... another WHATWG for every person seeking employment by Google
  125. # [03:22] <h3h> haha
  126. # [03:24] <xover> karl: You may want to point yod at mjs' <http://www.w3.org/mid/0D0B632E-9F51-4953-A87B-19A6F89DBE6F@apple.com>.
  127. # [03:25] <Lachy> I'm going about it exactly the way Hixie did... get a job at opera (trying to), work on specs, etc. :-)
  128. # [03:26] <Hixie> :-)
  129. # [03:26] <karl> xover: I'm looking at that. It is a day-off today in Keio SFC, but I will pass it.
  130. # [03:26] <xover> yod has days off? SInce when? :-)
  131. # [03:26] <Lachy> who wants to set up the IWAJAGWG (I want a job at Google working group) ;-)
  132. # [03:26] <karl> xover: well as you see ;) I'm here too and I should not :p
  133. # [03:26] <xover> heh heh
  134. # [03:26] <xover> Speaking of which...
  135. # [03:27] * xover heads off to bed...
  136. # [03:27] <karl> have a good night
  137. # [03:30] <mjs> xover: who is yod?
  138. # [03:31] <karl> mjs: yod on freenode:#validator is olivier on W3C channels
  139. # [03:31] <karl> aka Olivier Thereaux
  140. # [03:32] <mjs> ah, so he might be interested in helping with a test suite for conformance checkers?
  141. # [03:32] <karl> or at least to have access to the test and automate them for the validator. I think so.
  142. # [03:33] <karl> http://validator.w3.org/dev/tests/
  143. # [03:45] <zcorpan> i'll probably be working on tests at opera this summer, and i'll look into labeling each test as syntatically conforming/syntatically non-conforming, so they can be used as conformance checker tests as well as browser tests
  144. # [03:47] <mjs> Lachy: since you were discussing Safari's handling of <script /> earlier, we might make that a Dashboard-only quirk - we foolishly did it for Firefox compatibility, and then a huge number of Dashboard widgets started relying on it, and now Firefox no longer handles it as empty in HTML
  145. # [03:48] <mjs> zcorpan: maybe you can volunteer to be a test suite editor then
  146. # [03:48] <Dashiva> I need to make my client not highlight dashboard...
  147. # [03:48] <zcorpan> mjs: yeah
  148. # [03:48] <Lachy> mjs, I suspected that's what you were going to do
  149. # [03:48] * mjs hopes people who have been active in WHATWG consider helping out with issue tracking or the test suite
  150. # [03:49] * Lachy can contribute to the test suite
  151. # [03:49] <mjs> Lachy: I tried to get Apple to fix all the system widgets at least for the next release
  152. # [03:51] <karl> I would be happy to contribute for testing but I have the administration the WG is taking far too much time, still. But I will certainly do it.
  153. # [03:51] <karl> a first step would be to collect the test already done.
  154. # [03:51] <mjs> yeah, I know a lot of people have test cases around, I am hoping a few of them volunteer and we can give them a repository to start organizing them officially
  155. # [03:52] <mjs> (as soon as we have a spec of course - pointless to have tests w/ no spec)
  156. # [03:53] <Lachy> should we use CVS for the test suite? http://dev.w3.org/cvsweb/html5/
  157. # [03:54] <mjs> if the W3C had an official subversion repository I'd suggest that
  158. # [03:54] <mjs> in its absence, cvs should do
  159. # [03:54] <Lachy> I don't think they do have svn
  160. # [03:54] <Lachy> I have to go, cya
  161. # [03:55] <mjs> later
  162. # [03:58] <Zeros> mjs, Is Radar a custom issue tracker?
  163. # [03:58] <mjs> Zeros: it's the Apple internal bug-tracking system
  164. # [03:59] <Zeros> yeah
  165. # [04:01] * Quits: heycam (cam@130.194.72.84) (Ping timeout)
  166. # [04:03] * Joins: heycam (cam@130.194.72.84)
  167. # [04:38] * Quits: zcorpan (zcorpan@84.216.40.169) (Ping timeout)
  168. # [04:42] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  169. # [04:47] * Joins: gavin_ (gavin@74.103.208.221)
  170. # [06:47] * Quits: kazuhito (kazuhito@210.232.34.13) (Quit: Computer goes to sleep!)
  171. # [06:49] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  172. # [06:54] * Joins: gavin_ (gavin@74.103.208.221)
  173. # [07:03] * Quits: h3h (bfults@66.75.149.197) (Quit: h3h)
  174. # [07:40] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Ping timeout)
  175. # [07:57] * Joins: loic (loic@90.29.243.54)
  176. # [08:12] * Quits: gsnedders (gsnedders@86.139.123.225) (Ping timeout)
  177. # [08:15] <hsivonen> xover: see the context of saying "best solution already". It is quite possible that the WHATWG does not have the best solution for all issues. but it would be silly to assume that the solutions have to be changed just because they weren't reached within the W3C.
  178. # [08:17] <hsivonen> xover: that is, if the WHATWG already has the best solution for a given issue, reopening it just because of politics makes no sense
  179. # [08:17] <xover> hsivonen: I'm just reading mjs' latest and shaking my head in resignation.
  180. # [08:18] <xover> "So I am not sure why we would want to accommodate an opposing point of view."
  181. # [08:19] <xover> Really? Y'all are so sure you right and have thought of everything that you have no need of an opposing view?
  182. # [08:20] <mjs> xover: specifically on the issue of making changes to HTML that are not backwards compatible
  183. # [08:20] <xover> Sure. But that attitude keeps popping up.
  184. # [08:20] <mjs> xover: have I ever expressed it on any other point than that?
  185. # [08:20] <mjs> do you want to make incompatible changes to HTML?
  186. # [08:21] <xover> Yes.
  187. # [08:21] <mjs> why do you want to make them in HTML5 rather than XHTML2, when backwards compatibility is the biggest difference in goals between the two?
  188. # [08:21] <hsivonen> xover: considering that the new HTML WG is specifically not the XHTML 2.0 WG, do you think the new HTML WG should accommodate views that aspire to turn HTML5 into XHTML 2.0?
  189. # [08:22] <xover> And see what happens when I try to express an opposing point of view...
  190. # [08:22] <mjs> xover: people disagree with you?
  191. # [08:22] <xover> I get ganged up on by a pack of rabid WHATWG'ers throwing accusations of XHTML2'ness at me. :-)
  192. # [08:23] * xover is joking, but serious about the point...
  193. # [08:24] <Hixie> i don't see any ganging up, just some honest questions
  194. # [08:24] * Hixie is curious as to the answers too
  195. # [08:24] <mjs> my question is totally serious
  196. # [08:24] <mjs> I don't get why anyone would propose incompatible changes to HTML in HTML5, when XHTML2 exists as the venue for such things
  197. # [08:25] <xover> I would like to make evolutionary changes to HTML 4.01. I believe XHTML 2.0 is far too radical a change to be feasible in the real world in any reasonable timeframe.
  198. # [08:26] <mjs> I believe that any significantly incompatible change is far too radical a change to be feasible in the real world in any reasonable time frame
  199. # [08:26] <hsivonen> mjs: I do. If one assumes that browser vendors won't implement XHTML 2.0 but will implement HTML5, it makes sense to push whatever changes on the HTML5 side. However, this line of thinking misses the point *why* browser vendors would want to implement HTML5 and not XHTML 2.0.
  200. # [08:27] <mjs> that is why I want to work on a compatible evolutionary path, rather than arguing with the XHTML2 folks to break compat a little less
  201. # [08:27] <mjs> hsivonen: fair enough
  202. # [08:27] <Hixie> maybe it would help if xover gave concrete examples of things he wants to change that he doesn't think are backwards compatible
  203. # [08:28] <xover> Hell, how about things I /don't/ want changed? Y'all are radically redefining the entire language by no longer defining it in terms of SGML.
  204. # [08:29] <mjs> well, that goes to the question of what change and compatibility mean
  205. # [08:29] <xover> I'm still trying to figure out if mjs' really meant that "HTML5" redefines the meaning of all published documents (HTML 2.0, HTML 3.2, HTML 4.01, ISO-HTML).
  206. # [08:29] <mjs> browsers have never implemented SGML parsing for HTML, and now much content depends on this
  207. # [08:30] <mjs> including, for example, the ability to send XHTML as text/html
  208. # [08:30] * Joins: Shunsuke (kuruma@219.110.80.235)
  209. # [08:30] <hsivonen> xover: well, the non-SGMLness is even in the charter. it is entirely unproductive to reopen that issue every week.
  210. # [08:30] <xover> mjs: Above I meant I wandet to do things like drop the transitional and frameset DTDs from html 4.01.
  211. # [08:30] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  212. # [08:31] <mjs> HTML5 goes one better by dropping all the DTDs
  213. # [08:31] <xover> Completely needlessly.
  214. # [08:31] <hsivonen> xover: embracing reality and insisting on SGML are the kind of opposing viewpoints that are mutually exclusive
  215. # [08:31] <hsivonen> xover: the WG cannot be productive if the issue is debated every week
  216. # [08:32] <hsivonen> xover: so by necessity, some people are not going to have their way
  217. # [08:32] <Lachy> xover, you're welcome to write a DTD for HTML5 if you wish
  218. # [08:32] <Lachy> it just won't be endorsed by the spec in any way (or be particularly useful)
  219. # [08:36] <hsivonen> xover: out of curiosity, why do you want a DTD when a RELAX NG schema exists and it is known that RELAX NG is more expressive than DTDs (or XSD for that matter)?
  220. # [08:39] <xover> I want a DTD so I can process it with DTD based tools. I also want a Schema of some sort, normative preferably, for other tasks.
  221. # [08:40] <xover> Let me ask; are browsers the only relevant consumers of web content?
  222. # [08:40] <mjs> no, but they are among the ones where interoperability is most important
  223. # [08:41] <mjs> since lack of interoperability there directly hurts all authors and end users (other than the rare HTML content that will never end up on the Web)
  224. # [08:41] <xover> Ok, so the browser vendors have some requirements, needs, they need the standard to accomodate.
  225. # [08:42] <xover> My requirements run along the lines of having the ability to process web content without needing to implement a MSIE-bugcompatible parsing engine.
  226. # [08:43] <xover> OpenSP was excellent in this regard. I doubt WebKit will provide the equivalent.
  227. # [08:44] <mjs> http://code.google.com/p/html5lib/
  228. # [08:45] <mjs> does OpenSP actually process web content?
  229. # [08:45] <mjs> which is to say, in a way that matches what the author intended, rather than by SGML rules?
  230. # [08:45] <xover> Yes. Very well.
  231. # [08:45] <mjs> then it must have a rougly MSIE-bugcompatible parsing engine already
  232. # [08:45] <xover> Uh-huh. But in order for the browsers not to have to change their parser engines dramatically, you require me to move from the well known and established SGML toolchains to some single Python hack.
  233. # [08:46] <xover> mjs: No, just different goals then which pixel to animate in what color.
  234. # [08:46] <mjs> xover: if it parses HTML as if it were an SGML application, then it will parse a lot of web content incorrectly
  235. # [08:47] <mjs> whatever HTML5 has to say about the matter, it is already not meeting your goals
  236. # [08:47] <mjs> unless you are only interested in a subset of web content
  237. # [08:47] <xover> Everyone is interested iun a subset of web content; the question is which subset.
  238. # [08:48] <mjs> HTML5 is interested in a very large subset
  239. # [08:48] <xover> The only valid one?
  240. # [08:48] <mjs> if you are interested in a smaller one, you should feel free to continue using your existing tools
  241. # [08:49] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
  242. # [08:49] <xover> Ah, but in a previous message you implicated that HTML5 redefines all of text/html to _be_ HTML5.
  243. # [08:49] <mjs> I think asking for all browsers, most web content and most authoring tools to change so that your library can parse a bigger subset of web content is not a reasonable request
  244. # [08:49] <xover> Including, I can only assume, ISO-HTML.
  245. # [08:50] <xover> I'm asking that the spec at least /try/ to accomodate also the non-browser requirements.
  246. # [08:51] <xover> For instance, the non-SGML'ness of the charter was, IMO, a mistake, but the lack of focus on SGML in the actual spec is probably right and a good idea.
  247. # [08:51] <mjs> ISO-HTML differs from W3C HTML 4.01 and so is already invalid to send as text/html
  248. # [08:51] * Hixie is curious as to why html5lib is a "python hack", and whether that means OpenSP is a "C++ hack", and why that matters
  249. # [08:52] <Hixie> SGML tools simply can't process existing content
  250. # [08:52] <Hixie> e.g. <a href=http://damowmow.com/> test </a>
  251. # [08:52] <Hixie> ...is radically different in SGML-land than in HTML
  252. # [08:53] <Hixie> i see no good reason to insist on using clearly inappropriate, fundamentally broken tools that handle a minute subset of the web when there exists the opportunity to handle so much more content
  253. # [08:53] <xover> mjs: Are you seriously suggesting ISO-HTML cannot be served on the web?
  254. # [08:53] <xover> Hixie: That's a very browser-oriented point of view.
  255. # [08:53] <hsivonen> xover: yes, basically the suggestion is that in order to accommodate browser reality, it would be a good idea to use an HTML5 parser instead of OpenSP at the start of your processing pipeline.
  256. # [08:54] <Hixie> especially since the opportunity has already generated real workable tools, parsers, and conformance checkers
  257. # [08:54] <mjs> well, no one can stop you, but serving it with the text/html MIME type does appear to violate the RFC registering text/html
  258. # [08:54] <Hixie> xover: no, i'm talking about data mining
  259. # [08:54] <Hixie> xover: and other tools
  260. # [08:54] <Hixie> xover: not browsers at all
  261. # [08:54] <hsivonen> xover: once HTML5 parsers are readily available under very permissive licenses, I don't see this as onerous
  262. # [08:55] <xover> Hixie: It's a "python hack" only because SGML tools have about 30 years of history and html5lib is brand new.
  263. # [08:55] <Hixie> ah
  264. # [08:55] <Hixie> so in 30 years, will it still be a python hack?
  265. # [08:55] <hsivonen> xover: ISO-HTML is not served on the Web often enough for it to matter for tool choices unless you have made a bilateral agreement with the provider of content
  266. # [08:56] <xover> Yes, as much as OpenSP is a C++ hack. :-)
  267. # [08:56] <Hixie> it seems strange to judge something on its age rather than its quality
  268. # [08:56] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  269. # [08:56] <mjs> software isn't wine
  270. # [08:56] <Hixie> even wine should be judged on its quality, not its age
  271. # [08:56] <Hixie> it's just that with wine the two tend to be correlated
  272. # [08:56] <Hixie> with software, i don't think there's a correlation at all
  273. # [08:56] <hsivonen> I'd say OpenSP has quality if you judge it against the SGML spec, but it is the wrong tool for parsing arbitrary text/html content available on the Web
  274. # [08:57] <Hixie> (neither a positive one nor an inverse one)
  275. # [08:57] <Hixie> hsivonen: right
  276. # [08:57] <mjs> well, software quality does take a minimum amount of time
  277. # [08:57] <mjs> but past a certain point (which I think is less than 30 years for even the most complex software) there's not much correlation left
  278. # [08:57] <hsivonen> xover: you are basically suggesting that the spec should accommodate an inappropriate non-browser tool used by few instead of accommodating browsers used by many
  279. # [08:58] <xover> Did anybody tell ISO that their specs don't matter and we don't want them on our web?
  280. # [08:58] <xover> hsivonen: Did I say "instead"?
  281. # [08:58] <hsivonen> xover: "instead" follows implicitly due to the nature of the issue
  282. # [08:58] <xover> hsivonen: I disagree.
  283. # [08:58] <Hixie> sgml processing and the syntax of pages on the web are fundamentally incompatible
  284. # [08:59] <Hixie> see the example i gave above
  285. # [08:59] <hsivonen> xover: perhaps no one bothered to tell ISO.
  286. # [08:59] <Hixie> <a href=http://damowmow.com/> test </a>
  287. # [08:59] <Hixie> ...means something radically different in SGML-land than on the web
  288. # [09:00] <hsivonen> xover: see how many years it took them to make some of their specs available for gratis on the Web as zipped PDF when people have been saying for years that they should be available on the Web as Web pages
  289. # [09:00] <xover> So you rail about Microsoft's implementations of standards, but you want to redefine what the standard is so that your particular implementation of them is suddenly not only entirely conforming, but in fact /defiining/.
  290. # [09:00] <hsivonen> xover: ISO has been seriously out of touch with the Web, so why pretend that they matter just because they are official
  291. # [09:01] <Hixie> actually it's microsoft's implementation that we want to make conforming, basically
  292. # [09:01] <xover> See, this is what I don't like. The browsers and webdesigners point of view rules all; anything else is dismissed as irrelevant.
  293. # [09:01] <Hixie> (or as close as we can get without making it a non-tree)
  294. # [09:02] <xover> Hixie: Sorry, I may have been drowning in Matthew Raymonds rethoric a little much lately.
  295. # [09:02] <Hixie> xover: i'm talking about tools here. i really don't care about browsers in this conversation.
  296. # [09:02] * Joins: gavin_ (gavin@74.103.208.221)
  297. # [09:03] <hsivonen> xover: browsers are seriously important for the Web. the W3C begat the WHATWG when it ignored browsers
  298. # [09:04] <xover> hsivonen: There is a compromise position in between XHTML2 and WHATWG.
  299. # [09:04] <xover> They are both extremes of the scale in opposite directions.
  300. # [09:05] <xover> In fact, there's more than one axis to this scale.
  301. # [09:05] <hsivonen> xover: we should optimize for the good of the Web instead of finding political middle ground
  302. # [09:05] <xover> hsivonen: Who said anything about politics?
  303. # [09:06] <hsivonen> xover: compromising without technical reasons is politics
  304. # [09:06] <hsivonen> xover: it has been explained why it doesn't make sense to cater for OpenSP
  305. # [09:06] <hsivonen> technically
  306. # [09:08] <xover> See, this is why I don't want any of you lot as Editors. :-)
  307. # [09:09] <hsivonen> xover: btw, as far as old discussions go, we already had this discussion on the WHATWG list with Elliotte Harold, but that discussion had an XML parser in the role that OpenSP occupies here
  308. # [09:09] <xover> Yeah, that's why I gave up on the WHATWG in the early days. They didn't seem interested in accomodating my requirements.
  309. # [09:12] <hsivonen> xover: the fact that real Web content in the general case does not work with OpenSP is outside the control of the WHATWG. it is a contrained posed by the way the world is
  310. # [09:13] <hsivonen> xover: if your requirements are incompatible with the reality of the Web, you will indeed be frustrated with the WHATWG
  311. # [09:13] <hsivonen> xover: however
  312. # [09:13] <hsivonen> xover: if you want to use OpenSP and you are not interested in the general case, I have the same reply that applied to elharo's case
  313. # [09:14] <hsivonen> xover: if you can make and agreement with the content provider so that you have a bilateral agreement and the generalities of the Web don't apply, you can agree that the content provider provides conforming XHTML5 to you
  314. # [09:15] <hsivonen> xover: in which case you can consume it with OpenSP when you've loaded the XML compatibility SGML declaration
  315. # [09:15] <xover> It's entirely possibloe that I'll end up abandoning HTML5 as a lost cause, yes.
  316. # [09:16] <hsivonen> xover: OK, but please don't consider it the fault of the WHATWG but the fault of the way the Web is
  317. # [09:16] <hsivonen> xover: since the Web isn't SGML-compatible in general
  318. # [09:17] <xover> For the same reasons I abandoned the original HTML WG as a lost cause. They too were unwilling to listen to my requirements (or anybody else's requirements, for that matter).
  319. # [09:17] <Hixie> xover: can you state your requirements without reference to specific user agents? i'm not sure i understand them still.
  320. # [09:18] <hsivonen> xover: I have spent a good moment here listening and explaining why your requirements aren't workable on the Web scale
  321. # [09:18] <hsivonen> xover: this isn't about not listening
  322. # [09:18] <Hixie> also note that who is editor doesn't change what technical decisions get made, at least not if the editor is (like i am) trying to find solutions to everyone's problems
  323. # [09:20] <mjs> if your requirement is "make OpenSP handle arbitary web content correctly", then this is outside the power of any working group
  324. # [09:21] <mjs> if the requirement is "define conforming web content such that OpenSP can correctly handle all conforming content", then that is probably not achievable without breaking more popular use cases, like conforming XHTML-compatible syntax
  325. # [09:21] <xover> Hixie: On Editors, if they are too much in agreement and share too strongly the same point of view, then all their blinders will be the same and other voices will be lost or dismissed.
  326. # [09:22] <xover> Hixie: Conversely, if they disagree fundamentally but still manage to act impartially, then you avoid that problem.
  327. # [09:22] <mjs> I think editors disagreeing fundamentally is likely to lead to more fighting, more stress, and less work done
  328. # [09:22] <mjs> as opposed to more fairness or better results
  329. # [09:22] <xover> mjs: Perhaps. But the alternative is worse.
  330. # [09:23] <Hixie> xover: as an editor, i specifically try to treat my opinion as no more important than anyone else's
  331. # [09:23] <Hixie> xover: i believe i'm reasonablly good at this, based on the comments from others
  332. # [09:23] <xover> mjs: Forget OpenSP specifically. It's an example of using a general toolchain — be it SGML based or XML based — to process web content.
  333. # [09:24] <Hixie> xover: (there are several things in the spec i really disagree with)
  334. # [09:24] <xover> Hixie: That's a very good sign! :-)
  335. # [09:24] <mjs> the HTML5 solution of using a general toolchain to process web content is to put an HTML5 parser at the front of your pipeline
  336. # [09:24] * Joins: heycam (cam@203.214.79.176)
  337. # [09:25] <sbuluf> mjs, fast off topic question, if you can: 1) are you sort of *the* apple person for browsers? or at least know the code? and if so...is there anywhere where i could see an proximated list of lines of code per browser functionality? (like security, parsing, rendering, UI, whatever). feel free to answer later if busy, i do not wish to interrupt.
  338. # [09:25] <mjs> sbuluf: I am one of many apple persons for browsers
  339. # [09:25] <mjs> I do know the code
  340. # [09:25] <sbuluf> i see. enough for me
  341. # [09:25] <mjs> there is no breakdown like that readily available, and some of the things you ask for don't make sense because they are not on separate lines of code
  342. # [09:25] <mjs> like security
  343. # [09:26] <mjs> all code has to consider security issues
  344. # [09:26] <sbuluf> i feared so...
  345. # [09:26] <sbuluf> right
  346. # [09:26] <mjs> much like performance
  347. # [09:26] <mjs> but the source code to the whole engine is available
  348. # [09:26] <mjs> so you can do whatever approximation suits you yourself
  349. # [09:26] <sbuluf> not even a remote way to determine some sort of code composition?
  350. # [09:26] <mjs> http://webkit.org/
  351. # [09:26] <mjs> http://webkit.org/building/checkout.html
  352. # [09:26] <sbuluf> (i would not know even how to read it, i'm afraid)
  353. # [09:27] <hsivonen> xover: HTML5 has a solution to the toolchain issue. moreover, there is already enough implementation experience to believe that the solution works
  354. # [09:27] <xover> mjs: But all deployed web content is defined in terms of SGML and HTML5 retroactively changes the rules. The wealth of experience devloped over years with SGML tools is suddenly replaced with something brand new and extremely specific.
  355. # [09:27] <Hixie> xover: html5lib has already been used by several people as the frontend to an xml toolchain
  356. # [09:27] <sbuluf> (mjs, k, nevermind, and thanks)
  357. # [09:27] <hsivonen> xover: the solution is using XML tools except the XML parser and using an HTML5 parser that exposes an XML parser API in the place of the XML parser
  358. # [09:27] <Hixie> xover: several people have shown an interest in creating html5 parsers for xml toolchains in other languages
  359. # [09:28] <mjs> sbuluf: you might find people who can help you in #webkit on freenode, but there's a bunch of discussion there right now so probably best not to interrupt
  360. # [09:29] <sbuluf> mjs, tomorrow, then, and thanks =P
  361. # [09:29] <mjs> xover: using the SGML definition for deployed web content gives the wrong answer
  362. # [09:29] <mjs> seriously, it doesn't matter what the spec says, if you try to treat random web content as SGML your results will be wrong
  363. # [09:29] <xover> mjs: For cnn.com, yes. For my internal document archives, no.
  364. # [09:30] <mjs> well, you can keep parsing your internal document archives any way you want
  365. # [09:30] <mjs> if they work in browsers today, then HTML5 probably won't break them
  366. # [09:30] <Hixie> you don't need a spec for internal content
  367. # [09:30] <Hixie> you only need a spec for content that's going to have to interoperate
  368. # [09:30] <xover> In this context, I don't really care about what browsers do or do not support.
  369. # [09:31] <hsivonen> xover: the purpose of the spec is to establish common understanding between parties who don't have a priori bilateral agreements about the way of doing things
  370. # [09:31] * Joins: Deeder (Deeder@86.198.254.100)
  371. # [09:31] <xover> Hixie: Internal content has much more need to interoperate, over decades and changes of systems.
  372. # [09:31] <hsivonen> xover: obviously, you can make agreements with yourself without a spec
  373. # [09:32] <hsivonen> xover: as I suggested, you can place a voluntary constraint on yourself to use XHTML5
  374. # [09:42] * Joins: MikeSmith^ (MikeSmith@mcclure.w3.org)
  375. # [09:42] <xover> hsivonen: What does your HTML5 checker do when fed, say, a HTML 3.2 document?
  376. # [09:42] * Joins: ROBOd (robod@86.34.246.154)
  377. # [09:43] * MikeSmith^ is now known as MikeSmith
  378. # [09:43] <hsivonen> xover: now it says that there was an unsupported legacy doctype. once I upgrade the parser, it should complain but continue
  379. # [09:44] <xover> Processing it according to HTML5 rules I assume?
  380. # [09:44] <hsivonen> xover: once I upgrade the parser. the current parser predates HTML5 rules
  381. # [09:44] <xover> Hmm. Is this case discussed in your thesis?
  382. # [09:44] * xover hasn't managed to free up the time ot read it yet, sorry.
  383. # [09:45] <hsivonen> xover: the fact that the proof of point parser does not implement the HTML5 parsing algorithm is discussed. legacy doctypes are not
  384. # [09:46] <hsivonen> xover: when I've put all this thesis stuff behind me, I my plan is to turn the parser into a real HTML5 parser (but no specific promises at this time)
  385. # [09:46] <hsivonen> s/I my/my/
  386. # [09:49] <xover> Hmm. I'm trying to wrap my head around what the implications of "HTML5" are for the body of documents that are actual honest to gosh SGML Valid HTML <=4.01 documents.
  387. # [09:50] <hsivonen> xover: SGML minimizations work as in browsers--not as in OpenSP
  388. # [09:50] <hsivonen> xover: comment parsing is browser-compatible
  389. # [09:50] <hsivonen> xover: you get a non-fatal (i.e. recoverable) parse error on doctype
  390. # [09:51] <xover> hsivonen: My main beef with the former HTML WG was that they refused to update the SGML Declaration to match what browsers actually implemented. :-)
  391. # [09:51] <xover> (btw)
  392. # [09:51] <xover> (on minimizations specifically, that is)
  393. # [09:51] * Quits: sbuluf (vaztp@200.49.140.83) (Ping timeout)
  394. # [09:53] <xover> Hmm. Ok, so it's possible that for some "edge" cases, processing legacy content with a HTML5 processor would render them non-conforming?
  395. # [09:53] <hsivonen> xover: non-conforming as far as HTML5 docement conformance goes, yes. however, they'd still be compatible processable as far as UA conformance goes
  396. # [09:54] <xover> Would this be the case if the document was not just DTD-valid but also conformant with the actual prose of the specs?
  397. # [09:54] <hsivonen> xover: yes
  398. # [09:54] <xover> Ok, so there are actually acknowledged incompatibilities between HTML5 and previous HTML standards?
  399. # [09:55] <xover> (again, completely ignoring what the world looks like from inside a browser here)
  400. # [09:56] <hsivonen> xover: to the extent the previous HTML standards don't match reality, yes
  401. # [09:56] <hsivonen> xover: for example, the definition of usemap is reality-compatible but different from what previous spec said.
  402. # [09:57] <xover> Are these considered bug fixes or necessary breaks with legacy (in general)?
  403. # [09:57] <hsivonen> xover: in WHATWG, compatibility is functional compatibility with deployed browsers and content--not preserving the requirements of previous specs
  404. # [09:58] <hsivonen> xover: when processing models change, bug fixes
  405. # [09:58] <xover> Sure. But I'm trying to figure out what that means for my areas of interest.
  406. # [09:58] <hsivonen> xover: when document conformance changes, some changes are motivated by aesthetics
  407. # [09:58] <hsivonen> xover: but those changes don't cause actual page breakage is UAs
  408. # [09:59] <hsivonen> xover: I mean bimorphic content models
  409. # [09:59] * xover doesn't even know what "bimorphic" /means/... :-)
  410. # [09:59] <hsivonen> xover: but even the bimorphic stuff is considered a bug fix where the bug was due to the limitations of DTDs
  411. # [10:00] <hsivonen> xover: bimorphic content model take either block or inline at a time but not a mix of them
  412. # [10:01] * xover finds the distinction between block and inline increasingly artificial, but he digresses...
  413. # [10:01] <hsivonen> xover: there's also the concept of structured inline to address that problem
  414. # [10:02] <hsivonen> xover: unfortunately though, legacy contraints limit the applicability of structured inline in the case where you'd want it the most
  415. # [10:02] <hsivonen> xover: that is, in <p> in text/html
  416. # [10:04] * Joins: zdenko (zdenko@193.77.152.244)
  417. # [10:04] <xover> Ok, I think I'd need to see the output on a HTML5 conformance checker of legacy content on some sample set of documents to be able to asess the actual implications.
  418. # [10:05] <hsivonen> xover: please note that I haven't implemented the <font> stuff, because Hixie has indicated that it might not stand in the long run
  419. # [10:05] <xover> But I take it it's not in dispute that HTML5's backward compatibility is in terms of browser rendering and not general conformance.
  420. # [10:05] <hsivonen> right
  421. # [10:06] <xover> IOW, it's sort of a souped up Appendix C mode rather then a strict superset.
  422. # [10:06] <xover> (not meaning to attach the negative connotations of AppC here!)
  423. # [10:08] * Joins: kazuhito (kazuhito@210.232.34.13)
  424. # [10:09] <xover> Anyways, I need to head off to work. Thank you (all) for your time and the interesting discussions!
  425. # [10:10] <hsivonen> you're welcome. see you
  426. # [10:19] * Joins: Shunsuke (kuruma@219.110.80.235)
  427. # [10:26] * Quits: Deeder (Deeder@86.198.254.100) (Client exited)
  428. # [10:50] * Quits: Shunsuke (kuruma@219.110.80.235) (Client exited)
  429. # [10:50] * Joins: Shunsuke (kuruma@219.110.80.235)
  430. # [10:53] * Quits: Shunsuke (kuruma@219.110.80.235) (Client exited)
  431. # [10:55] * Joins: Shunsuke (kuruma@219.110.80.235)
  432. # [10:56] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  433. # [10:56] * Quits: Dashiva (noone@129.241.151.35) (Ping timeout)
  434. # [10:56] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  435. # [10:59] * Joins: xover (xover@193.157.66.5)
  436. # [10:59] * Joins: Dashiva (noone@129.241.151.35)
  437. # [11:02] * Joins: Hixie (ianh@129.241.93.37)
  438. # [11:04] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  439. # [11:05] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
  440. # [11:10] * Joins: gavin_ (gavin@74.103.208.221)
  441. # [11:19] * Joins: Shunsuke (kuruma@219.110.80.235)
  442. # [11:25] * Quits: claudio (claudioc@89.97.35.74) (Ping timeout)
  443. # [11:25] * Joins: claudio (claudioc@89.97.35.74)
  444. # [11:38] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
  445. # [11:47] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  446. # [12:01] * Joins: Shunsuke (kuruma@219.110.80.235)
  447. # [12:15] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  448. # [12:25] * Joins: hasather (hasather@81.235.209.174)
  449. # [12:31] * Joins: mjs (mjs@64.81.48.145)
  450. # [12:38] * Quits: kazuhito (kazuhito@210.232.34.13) (Quit: Computer goes to sleep!)
  451. # [12:39] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  452. # [12:51] * Joins: karl (karlcow@128.30.52.30)
  453. # [13:13] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  454. # [13:18] * Quits: Lachy (Lachlan@124.168.27.56) (Connection reset by peer)
  455. # [13:18] * Joins: gavin_ (gavin@74.103.208.221)
  456. # [13:18] * Joins: kazuhito (kazuhito@210.232.34.13)
  457. # [13:18] * Joins: Lachy (Lachlan@124.168.27.56)
  458. # [13:27] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  459. # [14:00] * Joins: mw22 (chatzilla@84.41.169.151)
  460. # [14:03] * Joins: zcorpan (zcorpan@84.216.42.88)
  461. # [14:19] * Quits: Shunsuke (kuruma@219.110.80.235) (Client exited)
  462. # [14:25] * Joins: Shunsuke (kuruma@219.110.80.235)
  463. # [14:27] * Quits: kazuhito (kazuhito@210.232.34.13) (Quit: Quitting!)
  464. # [14:49] * Joins: gsnedders (gsnedders@86.139.123.225)
  465. # [14:51] * Joins: dfgdsfg (sad@213.149.180.144)
  466. # [14:51] * dfgdsfg is now known as ManyMen
  467. # [14:51] <ManyMen> Are there any new features in html 5?
  468. # [14:53] <ManyMen> Are there any new features in html 5?
  469. # [14:55] <zcorpan> ManyMen: yes, some of which are already implemented in browsers, see http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
  470. # [14:55] <ManyMen> I found this page http://simon.html5.org/html5-elements.
  471. # [14:55] <zcorpan> ok
  472. # [14:55] * Joins: ROBOd (robod@86.34.246.154)
  473. # [14:56] <ManyMen> If it is right , then our knowledge in html will be useless
  474. # [14:56] <zcorpan> how so?
  475. # [14:56] <ManyMen> html 5 seems to be harder than the other versions
  476. # [14:57] <hsivonen> ManyMen: why?
  477. # [14:57] <ManyMen> there are more elements
  478. # [14:57] <ManyMen> and we must learn html again
  479. # [14:57] <ManyMen> from the beginnig
  480. # [14:57] <ManyMen> beginning
  481. # [14:58] <hsivonen> ManyMen: well, there wouldn't be any point in writing a new spec if it didn't offer anything new
  482. # [14:58] <zcorpan> ManyMen: no, you can continue with your current knowledge of html and just use any new feature you fancy
  483. # [14:58] <zcorpan> ManyMen: with html5, you *don't* need to relearn anything
  484. # [14:59] <ManyMen> actually you are right
  485. # [14:59] <hsivonen> zcorpan: in fairness, there are a couple of gotchas if one cares about document conformance
  486. # [14:59] <hsivonen> zcorpan: particularly the content model of <div>
  487. # [14:59] <zcorpan> hsivonen: yes, that's true
  488. # [15:00] <ManyMen> after html 5 there would be html 6 ?
  489. # [15:00] <zcorpan> probably
  490. # [15:00] <ManyMen> but some of the html 5 elements might not use in our browsers
  491. # [15:01] <ManyMen> might not work*
  492. # [17:04] * Disconnected
  493. # [17:04] * Attempting to rejoin channel #html-wg
  494. # [17:04] * Rejoined channel #html-wg
  495. # [17:04] * Topic is 'W3C HTML WG http://www.w3.org/html/wg/ - http://krijnhoetmer.nl/irc-logs/ (logged) - http://esw.w3.org/topic/HTML/ProposedDesignPrinciples'
  496. # [17:04] * Set by anne on Tue Mar 27 12:28:46
  497. # [17:05] * Joins: briansuda (briansuda@130.208.162.93)
  498. # [17:06] * Joins: Shunsuke (kuruma@219.110.80.235)
  499. # [17:10] <hsivonen> MikeSmith: CSS is supposed to be optional and disabling scripting is legitimate.
  500. # [17:11] <hsivonen> MikeSmith: even though Lynx isn't as much of Web browser as Firefox, Opera, Safari and IE, it would still be good if Lynx supported HTML5
  501. # [17:27] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  502. # [17:28] <zcorpan> and the spec should be written in a way such that Lynx could be conforming (without CSS, scripting, images, video, etc), imho
  503. # [17:28] <zcorpan> (probably is already)
  504. # [17:29] <zcorpan> (the spec, that is)
  505. # [17:29] <MikeSmith> hsivonen - of course it would good. I just don't think it's going to be a terrific hardship for the world if it doesn't
  506. # [17:30] <zcorpan> lynx supports some html 3.0/html+ features, doesn't it?
  507. # [17:31] * zcorpan thought he saw LH and FIG when looking at lynx's default style sheet before
  508. # [17:32] * Joins: gavin_ (gavin@74.103.208.221)
  509. # [17:40] * Quits: briansuda (briansuda@130.208.162.93) (Quit: briansuda)
  510. # [17:45] * Joins: briansuda (briansuda@130.208.162.93)
  511. # [17:46] * Quits: kazuhito (kazuhito@222.151.185.31) (Quit: Computer goes to sleep!)
  512. # [18:05] * Quits: Ashe (Ashe@213.47.199.86) (Quit: Quit)
  513. # [18:05] * Joins: Ashe (Ashe@213.47.199.86)
  514. # [18:11] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
  515. # [18:34] * Quits: briansuda (briansuda@130.208.162.93) (Quit: briansuda)
  516. # [18:35] * Joins: Pemou (xhtml@213.7.64.102)
  517. # [18:37] <Pemou> Hello , i am very confused. I just read http://blog.whatwg.org/faq/#xhtml5 which is a page for html 5. HTML 5 or XHTML ? I do not know .
  518. # [18:39] * Joins: olli- (olli@80.203.95.229)
  519. # [18:39] <gsnedders> Pemou: for both
  520. # [18:40] <Pemou> No , i mean HTML or XHTML . Which one to use ?
  521. # [18:40] <Pemou> Everything is so confusing
  522. # [18:40] <wilhelm> That depends on your needs.
  523. # [18:41] <Pemou> Yes , but they are the same .
  524. # [18:41] <zcorpan> Pemou: you probably want to be using text/html. then if you use "html syntax" or "xhtml syntax" is mostly a matter of taste, personal preference or faith in markup gods :)
  525. # [18:42] <wilhelm> Yes and no. XHTML is parsed as XML, HTML is not. This is good or bad depending on your needs and requirements.
  526. # [18:42] <Pemou> they say that xhtml syntax is better
  527. # [18:42] <gsnedders> "they"?
  528. # [18:42] <Pemou> i generally speak
  529. # [18:42] <Pemou> someone
  530. # [18:43] <Pemou> w3schools.com for example
  531. # [18:43] <wilhelm> Unless you require XML features (easy to parse, draconian error handling makes it easy to spot errors), you should stick with HTML.
  532. # [18:43] <Pemou> Are there any errors in XHTML ?
  533. # [18:43] <gsnedders> yes, but none are fatal
  534. # [18:43] <zcorpan> Pemou: that is mostly misguided, the syntax doesn't give you any advantages, and what they usually list as advantages can be done in html as well (e.g. using css)
  535. # [18:44] <Pemou> Well , now i am thinking it better , a customer who wants to a site , he will not see the code but the appearance
  536. # [18:45] <Pemou> If i mix html and xhtml ?
  537. # [18:46] <zcorpan> Pemou: in any case, "xhtml syntax" is allowed in text/html-html5, so in practise you can use either (or a mix)
  538. # [18:46] <Pemou> In XHTML , document type declaration is necessary ?
  539. # [18:47] <zcorpan> depends on how you define "XHTML"
  540. # [18:47] <zcorpan> in text/html, you need one to not trigger quirks mode in browsers
  541. # [18:47] <zcorpan> in XML, no
  542. # [18:48] <Pemou> and when html 5 is ready ?
  543. # [18:48] <wilhelm> 2010, perhaps?
  544. # [18:49] <zcorpan> depends on how you define "ready" :)
  545. # [18:49] <Pemou> 3 years is a long time
  546. # [18:49] <zcorpan> Pemou: you can use new features from html5 when they are implemented in browsers
  547. # [18:49] <olli-> Pemou: it took ie 5 years to fix position:fixed.. 3 years isnt really that bad
  548. # [18:50] <Pemou> lol
  549. # [18:50] <zcorpan> Pemou: you can use http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers to keep track of what is implemented
  550. # [18:51] <Pemou> thanks
  551. # [18:53] <Pemou> Netscape navigator is a browser ?
  552. # [18:56] <Pemou> ?
  553. # [18:56] <zcorpan> yes
  554. # [19:00] <Pemou> I have it , but it copies ie and ff
  555. # [19:00] <Pemou> ok thanks bye
  556. # [19:00] * Parts: Pemou (xhtml@213.7.64.102)
  557. # [19:09] * Quits: myakura (myakura@60.239.122.32) (Quit: Leaving...)
  558. # [19:18] * Quits: Shunsuke (kuruma@219.110.80.235) (Client exited)
  559. # [19:23] * Joins: Voluminous (Voluminous@66.195.32.2)
  560. # [19:26] * Joins: Sander (svl@80.60.87.115)
  561. # [19:26] * Joins: zdenko (zdenko@84.255.203.169)
  562. # [19:35] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  563. # [19:40] * Joins: gavin_ (gavin@74.103.208.221)
  564. # [19:50] * Joins: kingryan (rking3@66.92.187.33)
  565. # [20:00] * Joins: dbaron (dbaron@63.245.220.242)
  566. # [20:02] * Joins: mjs (mjs@17.255.99.192)
  567. # [20:37] * Quits: mjs (mjs@17.255.99.192) (Quit: mjs)
  568. # [20:41] * Joins: mjs (mjs@17.255.99.192)
  569. # [20:54] * Joins: beowulf (carisenda@91.84.50.132)
  570. # [21:14] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  571. # [21:42] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  572. # [21:47] * Joins: gavin_ (gavin@74.103.208.221)
  573. # [22:00] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  574. # [22:11] <Hixie> heh, i wonder if people will no longer want hyatt as editor now that he's pointed out that he disagrees with me on versionning
  575. # [22:14] <Dashiva> Only if they think he's going to be a real editor, rather than a figurehead
  576. # [22:48] * Joins: dbaron (dbaron@63.245.220.242)
  577. # [22:51] * Quits: Ashe (Ashe@213.47.199.86) (Connection reset by peer)
  578. # [22:52] * Quits: Deeder (Deeder@86.198.252.57) (Client exited)
  579. # [22:59] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  580. # [23:05] * Quits: loic (loic@90.29.106.117) (Ping timeout)
  581. # [23:08] <gsnedders> it seems to be the major implementers v. everyone else when it comes to versioning in HTML5
  582. # [23:09] <Hixie> actually there are people from apple and mozilla pro versioning, and people from apple and mozilla anti-versioning
  583. # [23:10] <hsivonen> gsnedders: how so? dbaron argued against versioning and cwilso argued in favor
  584. # [23:10] <Hixie> from having spoken to them off-list, i get the feeling those in favour are those who haven't thought through the implications
  585. # [23:10] <Hixie> and we've only seen one microsoft opinion so far
  586. # [23:10] <Hixie> though microsoft tend to be more in unison at wg meetings
  587. # [23:10] <gsnedders> hsivonen: sure, there are exceptions, but it seems mostly that way
  588. # [23:12] <gsnedders> I think cwilso has had valid reasons for saying what he has said, but I also think all the modes need to be spec'd
  589. # [23:13] <Hixie> which basically doubles are workload, assuming one more version
  590. # [23:14] <gsnedders> we already need to spec quirks mode anyway
  591. # [23:14] <Hixie> most of quirks mode is in css
  592. # [23:14] <Hixie> and the csswg are blissfully ignoring it
  593. # [23:31] * Joins: DanC (connolly@128.30.52.30)
  594. # [23:31] <DanC> RRSAgent, pointer?
  595. # [23:31] <RRSAgent> See http://www.w3.org/2007/04/23-html-wg-irc#T21-35-00
  596. # [23:44] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  597. # [23:49] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  598. # [23:54] * Joins: gavin_ (gavin@74.103.208.221)
  599. # [23:59] * Joins: dbaron (dbaron@63.245.220.242)
  600. # Session Close: Tue Apr 24 00:00:00 2007

The end :)