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

Options:

  1. # Session Start: Wed Apr 04 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:01] * Quits: mjs (mjs@17.255.98.91) (Connection reset by peer)
  4. # [00:01] * Joins: mjs (mjs@17.255.98.91)
  5. # [00:04] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
  6. # [00:04] <Zeros> Hixie, seems like it'd make the most sense to create smaller task groups of 10 or fewer people to hand each issue; they'd come to a consensus and present their findings on the issue (practicality,benefits,etc.) back to the group where anyone who feels they have a sufficiently strong counter argument can present it.
  7. # [00:04] <Zeros> handle
  8. # [00:04] <Hixie> sounds like a lot of work
  9. # [00:04] <Zeros> Better than letting one person do it which creates huge bias
  10. # [00:04] <mjs> I would expect ad-hoc task groups would form
  11. # [00:05] <mjs> currently there sort of is one for <video> in WHATWG, based on people who care
  12. # [00:05] <mjs> and a self-selected one for the Design Principles document in HTML WG
  13. # [00:06] <Hixie> oh well sure, unofficial ones... they don't "report back", though, they just do the work.
  14. # [00:07] <Zeros> The issue I see is that even if they do all the research about the topic, its still biased as to what they researched in the first place and what they interpreted from the research.
  15. # [00:07] <Zeros> in reference to "who's responsibility
  16. # [00:07] <Zeros> is to take all feedback from all the sources I listed in an earlier e-mail
  17. # [00:07] <Zeros> (including blogs, forums, direct feedback from implementors, comments in
  18. # [00:07] <Zeros> bug systems, conclusions from relevant"
  19. # [00:09] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  20. # [00:18] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  21. # [00:30] * Joins: heycam (cam@130.194.72.84)
  22. # [01:04] * DanC is away: family time
  23. # [01:18] * Quits: tylerr (tylerr@66.195.32.2) (Quit: Leaving)
  24. # [01:21] * Joins: htmlr (htmlr@203.206.237.84)
  25. # [01:34] * Parts: hasather (hasather@81.235.209.174)
  26. # [01:34] * Quits: mjs (mjs@17.255.98.91) (Connection reset by peer)
  27. # [01:35] * Joins: mjs (mjs@17.255.98.91)
  28. # [01:36] <anne> +1 to dropping the +1 one
  29. # [01:39] * Quits: htmlr (htmlr@203.206.237.84) (Ping timeout)
  30. # [01:40] <Dashiva> You're not helping the cause, anne ;)
  31. # [01:41] <mjs> my own feelings on the subject:
  32. # [01:41] <mjs> -1 on +1
  33. # [01:41] <anne> heh
  34. # [01:41] <Hixie> 0?
  35. # [01:41] <Hixie> or do you mean -1 over +1, as in -1/+1, which is -1?
  36. # [01:41] * anne deletes some codec discussion
  37. # [01:42] <mjs> so what would you guys think of turning "Mostly Semantic Markup" into "Separation Of Concerns"
  38. # [01:42] <mjs> that might capture the real point better, in addition to placating Murray (though I am not sure I get his point still)
  39. # [01:42] <Hixie> without changing the text of the principle?
  40. # [01:43] <mjs> well, with light editing to match the new name
  41. # [01:43] <Hixie> sure
  42. # [01:43] <mjs> Enable Separation Of Presentation From Content would be a bit unwieldy
  43. # [01:44] * anne agrees with Hixie that at some point the group needs to decide on by-argument versus by-majority
  44. # [01:44] <anne> SeparatePresentionContentAndBehavior
  45. # [01:44] <Hixie> i find it quite amusing given that HTML5 currently very carefully sidesteps the <b>/<i> issue by defining them semantically without breaking their presentational meaning
  46. # [01:44] <Hixie> avoid talking about Behaviour
  47. # [01:44] <Hixie> nobody knows what that is
  48. # [01:45] <Dashiva> It's :hover
  49. # [01:45] <anne> everything that involves events...
  50. # [01:45] <anne> but then <a> would violate it so nm
  51. # [01:45] <Hixie> i rest my case (you both gave totally different answers)
  52. # [01:46] <Philip> anne: But which decision method should the group use to decide which decision method to use?
  53. # [01:46] <Dashiva> I just bring up :hover whenever the case comes up because CSS fanatics don't seem to mind it even though they cry about separating out behavior
  54. # [01:46] <Hixie> some css fanatics
  55. # [01:46] <Hixie> don't lump us all in that bucket
  56. # [01:47] <Hixie> i personally think all the discussion about "separating behaviour" is one by red herring
  57. # [01:47] <Hixie> s/by/big/
  58. # [01:47] <Philip> If the majority thinks by-majority is best, but the best arguments come in favour of the by-argument side, it'll get a bit stuck
  59. # [01:47] <anne> Philip, benevolent dictator
  60. # [01:48] <Dashiva> Hixie: I don't consider people in your bucket fanatics
  61. # [01:48] <mjs> all we have to do is replace event handler attributes with xml events
  62. # [01:48] <mjs> then all behavior problems will be solved
  63. # [01:48] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  64. # [01:49] <anne> That would imply that introducing new stuff actually solves problems with existing technology...
  65. # [01:49] <anne> Sounds awesome!
  66. # [01:50] <anne> Philip, http://www.w3.org/mid/Pine.LNX.4.62.0704031953420.4736@dhalsim.dreamhost.com elaborates on that
  67. # [01:50] <Hixie> anyone able to find text in HTML4 that says you should ignore <td> tags when they're not in a <table>?
  68. # [01:51] <anne> ooh, SVG 1.1 errata
  69. # [01:51] <anne> Hixie, I think the IE guys already acknowledged that as a bug
  70. # [01:51] <mjs> by-argument invites the question of who decides what arguments are best
  71. # [01:51] <anne> at least one of them did, iirc
  72. # [01:52] <anne> mjs, the benevolent dictator
  73. # [01:52] <mjs> I would say the person responsible for taking action (most likely the editor of a relevant spec) should make the initial decision
  74. # [01:52] <mjs> and for lack of a better policy, vote of the group can override if someone calls for one
  75. # [01:52] <mjs> hopefully votes will be unwieldy enough to be used very rarely if ever
  76. # [01:52] <anne> that sounds reasonable enough
  77. # [01:53] * anne wonders why Murray is so hung up on +1 and -1
  78. # [01:53] <mjs> votes would hopefully also be preceded by reasoned discussion
  79. # [01:55] <Hixie> the problem with votes (not that i oppose them, just mentioning this) is that if the person making the decision hasn't yet made a new decision based on new arguments, but made a decision on old arguments, the vote can force the issue before the new arguments are considered
  80. # [01:55] <hsivonen> mjs: what I tried to get at Re: semantics was that defining reasonable presentation for different media is good enough and precise semantics aren't that important
  81. # [01:55] <Hixie> e.g. i have thousands of outstanding comments on HTML5 still to deal with, all of which have so far been "ignored", and people who raised them might think that i'm ignoring their feedback, and so might want to raise a vote
  82. # [01:56] * Joins: karl (karlcow@128.30.52.30)
  83. # [01:56] <mjs> hsivonen: I think different people have different exact views on this matter, and it's kind of hard to capture
  84. # [01:56] * Joins: htmlr (htmlr@138.130.176.60)
  85. # [01:56] <mjs> I think what we want to express is that HTML isn't gonna be XSL-FO, but we're not overly dogmatic about semantics
  86. # [01:57] * Joins: gavin (gavin@74.103.208.221)
  87. # [01:57] <anne> we don't want to repeat HTML 3.2 either i think
  88. # [01:57] <anne> (although the focus HTML 3.2 had on implementors was prolly good)
  89. # [01:57] <mjs> Hixie: I think issues should be discussed before voting is even considered, and arguments should be raised and given time to be considered before calling for a vote
  90. # [01:57] <hsivonen> nor become DocBook or TEI
  91. # [01:57] <mjs> Hixie: and also having a soft agenda of topics to discuss on-list might help people respect the queueing
  92. # [01:58] <mjs> Hixie: like saying "this month we will mostly discuss media elements, next two weeks after will be canvas" or something along those lines
  93. # [01:58] <Hixie> mjs: fair enough
  94. # [01:58] <mjs> obviously people can make a comment any time they want but should have less expectation of active discussion when it's not one of the focus topics
  95. # [01:59] <h3h> that kind of schedule would be awesome
  96. # [01:59] <anne> yeah, it would be useful if Hixie put his rough agenda somewhere in the draft again I think
  97. # [01:59] <h3h> but it assumes that there's some definitive list of issues to go through
  98. # [01:59] <hsivonen> I believe I have a number of comments in Hixie's queue and I've learned to route around the unresolved issues
  99. # [02:00] <hsivonen> nn
  100. # [02:00] <anne> g'night hsivonen
  101. # [02:01] <mjs> adding issues to a pool to be enqueued could be a distributed task, though I dunno how much anyone would enjoy doing it
  102. # [02:01] <Hixie> my schedule for the next quarter is <video>/<audio>, investigate adding something like the old <switch> proposal, and respond to 1000 feedback e-mails and fix 10 red issue boxes.
  103. # [02:02] <Hixie> for what that's worth.
  104. # [02:03] <anne> hmm, <option> is dropped indeed
  105. # [02:03] <anne> in html5lib that is
  106. # [02:04] <karl> http://www.searchtools.com/tools/tools-opensource.html to remember for testing
  107. # [02:04] * Joins: Lachy (chatzilla@58.105.240.232)
  108. # [02:14] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
  109. # [02:18] * Quits: Lachy (chatzilla@58.105.240.232) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
  110. # [02:22] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
  111. # [02:24] * Joins: Lachy (chatzilla@220.245.91.147)
  112. # [02:30] <Hixie> unsigned short is what, 8 bits or 16 bits?
  113. # [02:31] <mjs> in C? 16 bits
  114. # [02:31] <mjs> in IDL, I think also 16 bits
  115. # [02:31] <Hixie> thanks
  116. # [02:32] * Joins: olivier (ot@128.30.52.30)
  117. # [02:32] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  118. # [02:32] * Hixie is wondering whether to use the extra bits in the error value for further expansion, and ask people to do bitmask maths to find the error kind, or ask them to look for ranges of values; or, whether that's doomed and expansion will have to be in a separate field if we do it
  119. # [02:33] * Joins: marcos (chatzilla@131.181.148.226)
  120. # [02:34] <mjs> using short in an API is rarely beneficial
  121. # [02:35] <Hixie> oh i wasn't checking for that
  122. # [02:35] <Hixie> i was considering the bit mask idea and needed to know how many bits i had to put in the mask's value
  123. # [02:36] <Hixie> 0xF000 vs 0xF0
  124. # [02:36] <Hixie> or similar
  125. # [02:36] * Joins: htmlr_ (htmlr@203.206.237.84)
  126. # [02:36] <mjs> I'm not sure what you want to store in the error object
  127. # [02:36] <Hixie> right now it just has the kind of error -- aborted, network, or decode.
  128. # [02:37] <Hixie> it could have more, e.g. http-404, dns-failed, etc
  129. # [02:37] <Hixie> resource-was-video-but-i-was-expecting-audio
  130. # [02:37] <mjs> but one design that tends to be workable is to have a numeric code for the error domain (with known constants), a numeric value within that domain, a string description, and maybe optional extra data
  131. # [02:37] * Quits: htmlr (htmlr@138.130.176.60) (Ping timeout)
  132. # [02:37] <mjs> I think really detailed error reporting may be overkill though
  133. # [02:37] <mjs> aborted, network, decode seems like an ok starting point
  134. # [02:37] <Hixie> yeah, right now it's just aborted, network, or decode.
  135. # [02:37] <Hixie> i was just considering expansion options for future versions
  136. # [02:39] <mjs> if you want to make it expandable then probably making it an object rather than a primitive value is sufficient
  137. # [02:40] <Dashiva> I don't think xhr has more detailed than a catch-all NETWORK_ERR
  138. # [02:40] <Hixie> mjs: yeah that might work, just worried that that's too heavy duty.
  139. # [02:40] <Hixie> we'll worry about changing error later.
  140. # [02:40] <Hixie> i'll note it as an issue.
  141. # [02:54] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  142. # [02:54] <karl> hmm I wish browsers had a feature save as... valid xhtml/html
  143. # [02:55] <Dashiva> hehe
  144. # [02:56] <Dashiva> With (X)HTML5 defined serializations, that might become reality
  145. # [02:56] * Joins: h3h (bfults@70.95.237.98)
  146. # [02:59] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
  147. # [03:00] <mjs> it might not always be possible to make the document valid without altering presentation/behavior
  148. # [03:00] <mjs> (for example nesting blocks in inlines)
  149. # [03:11] * Quits: Dashiva (noone@129.241.151.35) (Quit: Dashiva)
  150. # [03:12] * Joins: h3h (bfults@70.95.237.98)
  151. # [03:13] * Joins: sbuluf (hem@200.49.140.228)
  152. # [03:14] * karl wonders if henri went ahead with wiki page for XTech ?
  153. # [03:15] <karl> maybe it should be on PeopleLocation page, more than creating a one time page
  154. # [03:15] <karl> http://esw.w3.org/topic/PeopleLocation hmm I wonder
  155. # [03:16] <karl> or something like
  156. # [03:16] <karl> http://esw.w3.org/topic/HTML/BOF
  157. # [03:16] * Joins: Dashiva (noone@129.241.151.35)
  158. # [03:18] <karl> ooooh
  159. # [03:18] <karl> http://esw.w3.org/topic/HTML/XTech2007BoF
  160. # [03:18] <karl> I see
  161. # [03:24] * Quits: kingryan (kingryan@66.92.187.33) (Quit: kingryan)
  162. # [03:37] * Quits: mjs (mjs@17.255.98.91) (Quit: mjs)
  163. # [03:42] * Joins: mjs (mjs@17.255.231.74)
  164. # [03:47] * Quits: mjs (mjs@17.255.231.74) (Quit: mjs)
  165. # [03:52] * Lachy wonders whether the decision of by-consensus vs. by-argument, should itself be determined by consensus or argument?
  166. # [03:55] <marcos> hehe
  167. # [03:57] <karl> Lachy: THAT is meta.
  168. # [03:57] <Lachy> karl: what do you mean?
  169. # [03:58] <karl> hmmm I guess the joke didn't go through
  170. # [03:58] <karl> this is a meta discussion
  171. # [03:58] <sbuluf> that it is a meta-level
  172. # [03:58] <karl> yep
  173. # [03:58] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  174. # [03:58] <sbuluf> an interesting one, certainly
  175. # [03:59] <Lachy> ok, just wasn't sure what you meant by meta
  176. # [03:59] <karl> and that is interoperability problems ;)
  177. # [03:59] <sbuluf> heh =P
  178. # [03:59] <marcos> lachy, perhaps you should express yourself in OWL
  179. # [04:00] * karl doesn't like the block/inline model for HTML.
  180. # [04:00] <Philip> I think the solution is to have the chair(s) decide, no matter how much fun infinitely recurring mailing list threads would be :-)
  181. # [04:00] <karl> hehe
  182. # [04:01] * marcos notices the beginings of another +1 usage debate in email :(
  183. # [04:01] <Lachy> Philip: +1
  184. # [04:03] <sbuluf> yesterday i wondered here if there were off limits topics to this working group (notably, back compat issues), or if everything was discussable. the answer at least some gave, was that everything was discussable...but that some players might leave if back compat, for instance, was broken
  185. # [04:04] * Joins: gavin (gavin@74.103.208.221)
  186. # [04:04] <sbuluf> that, imho, points to by-consensus.
  187. # [04:06] <Lachy> sbuluf: there's a difference between something that discussable and debatable. Everything can certainly be discussed, but there are just some things (like back compat) which just aren't up for debate because they are such fundamental goals
  188. # [04:07] <Lachy> also, I don't see how anything you said points to by-concensus
  189. # [04:07] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  190. # [04:07] <sbuluf> lachy, well...that's exactly why i asked yesterday about it here. you might be interested even in checking the log, perhaps. mjs, and anne, at least, seemed to think that everything was discussable (which was *not* my impression really.
  191. # [04:08] <Lachy> sbuluf: can you find and highlight the relevant section in the log for me?
  192. # [04:09] <sbuluf> lachy, probably, yes, give me a sec
  193. # [04:14] <sbuluf> http://krijnhoetmer.nl/irc-logs/html-wg/20070403#l-302
  194. # [04:14] <sbuluf> lachy, i think it starts there
  195. # [04:16] <Lachy> ok, I'll read it later
  196. # [04:16] <sbuluf> sure
  197. # [04:17] <sbuluf> karl, what's wrong with the block/inline model in HTML? and what would be an alternative?
  198. # [04:20] <Lachy> ah, the block-vs-inline debate is an interesting one, but the pragmatic side of me doesn't think it needs to be rehashed
  199. # [04:24] * Quits: Philip (excors@80.177.163.133) (Quit: Philip)
  200. # [04:24] <sbuluf> i'm ignorant, myself. i'm sure there might be finer points that i miss.
  201. # [04:25] <sbuluf> i tend to see things from an end-user point of view. and as such, the idea of block sounds like enclosing bigger structures in markup, while the inline one means to enclose just little chunks of text. as such, seems like a simple, graspable idea.
  202. # [04:26] <karl> sbuluf: bloc/inline is a kind of thing inherited from typography.
  203. # [04:27] <karl> the problem is that many elements of HTML should not be either block or inline
  204. # [04:27] <karl> the good examples is code and blockquote/q
  205. # [04:27] <karl> when we have elements which are used to give meaning to the content.
  206. # [04:27] <karl> the fact to be block or inline should not matter at all
  207. # [04:27] <karl> because it is not related
  208. # [04:28] <karl> so because we have block/inline, people try to hack on top of it
  209. # [04:28] <karl> and we have to create things like... blockcode
  210. # [04:28] <karl> it is insane somehow
  211. # [04:28] <karl> to have to create new elements just because of block/inline
  212. # [04:29] <sbuluf> mm, karl, thanks. i think i start to see what you mean. not completely sure, but i think is a start.
  213. # [04:30] <sbuluf> do you mean something like the semantic and thepresentational aspects get mixed up?
  214. # [04:30] <karl> something like that.
  215. # [04:31] <sbuluf> i think i see, thanks.
  216. # [04:31] <Lachy> there was an interesting thread on www-html back in 2004 (I think) that covered all the arguments for and against block vs. inline
  217. # [04:31] <karl> there are html elemts which are outside of this block/inline model
  218. # [04:32] <karl> and I think all the elements which carries only meaning should be outside of block/inline.
  219. # [04:35] <karl> Lachy: good memory
  220. # [04:35] <karl> http://lists.w3.org/Archives/Public/www-html/2004Jul/0015.html
  221. # [04:35] <sbuluf> thanks both =P
  222. # [04:37] <karl> and http://lists.w3.org/Archives/Public/www-html/2004Jul/thread.html#msg49
  223. # [04:38] <Lachy> http://lists.w3.org/Archives/Public/www-html/2003Dec/0123.html
  224. # [04:38] <Lachy> that's actually the message I was thinking of
  225. # [04:41] <karl> oh yes even better
  226. # [04:45] <sbuluf> i'm reading. and probably will be wise to chew it up a bit before saying much.
  227. # [04:46] <Lachy> it's interesting to re-read stuff I wrote 3 ago, and even though it's talking about XHTML2, it still seems quite good :-)
  228. # [04:47] <sbuluf> i feel that sometimes too. sometimes, the first impressions are keenest.
  229. # [04:52] <sbuluf> do you ever use the trick of analyzing how our minds perceive/organize the information in a document, by imagining a document ina foreing language, as seen from afar?
  230. # [04:53] <sbuluf> don't we organize it first by identifying "chunks"?
  231. # [04:56] <karl> sbuluf: there are definitely surprising things when you look at other languages
  232. # [04:57] <karl> examples
  233. # [04:57] <karl> http://www.la-grange.net/2006/02/04-3810-japon-texte-1.jpg
  234. # [04:57] <karl> http://www.la-grange.net/2006/02/04-3811-japon-texte-1.jpg
  235. # [04:57] <karl> http://www.la-grange.net/2006/02/04-3812-japon-texte-1.jpg
  236. # [04:57] * karl is going to lunch
  237. # [05:01] <sbuluf> (just for the record, even if top-to-bottom instead of left-to-right, i still see chunks)
  238. # [05:04] <Lachy> someone please explain to Brad Fults (on the mailing list) that it's ok for specs themselves to be numbered, but that is completely different from versioning in the language
  239. # [05:04] * Lachy is going to lunch
  240. # [05:14] <h3h> no need to explain
  241. # [05:14] <h3h> it was a passing observation
  242. # [05:15] <h3h> and stated quite clearly in question form
  243. # [05:15] <Zeros> We should just go with HTML-TR2010 (HTML Technical Revision 2010) or some such
  244. # [05:16] <Zeros> all the major/minor versioning, even for the spec itself, seems unnecessary.
  245. # [05:19] <h3h> don't tell Lachy that :P
  246. # [05:42] <Lachy> h3h, I didn't realise you were Brad
  247. # [05:42] <h3h> I hope that doesn't cause you to censor yourself :)
  248. # [05:42] <Lachy> Zeros: it would be silly to include the year in the name, especially when it's highly unlikely that HTML5 will actually be finished by 2010
  249. # [05:43] <Lachy> h3h: I never censor myself
  250. # [05:43] <h3h> good
  251. # [05:45] <Zeros> Lachy, the year would be decided when we publish it as a REC
  252. # [05:45] <Zeros> not now
  253. # [05:46] <Lachy> it's still silly to put it in the title
  254. # [05:46] * marcos hopes he can finish reding the 40+ page HTML5 spec by 2010!
  255. # [05:46] <Lachy> just like it was silly to put the year in the namespace URI
  256. # [05:46] <marcos> s/reding/reading
  257. # [05:46] <Zeros> Lachy, Why? Its a unique identifer, other wise we end up with HTML6 and then HTML7 and what about a minor change of HTML6.251
  258. # [05:46] <h3h> yeah, years are a bad idea for a spec that's supposed to be definitive for years to come
  259. # [05:46] <Zeros> 4.01, XHTML1.1
  260. # [05:47] <h3h> I'd be fine with HTML 5.0
  261. # [05:47] <Lachy> numbering incrementally is sufficient
  262. # [05:47] <Zeros> h3h, the year has to do with publication, it differentiates if from a later revision
  263. # [05:47] <h3h> Zeros: that's what the "latest version" and "previous version" etc. links are for at the top of all W3C published docs
  264. # [05:47] <Zeros> It doesn't change validity at all 10 years from now, nor does HTML5 since anyone can lookup the publish date anyway
  265. # [05:48] <h3h> years make people want to upgrade. years are good for consumer products like MS Office
  266. # [05:48] <Zeros> h3h, once its made into a REC that's the last version, I don't think we should be calling this HTML5
  267. # [05:48] <Zeros> what do we call the XHTML serialization of ti?
  268. # [05:48] <Zeros> s/ti/it/
  269. # [05:48] <h3h> that's the last version? somehow I doubt that
  270. # [05:49] <Zeros> h3h, the REC is the last version of that spec
  271. # [05:49] <h3h> the language, like the world, will continue to evolve even after this wg is done
  272. # [05:49] <Zeros> that would be a different revision
  273. # [05:49] <h3h> sure, then the next one is 6.0...
  274. # [05:49] <Zeros> h3h, or 5.2
  275. # [05:49] <h3h> sure if it's a minor revision or whatever
  276. # [05:49] <Zeros> we had 3.2 and then 4.01
  277. # [05:49] <h3h> the corresponding XHTML version number is another good question
  278. # [05:49] <Zeros> why do we need minor and major versions, and who decides that's minor and major?
  279. # [05:50] <h3h> if that even deserves a name+version number
  280. # [05:50] <h3h> I'm guessing not
  281. # [05:50] <h3h> there's just HTML-as-HTMl and HTML-as-XML
  282. # [05:50] <sbuluf> the years-in-url's general rationale, if i understood correctly, is because a domain can be reassigned to a new authority, eventually, and this helps identify when a certain url was issued, and who was the authority then (i'm not saying i vouch the idea, though)
  283. # [05:50] <Zeros> h3h, That's not real helpful, then people make up names and terms.
  284. # [05:51] <h3h> possibly
  285. # [05:51] * Joins: mjs (mjs@64.81.48.145)
  286. # [05:52] <karl> [12:46] <Lachy> just like it was silly to put the year in the namespace URI
  287. # [05:52] <karl> Lachy: dates in URI are not always dates :)
  288. # [05:52] <karl> dated space is a very useful way of creating unique identifiers. :)
  289. # [05:54] <sbuluf> and unique-in-long-time-periods (i.e, "eternal"), even if authority changes, is what i meant
  290. # [05:55] <Lachy> karl: what are they if they're not dates?
  291. # [05:56] <Lachy> I'm glad the new namespace policy says to use /ns/ instead of /YYYY/
  292. # [05:59] * Joins: zcorpan (zcorpan@130.243.79.10)
  293. # [06:01] <karl> Lachy: I just said it a way to create unique identifiers.
  294. # [06:03] <karl> just think about a system of creating unique identifiers in an information space.
  295. # [06:03] <karl> which is practical and easy
  296. # [06:03] <mjs> http://esw.w3.org/topic/HTML/ProposedDesignPrinciples -- thoughts on "Separation of Concerns" as replacement for "Mostly Semantic Markup"?
  297. # [06:04] <sbuluf> i have some strong opinions about it, but probably exceeds what would be useful to discuss here (karl, we have discussed some of them before, you know me as Biblio in freenode, and as fernando franco in the TAG mailing list)
  298. # [06:04] <Lachy> I disagree. Dates in URIs are useful for identifying the date of publication for articles, specs, etc. But when the date has no relevance, it's pointless
  299. # [06:04] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
  300. # [06:04] <marcos> +1
  301. # [06:04] <karl> Lachy: forget about the date :)
  302. # [06:05] * mjs gives marcos a dirty look
  303. # [06:05] <marcos> hehe
  304. # [06:05] <karl> and design a system to create unique identifier
  305. # [06:05] <Lachy> mjs: +1
  306. # [06:05] * mjs sighs
  307. # [06:05] <Lachy> -1
  308. # [06:05] * Joins: zcorpan (zcorpan@130.243.79.10)
  309. # [06:06] <karl> mjs: why don't you just leave Separation of Concerns
  310. # [06:06] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  311. # [06:06] <karl> do not create camps, but just build argumentation on what you want
  312. # [06:06] <karl> a double title leads to argument
  313. # [06:07] <mjs> karl: it's in the Disputed section because the past version was disputed
  314. # [06:07] <karl> :)
  315. # [06:07] <karl> yes but the dispute is about a topic
  316. # [06:07] <mjs> karl: I try to reflect multiple points of view when there is not consensus
  317. # [06:08] <mjs> (although I hope the latest version can sustain a broader consensus)
  318. # [06:09] <karl> http://esw.w3.org/topic/MeaningVsBehavior
  319. # [06:09] <karl> which is specifically a bad example :p
  320. # [06:09] <karl> topic 1 vs topic 2
  321. # [06:09] <karl> :)
  322. # [06:10] <Zeros> MeaningAndBehavior would probably be better
  323. # [06:10] <karl> yep Zeros indeed
  324. # [06:10] <mjs> karl: the "vs" only reflects cases where we haven't yet settled on a principle, it is not intended to be lasting
  325. # [06:10] <mjs> karl: I would prefer to reflect substantive disagreement than to only push my own point of view
  326. # [06:10] <sbuluf> http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm <--some of you might find some value to this topic here
  327. # [06:11] <karl> mjs: I agree with you on the desire to illustrate the two points of view
  328. # [06:11] <karl> I can't find the reference in wikiwikiweb
  329. # [06:11] * Joins: zcorpan_ (zcorpan@130.243.79.10)
  330. # [06:11] <karl> about the patterns for discussions
  331. # [06:11] * Joins: gavin (gavin@74.103.208.221)
  332. # [06:11] <karl> :)
  333. # [06:12] <mjs> I can say "or" instead of "vs"
  334. # [06:12] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
  335. # [06:12] <mjs> but I'm not sure that is any better
  336. # [06:12] <karl> maybe there is a meta category to this two names
  337. # [06:12] <karl> these
  338. # [06:13] <sbuluf> to identify and properly categorize and name design goals, is not an easy task
  339. # [06:13] <Zeros> I'd rather use "And" since it implies both topics are being discussed there rather than its a battle between the two.
  340. # [06:13] <sbuluf> i've done a little of that myself, and is definitely not easy
  341. # [06:14] <mjs> Zeros: well, when there's mutually exclusive alternatives, it's hard to dress it up
  342. # [06:14] <karl> there are elements for structure (table), meaning only (code), functionalities (form, head), style (b), etc.
  343. # [06:15] <Zeros> mjs, yeah. Really I don't think its all /that/ important as long as its more descriptive than DeclWebFormExpr
  344. # [06:15] <karl> and I'm pretty sur if we were drawing circles around each element (as in tagging them with category), we would have different drawings depending on the people
  345. # [06:16] <mjs> I probably should have said something about how it's best for an element to have both a meaning and a default presentation
  346. # [06:17] <karl> mjs: I see how it can help, but I see the drawback as well.
  347. # [06:17] <Zeros> default presentation in the abstract sense
  348. # [06:17] <sbuluf> karl, don't you find my approach cleaner? particularly, from the url above... "CDL cleanly separates content, from presentation, from structure, from semantics, from behaviour"
  349. # [06:17] <karl> example: blockquote used for indenting text
  350. # [06:17] <Zeros> I don't think we should specify it, we can't possibly make it work for all UAs
  351. # [06:18] <karl> we may guess that blockquote has been abused because of the presentation
  352. # [06:19] <Zeros> mjs, where does Webkit currently content sniff documents to figure out the mime?
  353. # [06:20] * karl is looking at sbuluf link
  354. # [06:22] <mjs> Zeros: content sniffing is in the network layer we use on Mac OS X
  355. # [06:22] <karl> s/semantics/meaning/ would be better in the document, I guess. but there is an idea indeed. and still, I'm pretty sure we all have a different opinions of what convey meaning or not.
  356. # [06:23] <karl> structure is very often inherited from paper typography, which has its limits in web world.
  357. # [06:23] <mjs> I think it comes down to how you would describe the difference between HTML and a pure visual formatting language like PDF
  358. # [06:23] <sbuluf> semantics would be more technically precise, yes, i used meaning since is easier for end-users, hence good for reducing learning curve
  359. # [06:23] <karl> meaning is better than semantics.
  360. # [06:23] <karl> less confusion
  361. # [06:24] <sbuluf> karl, by structure, i mean just "a bunch of [ordered] fields (i.e, label/value pairs
  362. # [06:24] <karl> but I really appreciate the work of mjs, I think it is a very valuable work which is done right now
  363. # [06:25] <karl> aka The Design Principles
  364. # [06:25] <sbuluf> i think to clearly state design goals is totally vital
  365. # [06:25] <Zeros> mjs, What is it using to content sniff the <object> then, the file extension? My local test has Safari showing the source when its sent as text/plain, though the file extension isn't html anymore.
  366. # [06:25] <mjs> how would you guys describe the difference between HTML and PDF? (other than the fact that PDF is a binary format - in theory it could be an XML grammar)
  367. # [06:26] <mjs> Zeros: it sniffs based on content, not filename
  368. # [06:26] <sbuluf> pdf is a language for printers, not a content authoring format
  369. # [06:26] <karl> mjs: PDF is a graphical format
  370. # [06:26] <Zeros> mjs, the content of the file is an html document, still shows the source.
  371. # [06:27] <sbuluf> imho, pdf should not even exists, and html/css should cover printing decently, instead
  372. # [06:27] <karl> when you copy and paste a PDF text, the whole structure and meaning of the document is jumbled.
  373. # [06:27] <Zeros> karl, That's not quite true since PDF has annotations and extra metadata in tags now
  374. # [06:27] <mjs> people make WYSYWIG tools to edit PDF
  375. # [06:27] <sbuluf> no lossless conversion, exactly
  376. # [06:27] <mjs> and it can be viewed interactively
  377. # [06:27] <mjs> and even supports hyperlinks
  378. # [06:28] <sbuluf> no lossless conversion, exactly <--this turns into an *output* format
  379. # [06:28] <Zeros> You could certainly write something that copy and pastes the pdf as is karl
  380. # [06:28] <karl> I guess it might be possible to create a logical flow in PDF, but each time I have tried to cut and paste document, with Apple Preview for example
  381. # [06:29] <karl> I ended up with a text making a poetic mixing of all paragraphs and lines
  382. # [06:29] <sbuluf> it never works, and exporting back to other formats, does not work either, no lossless conversion
  383. # [06:30] <Zeros> that doesn't work with HTML either
  384. # [06:30] <mjs> RTF is another good example for comparison
  385. # [06:31] <mjs> (cutting and pasting from it does not jumble logical flow, but it is much more presentational than HTML)
  386. # [06:31] <karl> I wonder if CSS 3 layout implemented in wysiwyg tools will give the same problems.
  387. # [06:31] <karl> like for tables
  388. # [06:31] <sbuluf> txt, rtf, pdf...it is 2007, and we still do not have a half decent content authoring language
  389. # [06:32] <sbuluf> html+css should be the best, and only one (what so many for?), but it has serious flaws
  390. # [06:32] <karl> sbuluf: it is only 30 years ;) peanuts
  391. # [06:32] <Zeros> How do you represent HTML on the clipboard to preserve the logical flow? As rendered with styles the flow the user sees may not be the document order.
  392. # [06:32] <sbuluf> kerl =P
  393. # [06:33] <sbuluf> zeros..ahh...html and wysiwyg editing, a broken topic these days
  394. # [06:33] <karl> I think we will not succeed thinking like that.
  395. # [06:33] <mjs> I think we're wandering off topic
  396. # [06:33] <mjs> or at least, my point wasn't to talk about why everything sucks
  397. # [06:33] <mjs> but rather, what's different about HTML than other rich hypertext formats
  398. # [06:33] <karl> we may have to think in terms of what the language can help us to do in certain contexts, having in mind that it can be always abused
  399. # [06:34] <Zeros> sbuluf, you said "no lossless conversion, exactly" in response to karl's comment on the jumble when pasting
  400. # [06:34] <karl> and being abused is somehow a feature.
  401. # [06:34] <Zeros> sbuluf, HTML has the same problem since the semantics (meaing) in the document are generally lost when pasting elsewhere
  402. # [06:34] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  403. # [06:34] <Zeros> you do lose something
  404. # [06:34] <sbuluf> the wg charter mentions editing API's and WYSIWYG editing tools, right? i wonder how seriously that is being considered. and if it should not even be included in mjs's design goals list
  405. # [06:35] <karl> mjs: do you have contacts with iWeb?
  406. # [06:35] <sbuluf> mm, zeros, have you seen the link i posted above? it might (or might not) be of relevance for this as well
  407. # [06:35] <karl> iWeb Team
  408. # [06:35] <mjs> karl: some
  409. # [06:35] <karl> it would be good to have them on the group
  410. # [06:35] <Zeros> sbuluf, for that other document language; CDL?
  411. # [06:35] <sbuluf> zeros, yes.
  412. # [06:35] <mjs> if the follow-up question is "can I influence the kind of markup they generate?" then the answer is "only very indirectly"
  413. # [06:36] <karl> the question was can you make them participate
  414. # [06:36] <Zeros> sbuluf, its an interesting idea, looks an awful lot like RDF
  415. # [06:36] <karl> authoring tools are essential
  416. # [06:36] <Zeros> sbuluf, very abstract
  417. # [06:37] <sbuluf> zeros, the "meaning" part should be rdf like. but the rest should be a sort of functionality like what html does today
  418. # [06:37] <mjs> I'm not sure any of them are sufficient experts on web technology to usefully participate
  419. # [06:37] <sbuluf> zeros, totally empty, in fact. just full of hooks
  420. # [06:38] <karl> mjs: could you try to invite them to participate or if you give me a contact person, I can invite them.
  421. # [06:39] <Zeros> sbuluf, Well, speaking just for me, RDF is very complicated and very abstract. Too much so to be of any use to a general editor which is what we seem to be targeting with the HTML WG. If we went with that much abstraction I think we'd be making a mistake. I mean, if we used 100 lines of XML and pronunciation keys and definitions and logical flow languages all bundled together we could certainly get more meaning into a single document than HTML does.
  422. # [06:39] <Zeros> it'd just be unwieldy
  423. # [06:39] <karl> mjs: I also see that Pages can export as html. Another case that would be useful. Another team of people.
  424. # [06:39] <mjs> karl: I can spread the word to them, but like I said, I'm not sure they would have a lot to add
  425. # [06:40] <mjs> HTML to them is an export format used for presentation-oriented final delivery on the web
  426. # [06:40] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
  427. # [06:40] <karl> I think at least it could help to build more awareness for them
  428. # [06:40] <karl> on the correct things to do.
  429. # [06:41] <Zeros> I'd be pretty cool if TextEdit exported more semantic markup. It already generates a valid HTML4 skeleton document which is nice.
  430. # [06:41] <karl> and they may have questions that we didn't think about
  431. # [06:41] <mjs> we do talk to them about their HTML export related issues
  432. # [06:41] <mjs> and gave some suggestions for improving their markup and styling
  433. # [06:41] <karl> with knives and hammers ?
  434. # [06:41] <karl> WOW style negotiations?
  435. # [06:41] <mjs> but iWeb and Pages are not (yet) major web content authoring tools
  436. # [06:42] <mjs> would be more interesting to have folks who work on Dreamweaver or similar
  437. # [06:42] <karl> yes
  438. # [06:42] <karl> I wish Adobe was part of the WG.
  439. # [06:42] <mjs> I believe Adobe is involved in the CSS WG so that wouldn't be out of the question
  440. # [06:42] <karl> I'm trying on this side too
  441. # [06:42] <sbuluf> mjs, should the whole wysiwyg editability topic be included in the design goals list as well? is it a design goal?
  442. # [06:43] <mjs> sbuluf: I think of support for editing APIs as a required feature, not a design goal
  443. # [06:43] <Zeros> I know a couple people over at Adobe, I could drop hints at the conference in June, but I don't think anyone related to DW will be there.
  444. # [06:43] <mjs> top missing participants I'd like to see involved:
  445. # [06:44] <mjs> Microsoft, Adobe, Nokia, BM, Sun
  446. # [06:44] <mjs> (that should be IBM, not BM)
  447. # [06:45] <Zeros> MS should be joining eventually?
  448. # [06:45] <Lachy> Zeros: Chris Wilson from MS will be the Chair
  449. # [06:46] <Lachy> so yes, eventually
  450. # [06:46] <Zeros> Lachy, So I've read, but there doesn't seem to be any development on that.
  451. # [06:46] <Lachy> DanC: was going to follow up on it I think
  452. # [06:47] <Zeros> cool
  453. # [06:48] <sbuluf> i can not help but to wonder how many people, and how seriously have given thought to the wysiwyg editability problem
  454. # [06:48] <Lachy> lots of people have thought about it, few people think about it correctly and even fewer even try to implement it sensibly
  455. # [06:49] <sbuluf> i thouht about it some, and i found it might be just about impossible, with html as it stands today
  456. # [06:49] <Lachy> why
  457. # [06:50] <sbuluf> i don't think i could make a bullet list right now, but my general feeling, is that html simply was not developed, over time, keeping that topic as a design goal
  458. # [06:50] <sbuluf> and hence html+css have become too complex for sensible wysiwyg editability
  459. # [06:50] <Zeros> Lachy, lack of mind reading technology and neural nets. Software that's powerful enough to ascertain the meaning of the content you're typing and then add the proper elements to pull it off remains to be seen.
  460. # [06:51] <Zeros> Styling it is also problematic because browsers all render differently. How do you write a wysiwyg tool that works around bugs in all the browsers and still provides what the user wanted?
  461. # [06:52] <Lachy> Zeros: it doesn't require anything nearly that complex. It just requires suitable interfaces for the user to tell the editor what the content is
  462. # [06:52] <sbuluf> i agree
  463. # [06:52] <Zeros> Lachy, And then style it how?
  464. # [06:53] <Lachy> unfortunately, so many developers keep copying the Word Processor interface, instead of innovating with something really good
  465. # [06:53] <Zeros> What about bugs in Firefox and Safari's float model or the hasLayout ones in IE that cause really odd bugs like missing blocks, text content, images, extra spaces...
  466. # [06:53] <Lachy> Zeros: I gave a brief overview of how an editor should work either in this channel or #whatwg a week or two ago, check the logs
  467. # [06:53] <sbuluf> lachy, agreed again.
  468. # [06:54] <mjs> users don't seem to be good at thinking about meaning instead of style
  469. # [06:54] <sbuluf> lachy and i also discussed the topic some a couple of days ago
  470. # [06:54] <Zeros> Lachy, I will; though i don't think its possible to make any type of wysiwyg editor for HTML.
  471. # [06:54] <Lachy> mjs: it depends upon the way you present the choices to the uesr
  472. # [06:54] <Zeros> Not one that generates decent markup and renders consistently anyway.
  473. # [06:55] <sbuluf> one general question: have you seen the url i posted above, in the light of precisely this editability problem?
  474. # [06:55] <Lachy> sbuluf: what UIR?
  475. # [06:55] <mjs> it's possible to make a WYSIWYG editor, just not one that outputs markup that we'd consider as following best practices
  476. # [06:55] <Lachy> *URI
  477. # [06:55] <mjs> (I mean, the latter might be possible too, it's just beyond the current state of the art)
  478. # [06:56] <sbuluf> lachy, http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm
  479. # [06:56] <sbuluf> particularly, from the url above... "CDL cleanly separates content, from presentation, from structure, from semantics, from behaviour"
  480. # [06:56] <Lachy> one day I'll get around to writing up a descent description of how a good WYSIWYG editor should work
  481. # [06:57] <sbuluf> lachy, please do
  482. # [06:57] <Zeros> Well, if we implemented XHTML2 and an entirely new style language we could get the same thing we'd get from CDL sbuluf. All the implementations would be new.
  483. # [06:57] <Zeros> We'd just have to make the spec so strict that everyone's implementation would be the same, hah.
  484. # [06:58] <sbuluf> zeros, exactly
  485. # [06:58] <Lachy> the interface would need to be task oriented, rather than presentation oriented
  486. # [06:58] <sbuluf> unfortunately, i dont think that is in scope here, which is why yesterday i asked certain questions here. and is also why i think it would probably need to be done separately from w3c
  487. # [06:59] <sbuluf> http://www.teoriadetodo.com.ar/fips/ <--zeros
  488. # [07:00] <mjs> xhtml2 and CDL would both be out of scope for this group
  489. # [07:00] <mjs> xhtml2 isn't out of scope for the xhtml2 WG
  490. # [07:00] <sbuluf> mjs, see now why i asked all those questions yesterday?
  491. # [07:00] <Zeros> sbuluf, I can't find it right now, but there's a document about how to write a good spec, and one of the main points is "The reference implementation should not be the only possible implementation"
  492. # [07:01] <Zeros> Not that I think that's possible with HTML anyway since it needs to render on so many different types of UAs
  493. # [07:01] <mjs> sbuluf: you could have asked more directly
  494. # [07:02] <sbuluf> mjs, well, you might note that i was not quite asking, in fact. i was just suggesting that part or either the charter or your design goals list could, and probably should, be more explicit about the whole wg scope
  495. # [07:03] <sbuluf> mjs, if you noticed, i did not think, at all, that any CDL related stuff would be within scope. pretty much the opposite.
  496. # [07:03] <sbuluf> i just mentioned it today, cause it seemed relevant to a topic at hand, perhaps some ideas could help
  497. # [07:07] * Joins: icaaq (icaaaq@85.228.55.162)
  498. # [07:16] <sbuluf> mjs, i just relized, btw, that my own design goals page is not up to date (that's a very old version). would yopu like me to upload a more up to date one, just in case anything might be of use for yours?
  499. # [07:17] <mjs> sbuluf: depends - what project are your design goals for?
  500. # [07:17] <sbuluf> mjs, CDL, not same as yours. and many points are even diametrically opposed to wat this wg has in mind. but perhaps, even then, some might be of use.
  501. # [07:18] <Zeros> CDL is your project?
  502. # [07:18] <sbuluf> barely ideas up to now, zeros. those pages, as you surely noted, are terrible beta
  503. # [07:19] <mjs> I'm mainly interested in things that will be relevant to the design of the next generation of HTML
  504. # [07:19] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
  505. # [07:19] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
  506. # [07:20] <sbuluf> mm, i'll take that as a "no", i think.
  507. # [07:21] <sbuluf> zeros, i'm behind it, yes, if that's what you meant
  508. # [07:34] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
  509. # [07:38] <sbuluf> lachy, do you think you'll wirte about proper wysiwyg (or wymiwyg) editing soon?
  510. # [07:38] <Lachy> no idea, it depends if I have the time, motivation and knowledge to do so
  511. # [07:39] * Joins: heycam (cam@203.214.79.176)
  512. # [07:39] * Joins: Grauw (ask@202.71.92.74)
  513. # [07:39] <sbuluf> lachy, teoriadetodo at gmail is my mail adress, in case you do
  514. # [07:40] <sbuluf> i offer myself to diuscuss the topic further, or to contribute to writing, if you ever decide to go on
  515. # [07:40] <Lachy> send me an e-mail about it
  516. # [07:40] <sbuluf> right.
  517. # [07:41] <Lachy> otherwise, I'm likely to forget
  518. # [07:41] <sbuluf> same happens to me =P
  519. # [07:43] <sbuluf> i reckon it will be important too, curiously. this wg charter includes a line, apparently requiring wysiwyg editing as a feature. but i reckon it might turn out to be just about impossible, with current state of specs
  520. # [07:44] * Joins: mjs (mjs@64.81.48.145)
  521. # [07:47] <Lachy> the wysiwyg editing feature is referring to contentEditable, not to general HTML authoring tools
  522. # [07:49] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  523. # [07:49] <sbuluf> the charter says "Editing APIs and user-driven WYSIWYG editing features"
  524. # [07:49] <Zeros> We should create a standard for what contentEditable generates. Its useless if every browser makes something different.
  525. # [07:50] <sbuluf> ithought the API's bit referred to programmatical way, while the WYSIWYG bit referred to end-user authoring tools
  526. # [07:50] <sbuluf> you reckon this is not the cacse, lachy?
  527. # [07:50] <sbuluf> *case
  528. # [07:50] <mjs> that's not the intent
  529. # [07:50] <mjs> contentEditable allows live editing, execCommand is the API
  530. # [07:52] <MikeSmith> mjs - about your earlier question on difference between HTML and PDF as rich hypertext formats ...
  531. # [07:52] <sbuluf> mjs, if that was an answer for me, thanks, i'm not sure i undertand, or know enough, but i'll research some.
  532. # [07:53] <Zeros> execCommand is poorly named
  533. # [07:53] <MikeSmith> I wonder if the distinction of considering PDF to be a "terminal" or "final" rendering format makes sense
  534. # [07:53] <MikeSmith> and also the distinction that PDF is intended to be a user-unalterable presentation of the page layout as the author intended it
  535. # [07:55] <MikeSmith> while browsers and other UAs allow end users the choice to display HTML in alternate presentational views
  536. # [07:55] <MikeSmith> for example, by selecting their own CSS stylesheet instead of using the author's CSS
  537. # [07:55] <MikeSmith> or supplementing the author's CSS
  538. # [07:58] <mjs> I users selecting their own stylesheet really the main thing that is different about HTML?
  539. # [07:58] <mjs> because very few users do that
  540. # [07:59] <marcos> MikeSmith: I thought PDF allowed at least some of that flexibility... unlike PostScript which I assume would be fairly close to a final rendering format.
  541. # [07:59] <MikeSmith> mjs - well, perhaps it's not just the fact that users can alter the presentation, but that UAs can also
  542. # [07:59] <MikeSmith> for example, the Small Screen Rendering view in Opera Mobile/Mini
  543. # [08:00] <Zeros> Can you embed remote resources into a PDF?
  544. # [08:00] <MikeSmith> (which as I guess you know puts all content into a single column)
  545. # [08:00] <MikeSmith> Zeros - yes
  546. # [08:00] <Zeros> Hmm, so you can load images on another server.
  547. # [08:00] <MikeSmith> you can embed other (hyperlinked) PDFs within a PDF
  548. # [08:01] <MikeSmith> Zeros - sorry, I missed the word "remote"
  549. # [08:01] <MikeSmith> I don't know about embedding remote resources
  550. # [08:01] <Zeros> I'd say that's a big difference between HTML and PDF
  551. # [08:02] <sbuluf> for, me, the main issue is: "can PDF be considered a good content authoring format?" and given that in practice, i never seem to achieve lossless PDF-to-other-formats lossless conversion, the answer seems to be "no"
  552. # [08:02] <Zeros> You can use dataurls, but they're pretty limited
  553. # [08:02] <Zeros> sbuluf, the same is true of HTML though, so what do you gain using one over the other?
  554. # [08:03] <Zeros> That was the issue that mjs was presenting I think
  555. # [08:03] <marcos> The level of abstraction of Pdf is too close to the final form.
  556. # [08:03] <MikeSmith> marcos - I know PDF allow some flexibility, but I would argue that a large part of their distinctive value is that they don't let users or PDF UAs (Acrobat Reader, xpdf, whatever) alter the basic page layout
  557. # [08:04] <MikeSmith> part of the value of having a PDF is that I say say to you, look at the second paragraph down on page 12
  558. # [08:04] <sbuluf> sbuluf, it might be true about HTML, perhaps (i dunno, some seem to think properly coded HTMl might work). but what about once we move into XML-land? doesn't XML, by its strict nature, or some other factors, achieve a "lossless reprocessability" goal?
  559. # [08:04] <MikeSmith> and know that you'll be looking at the same thing as me
  560. # [08:04] <sbuluf> s/sbuluf/zeros/
  561. # [08:05] <marcos> and I would say look at some.html#identifier and we would be looking at the same thing?
  562. # [08:05] <Zeros> sbuluf, there's no way to convert from XHTML to some random format and back to XHTML without losing something
  563. # [08:05] <marcos> kinda sorta
  564. # [08:05] <Zeros> same with PDF
  565. # [08:05] <mjs> higher level of abstraction might be a good way to think about it but is hard to express clearly and concisely
  566. # [08:05] <MikeSmith> marcos - yeah, true
  567. # [08:06] <mjs> I think most people would agree that elements like <margin> or <textcolor> would be inappropriate for HTML
  568. # [08:06] <marcos> MikeSmith, I can change the print layout of PDF as well so what you say may not always hold
  569. # [08:06] <mjs> is there a way to say why those don't make sense, but <section> or <figure> do?
  570. # [08:07] <sbuluf> zemjs, <section>, or <figure>, are datastructures, while the former are just presentation?
  571. # [08:07] <marcos> because <figure> is more of a common design pattern that can be abstracted?
  572. # [08:07] <marcos> and so is section
  573. # [08:07] <MikeSmith> marcos - I know it doesn't always strictly hold, but I think in common practice it fits the normal use cases for PDFs
  574. # [08:08] <mjs> having margins is also a common design pattern
  575. # [08:08] <sbuluf> mjs, but isn't it presentation, as opposed to a datastructure?
  576. # [08:08] <marcos> but that is presentational
  577. # [08:08] <mjs> I don't know what it means to say some markup is a data structure and other markup isn't
  578. # [08:08] <Hixie> mjs: that's just media independence
  579. # [08:08] <marcos> content, structure and style are the separations of concerns
  580. # [08:08] <MikeSmith> mjs - saying that HTML has a higher level of abstraction seems to me like a relatively clear and understandable way to describe it
  581. # [08:09] <mjs> MikeSmith: but that doesn't clarify how to express the right level of abstraction
  582. # [08:09] <sbuluf> mjs, by datastructure i mean, roughly, a bunch of )optionally ordered) data fields (namely, label/value pairs
  583. # [08:09] <mjs> perhaps media independence and ability to alter presentation without changing the content (what I called Separation of Concerns) are really the main points to capture
  584. # [08:10] <marcos> the right level of abstraction might be based on usage patterns in the wild.
  585. # [08:10] <sbuluf> mjs, examples of datastructures in documents: a list, a table, a paragraph (the simplest one), etc
  586. # [08:10] <marcos> All english speakers might agree that we don't need to mark up things at the level of <word> or <character>
  587. # [08:10] <marcos> but <p> is ok
  588. # [08:11] <mjs> sbuluf: so out of <em> or <i> or <textcolor>, which would you consider a data structure?
  589. # [08:11] <Zeros> mjs, A figure is a fundamental unit of a document. It defines a region of the document and its meaning. <margin> isn't defining a region of the document, but rather how to display another region that has a meaning beyond just the visual presentation.
  590. # [08:11] <marcos> sorry, I missed the definition of "data structure" in this context ?
  591. # [08:12] <sbuluf> mjs, i consider things like <em> or <strong> a lishgtly different problem, cause while they *do* enclose content, and *can* be seen as a label/pair value, they are inline, while usually datastructures are bloicks, chunks. is this useful?
  592. # [08:13] <sbuluf> marcos: mjs, by datastructure i mean, roughly, a bunch of )optionally ordered) data fields (namely, label/value pairs
  593. # [08:13] <Zeros> sbuluf, your own statement shows its useful
  594. # [08:13] <Zeros> "and *can* be seen"
  595. # [08:13] <mjs> I'm not sure "data structure" clarifies anything
  596. # [08:13] <Zeros> the emphasis you added with *'s
  597. # [08:14] <MikeSmith> mjs - I think as far as writing a description goes, having some concrete illustrative examples included along with the description would help; e.g., "Having a document source in HTML form allows a user or UA to do X -- easily -- while having it in PDF (or whatever) form does not."
  598. # [08:14] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  599. # [08:14] <Zeros> Without <strong> and <em> that's not possible unless we make something up sbuluf
  600. # [08:14] <marcos> yeah, data structure makes little sense to *me* in this context
  601. # [08:15] <sbuluf> datastructures are, roughyl, any instance of what is commonly referred to as "structured content". i.e, anything you might want to plug in databases, normally
  602. # [08:15] <Zeros> What about construct?
  603. # [08:15] <mjs> <em> and <i> and a hypothetical inline <textcolor> element would all have the exact same logical relationship to their contained text
  604. # [08:15] <Zeros> as in "language construct"
  605. # [08:15] <mjs> I don't think HTML elements map very well to language constructus
  606. # [08:15] <Zeros> mjs, only to a visual UA
  607. # [08:15] <mjs> most of them are above the level of language
  608. # [08:16] <marcos> you mean the DOM?
  609. # [08:16] <mjs> Zeros: what I mean is they tag a sequence of characters with a label
  610. # [08:16] <Zeros> mjs, oh okay, then yes, they're the same.
  611. # [08:16] <mjs> that is just as much a "data structure" or not, regardless of what the label is
  612. # [08:17] <Zeros> yeah, I see what you're saying. Data structure seems like a bad term then?
  613. # [08:17] <mjs> I think this might be too abstract to result in a useful design principle
  614. # [08:17] <marcos> I can understand the DOM as a data structure.
  615. # [08:17] * marcos obviously lost
  616. # [08:18] <sbuluf> mjs, ultimately yes, content inside <i> tags are a datastructure as well, strictly speaking. i only pointed that they are *perceived* as slightly different because of the same reasons people tend to distinguish block and inline levels in HTML
  617. # [08:18] <Zeros> mjs, What about stating that the goal is to not introduce elements whos meaning is tied to a specific UA type and have no abstract meaning that can be mapped to a different context?
  618. # [08:18] <Grauw> a data structure is just a structure of data, of any kind, period
  619. # [08:18] <sbuluf> graw, yes
  620. # [08:18] <Grauw> I've had a course on it at university :)
  621. # [08:18] <Zeros> mjs, <textcolor> is very specific to a type of UA so it'd violate that principal
  622. # [08:18] <MikeSmith> perhaps "logical unit" might be more clear than "data structure"
  623. # [08:18] <marcos> Grauw, got it :)
  624. # [08:19] * Joins: gavin (gavin@74.103.208.221)
  625. # [08:19] <sbuluf> MikeSmith, datastructure itself is just a term. it comes more from the programmer's lexicon, i think
  626. # [08:19] <mjs> Zeros: seems like it would apply to a lot of different types of UAs - desktop, handheld, print, slideshow, various kinds of editors, search engines that want to find attempts to make text invisible...
  627. # [08:19] <MikeSmith> sbuluf - I realize that
  628. # [08:20] <Grauw> e.g. a red-black tree http://en.wikipedia.org/wiki/Red_black_tree is a way to structure data
  629. # [08:22] * Joins: loic (loic@90.29.252.98)
  630. # [08:22] <Zeros> mjs, Okay, I see what you mean. The only thing I can think of is that we shouldn't introduce something better expressed with CSS. Changing stylesheets shouldn't change the meaning of the document, but changing the html should?
  631. # [08:22] <Zeros> this principal does seem hard to define
  632. # [08:23] <Grauw> isn't the term ‘semantic markup’ covering that idea?
  633. # [08:24] <sbuluf> it is, imho. is the reason why <em> was proposed instead of <i>, so you can render content not just to visual UA's, but also to say, a speech sunthesizer
  634. # [08:25] <sbuluf> i.e, you *can* aplly emphasis to voice, but not "italics"
  635. # [08:26] <mjs> I think many people consider <em> a failed experiment
  636. # [08:26] <mjs> that's part of the reason people don't like the term 'semantic markup'
  637. # [08:27] <Grauw> well let them get back to their font tags then, if they want that so badly :)
  638. # [08:27] <Grauw> I mean, if you do not express semantics, then there's no point in having CSS
  639. # [08:27] <Grauw> if you use <i> for italics, there’s no real reason why you should have font-style: italics
  640. # [08:29] <Hixie> <i> doesn't mean "italics" in the whatwg html5 draft :-)
  641. # [08:29] <sbuluf> imho, the point was not some academic, nitpicking, ivory tower capprice. i think, instead, that it provided the above mentioned functionality/coherence. one can not stand in front of an actor and say to him "ok, now please italize this part of the script". but one can say "please emphasize this part".
  642. # [08:29] <Grauw> one who uses <em> on the other hand can on a whim decide to render all emphasis with bold or larger or underline or in a different colour, although that may not exactly match with common typographical convention (bold and underline are used as such though), the advantage is clear
  643. # [08:29] <marcos> I was just going to say, depends on your definition of italics...
  644. # [08:30] <Grauw> styling an <i> italics tag to be bold would be kind of weird :)
  645. # [08:30] <Zeros> Hixie, I think that's a mistake since it takes all the presentational abuses of <i> and makes them into semantic markup
  646. # [08:30] <marcos> Exacly what I was saying before, its all based on usage patterns in the wild.
  647. # [08:30] <Hixie> Zeros: as opposed to the presentational abuses of <blockquote> that we're making into semantic markup?
  648. # [08:30] <sbuluf> if <i> means emphasis, then i think is more coherent to call it <em>
  649. # [08:30] <Hixie> wait, why is making things right a bad thing?
  650. # [08:31] <Hixie> <i> doesn't mean emphasis
  651. # [08:31] <Hixie> <em> is for emphasis
  652. # [08:31] <Zeros> and you're saying with HTML5 they both mean emphasis?
  653. # [08:31] <Grauw> I don't think the new definition of <i> is improving so much
  654. # [08:31] <Hixie> Zeros: no
  655. # [08:31] <Hixie> Zeros: see the spec
  656. # [08:31] <sbuluf> what does <i> mean in html5?
  657. # [08:31] <Hixie> Zeros: http://www.whatwg.org/specs/web-apps/current-work/#the-i
  658. # [08:31] <mjs> <i> is for things that are not emphasis but would normally be rendered in italics in print
  659. # [08:32] <Grauw> there's a lot of overlap, and the definition isn't exactly clear, it could cover a lot
  660. # [08:32] <Grauw> Example from the spec; <p>The <i>block-level elements</i> are defined above.</p> would rather be <dfn></dfn> instead of <i>
  661. # [08:32] <Zeros> mjs, that should probably be handled in the stylesheet though, not the markup
  662. # [08:32] <Zeros> the print conventions may change depending on who is printing
  663. # [08:32] <Zeros> Hixie, it'd honestly make more sense to deprecate it.
  664. # [08:33] <Hixie> Grauw: <dfn> means it's the defining instance, not just a random use of them
  665. # [08:33] <Zeros> We don't have to remove it, but it can be discouraged. Otherwise we might as well add <center> back in for things normally printed in center?
  666. # [08:33] <Hixie> Zeros: i disagree
  667. # [08:33] <marcos> argh... loading the HTML 5 spec makes my machine sooo slow...
  668. # [08:33] <Grauw> I agree, although there is a need for a means to indicate foreign terms
  669. # [08:33] <Hixie> <i> has uses
  670. # [08:33] <Zeros> Hixie, so does <center>
  671. # [08:33] <Grauw> like <i>felis silvestris catus</i> and <i lang="fr">je ne sais quoi</i> in the examples of the spec
  672. # [08:34] <Hixie> Zeros: <center> makes no sense in aural media. <i> does.
  673. # [08:34] <Grauw> and I'd say the dream sequence example needs <q>
  674. # [08:34] <mjs> <i lang="fr">je ne sais quoi</i> makes more sense to me than <span class="foreign-phrase" lang="fr">je ne sais quoi</span>
  675. # [08:34] <Zeros> Hixie, How does giving <i> not break the web? All the abuses of <i> now have special meaning when previously they did not.
  676. # [08:34] <Grauw> (or well, maybe not)
  677. # [08:35] <sbuluf> <mjs> <i> is for things that are not emphasis but would normally be rendered in italics in print <--how does this make sense in aural media?
  678. # [08:35] <Grauw> mjs, how exactly did I say there was *not* a need for an element for foreign phrases, so span with a class would be needed?
  679. # [08:35] <Hixie> Zeros: doesn't really break anything. it changes the meaning of old documents from being meaningless to being confused, but in practice that will have very little effect.
  680. # [08:36] <Hixie> anyway, afk
  681. # [08:36] <Grauw> I was saying the exact opposite, I just think maybe it should not be placed on <i> where it shares semantics with a lot of other things
  682. # [08:36] <mjs> sbuluf: well, how would a reader application render italics in a book? probably by using a distinguished voice
  683. # [08:36] <marcos> I really like the HTML5 def, it captures <i> really nicely: "The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized."
  684. # [08:37] <Grauw> from the description of <i> I think you can divide that up into two categories: different mood, and foreign terms
  685. # [08:37] <Zeros> Making old documents confused hardly seems like no effect.
  686. # [08:37] <mjs> sbuluf: this is what TV Raman, who actually uses a screen reader regularly, recommends as aural presentation for <i>
  687. # [08:37] <Grauw> if you would separate those two out into two elements would be better
  688. # [08:37] <Zeros> We're retroactively redefining what an element that already exists means
  689. # [08:37] <Grauw> and preferably not call them <i> because that would add meaning to existing web sites where none was intended
  690. # [08:37] <Zeros> exactly
  691. # [08:37] <sbuluf> mjs, perhaps he says so because the existence of <i> was there to begin with, and he could not change it?
  692. # [08:37] <Grauw> which is just as bad as inferring sectioning from heading elements :)
  693. # [08:38] <Zeros> Leave them presentational and use something else that has no retroactive effect on existing documents.
  694. # [08:38] <mjs> I think you'll find that definition of <i> captures most actual uses, other ones that should really be <em> but are generated by a WYSIWYG editor that doesn't know any better
  695. # [08:38] <Grauw> example from <b>: <p>The <b>frobonitor</b> and <b>barbinator</b> components are fried.</p>
  696. # [08:39] <Grauw> those are either <dfn> definitions or foreign terms
  697. # [08:39] <mjs> for example none of the italics on this page are emphasis: http://en.wikipedia.org/wiki/HMS_Ark_Royal
  698. # [08:39] <Grauw> so <b> can be used for the same things <i> can be used for?
  699. # [08:39] <sbuluf> mjs, i'm all for wyMiwyg editors, if possible, if that helps. with EM button, instead of I button.
  700. # [08:40] <mjs> sbuluf: then you will get people writing <em>je ne sais quoi</em>
  701. # [08:40] <mjs> which is clearly wrong
  702. # [08:40] <mjs> but people do it because they have been trained that <i> is evil and <em> is good
  703. # [08:40] <sbuluf> mjs, we could create another tag for foreing languages, couldn't we?
  704. # [08:40] <Grauw> not if you add a <foreign-term> element
  705. # [08:41] <Grauw> then people can choose between em and foreign-term, and will choose the one appropriate
  706. # [08:41] <marcos> IMHO, I think the "whose typical typographic presentation is italicized" part is key here.
  707. # [08:41] <mjs> and elements for <ship>, <note>, <species>, etc?
  708. # [08:41] <Grauw> the reason why people overload <em> is because there are cases where <em> is not appropriate
  709. # [08:41] <mjs> with a different button in your editor for each?
  710. # [08:41] <Zeros> I'm going to refrain from getting too heated into this without doing more research into it. :)
  711. # [08:41] <sbuluf> which in turn would normally lead me to an explanation of why i included certain principles in CDL, but unfortunately, that seems to be out of scope here
  712. # [08:42] <Grauw> foreign-term would cover species, I do not claim I made up the best name for such an element in the 10 seconds that it took me to type that phrase :)
  713. # [08:42] <Grauw> as well as ships
  714. # [08:42] <Grauw> maybe just ‘term’ alone would be better
  715. # [08:42] * Grauw nods, yes, a ‘term’ element would be really nice
  716. # [08:43] <sbuluf> mjs, one of the biggest HTML flaws, imho, is that, precisely, it does not allow for inswertion of arbitrary datastructures. just p, ul, ol, table, and a couple more. but why not, instead, an extensibility mechanism, so that we could insert any, at all?
  717. # [08:43] <mjs> a scientific name for a species is not a foreign term
  718. # [08:43] <Grauw> where <dfn> is used for the defining instance of a term
  719. # [08:43] <mjs> it is a scientific term
  720. # [08:43] <mjs> sbuluf: that's called "class"
  721. # [08:43] <Grauw> mjs: as I said, quote "I do not claim I made up the best name for such an element in the 10 seconds that it took me to type that phrase"
  722. # [08:43] <Grauw> quote: "maybe just ‘term’ alone would be better"
  723. # [08:44] <mjs> great, so if you think about what 'term' would apply to, it's pretty much the same set of things as the HTML5 'i'
  724. # [08:44] <Grauw> yes, but
  725. # [08:44] <Grauw> HTML5 <i> also applies to indicate mood
  726. # [08:44] <sbuluf> graw, this might )or might not) interest you: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm (is *very* beta, mind you)
  727. # [08:44] <Grauw> which is a different thing
  728. # [08:44] <mjs> so it makes life easier to call it 'i' and Pave The Cowpaths instead of Reinventing The Wheel
  729. # [08:45] <Grauw> as I wrote above, in my opinion you need to separate those two out, or it would be better to use <span>
  730. # [08:45] <Grauw> well, not need, and maybe span would be worse. But anyway, they should imo be separated out.
  731. # [08:45] <marcos> I guess the choice is yours, grauw.
  732. # [08:46] <mjs> two ways to italicize text is already plenty, I'm not sure three are justified
  733. # [08:46] <sbuluf> mjs, "class" was the closest available thing, yes. if you remember my CDL model, you'll notice that i kept it and mentioned it, for the same reason: a generic extensibility mechanism, for unforeseen uses. BUT, i also used "meaning", "structure", "behaviour", etc, for already known uses.
  734. # [08:46] <Grauw> what, italicise? don't think in terms of that.
  735. # [08:46] <Grauw> marcos, I don’t exactly know what you mean
  736. # [08:46] <mjs> I didn't really read your CDL model, sorry
  737. # [08:46] <sbuluf> mjs, k
  738. # [08:47] <Hixie> fwiw, html5 had a <term> element for a while. we removed it, though i forget why. it's probably in the subversion logs or the mailing list.
  739. # [08:47] <marcos> Grauw, you can use either <i>, <em>, <span>... why add another?
  740. # [08:47] <marcos> oh, and dfn
  741. # [08:48] <Grauw> dfn is the defining instance of a term
  742. # [08:48] <Grauw> what you see is that people want to use (and italicise) terms without defining them
  743. # [08:48] <marcos> yeah, still italics
  744. # [08:48] <Zeros> marcos, you're thinking in terms of presentation not meaning
  745. # [08:48] <Grauw> zeros, indeed
  746. # [08:48] <marcos> No, I'm not. Trust me.
  747. # [08:48] <Zeros> you could use <b> and make it italic if you wanted in the same way you used the span
  748. # [08:49] <Grauw> so <term> would be the ideal accompaniment for <dfn>
  749. # [08:49] <sbuluf> if we include <term>, we might as well include <haiku>, <sonet>, <employee>, <car>, and uncountable datastrucres more as well. this is why i think HTML is flawed, and a good content authoring language should allow for external definition and insertion of arbitrary datastructures.
  750. # [08:49] <Hixie> oh it was called <t>. it was dropped in version 456.
  751. # [08:49] <Grauw> Hixie, why?
  752. # [08:49] <Grauw> btw, <term> seems better, more clear, than <t>
  753. # [08:49] <Hixie> it was dropped same time we added <i> and <b>, presumably for the same reason sbuluf just gave
  754. # [08:50] <Hixie> but if you look in the archives there'll be an e-mail from me explaining the reasoning
  755. # [08:50] <Grauw> I'll never be able to find it, so I won't bother
  756. # [08:51] <Zeros> I don't know if we need term, but we definitely think we need a grouping element for term/definition sets in <dl>
  757. # [08:51] <Hixie> r456 was at 2006-12-22 01:07:05
  758. # [08:51] <sbuluf> hixie, as mere curiosity, and *out* of scope, of this wg, most likely, you might be interested in having a look at this: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm (feel free to disregard if not)
  759. # [08:51] <Zeros> I definitely think*
  760. # [08:51] <Hixie> sbuluf: what is it?
  761. # [08:52] <sbuluf> hixie, a very beta project of mine, a language to replace html, plus a lot of other things
  762. # [08:52] <Hixie> aah
  763. # [08:52] <Hixie> good luck replacing html :-
  764. # [08:52] <Hixie> :-) even
  765. # [08:52] <Zeros> like well, RDF?
  766. # [08:52] <sbuluf> thanks =P
  767. # [08:53] <sbuluf> zeros, rdf, or something similar, would be used to externally define what you see in that page as "meaning" in each <section>
  768. # [08:53] <Hixie> sbuluf: might be useful to have a section explaining the design goals and basic principles behind the spec
  769. # [08:54] <sbuluf> hixie, i have one, but apparently forgot to upload it the last time. thanks, and right
  770. # [08:55] <Zeros> sbuluf, RDF is abstract enough it could describe the entire thing and replace it.
  771. # [08:55] <sbuluf> hixie, mind you, the design goals are almost diametrically opposed to the ones being considered here, though, since the idea is to search for an optimal language, not to keep back compat. i.e, from scratch
  772. # [08:55] <Hixie> hehe
  773. # [08:55] <Grauw> RDF doesn't try to replace HTML
  774. # [08:55] <Hixie> man, designing a new language would be so much more fun than doing html5
  775. # [08:55] <Grauw> if that's what you think then you're missing the point ;p
  776. # [08:56] <sbuluf> zeros, yes, i know, and i do not quite discard it, even, the problem is that some people find it difficult, and that is a big problem wrt the learning curve, and even people's very conceptualization
  777. # [08:56] <sbuluf> hixie...let's do it, even for fun, as hobbie =P
  778. # [08:56] <sbuluf> hixie, i don't envy you having to keep back compat here
  779. # [08:56] <Hixie> hah, my full time job is writing a spec, not gonna make it my hobby too :-P
  780. # [08:57] <sbuluf> hixie =P
  781. # [08:57] <Zeros> Grauw, Not at all. But using RDF and a few extensions like DC and you could get to a point where it could
  782. # [08:57] <mjs> TrainML!
  783. # [08:57] * MikeSmith is looking for the spec he wrote that replaces HTML markup with S-expressions, which is what Web documents should have used from the beginning. Just as we all should be programming in lisp if we really knew what we were doing.
  784. # [08:57] * Joins: cwahlers (Miranda@201.68.59.218)
  785. # [08:57] <MikeSmith> I'll post the URL later
  786. # [08:57] <MikeSmith> remind me if I forget
  787. # [08:57] <sbuluf> MikeSmith, pelase do, i'd like to have a look
  788. # [08:58] <mjs> preferrability of sexps vs sgml-ish syntax depends on density of tags relative to text content
  789. # [08:59] <Grauw> Zeros, I don't think RDF, which is merely a format for data, could replace prose
  790. # [08:59] <Grauw> RDF is nothing else than a database system
  791. # [08:59] * MikeSmith warns that stuff he says is not always to be taken seriously
  792. # [08:59] <Grauw> No different than describing an HTML document in a MySQL relational database and then generate an HTML document from it
  793. # [08:59] <Grauw> which is done on many, many websites of course.
  794. # [08:59] * marcos is shocked by the idea that someone does not like RDF!
  795. # [09:00] <sbuluf> zeros, graw, i tend to see it as graw does. altough i sense what zeros mean. i thinklearning curves are very important, though, and that some html-like language is basically better to write content on cause of that, looks simpler
  796. # [09:01] <Grauw> Youtube is for a large part HTML generated from a database, which is probably some relational thing but could be RDF as well, which would give it a number of benefits
  797. # [09:01] <Zeros> Grauw, reference plain text documents and start defining the relationships and meaning with RDF, or add some extensions as its XML after all and then you've replaced HTML
  798. # [09:01] <sbuluf> MikeSmith, oh i see, i did not know what s-expressions meant. i assume, if joke, that you meant string theory stuff.
  799. # [09:02] <MikeSmith> sbuluf - I have a spec for that too
  800. # [09:02] <Grauw> zeros: as I said, it's not anything new that RDF introduces, it is done on tons of websites using conventional databases already
  801. # [09:02] <MikeSmith> Grand Unification Markup, I call it
  802. # [09:02] <MikeSmith> GUM
  803. # [09:02] <sbuluf> MikeSmith =PP
  804. # [09:02] <Zeros> Grauw, how does that change that it could be used to replace HTML with some abstract extensions?
  805. # [09:03] <sbuluf> zeros, how would you do it? and how would it affect learning curve?
  806. # [09:03] <Grauw> I don't think it can replace entirely... if you look at a database, if there's blurbs of text they're usually contained in a single cell
  807. # [09:03] * MikeSmith is also reminded that he meant to propose we change the list culture to discourage "+1" message and instead encourage people to use "pirate talk" to express agreement
  808. # [09:03] <MikeSmith> as in "Aye, matey"
  809. # [09:03] <Zeros> That's too conventional, you'd just need to break it up more Grauw like in a HTML document
  810. # [09:04] <Zeros> sbuluf, If you replaced HTML with RDF+Stuff you'd end up with a uselessly complex language :)
  811. # [09:05] <Grauw> I'm not saying you couldn't, I mean you can describe HTML pages in XML (another database format, in a sense). RDF is graph-based, so more flexible than XML, and thus it can express the same things.
  812. # [09:05] <Zeros> There is no way RDF can be more flexible than XML since its expressible within XML.
  813. # [09:05] <sbuluf> zeros, so the iudea in that CDL page, in which HTML becomes just <sections>, basically, but each section can externally define structure, presentation, meaning, etc, would be better, simpler?
  814. # [09:06] <Grauw> zeros, XML is in essence a tree-based structure for data, RDF is graph-based
  815. # [09:06] <sbuluf> xml is a tree, while rdf is a graph
  816. # [09:06] <sbuluf> exactly
  817. # [09:06] <Hixie> mjs: i use SVG and XBL1 for my train software (seriously)
  818. # [09:06] <Zeros> If you can express rdf in XML then you can make XML that represents a graph
  819. # [09:06] <Zeros> rdf is not more flexible
  820. # [09:07] <sbuluf> hence, we could represent html in rdf , but we would need to add some ordering information as well...which would turn it into equivalent to a tree
  821. # [09:07] <mjs> Hixie: I think you mentioned that the other day
  822. # [09:07] <mjs> by way of commentary on <use>
  823. # [09:07] <Zeros> Grauw, Anyway, for kicks. What does RDF give me that a conventional SQL database doesn't?
  824. # [09:07] <Grauw> indeed, the ordering is implicit in XML and nonexistant in RDF
  825. # [09:08] <Hixie> mjs: yeah, god, they should drop <use>, seriously
  826. # [09:08] <Grauw> it's a web database format, SQL databases are not
  827. # [09:08] <sbuluf> zeros, you can make automatical mashups. i.e, you can merge graphs with almost no cost, i think
  828. # [09:08] * Hixie wonders what makes something a "web database format" as opposed to some other database format
  829. # [09:08] <Grauw> plus relational databases deal with various graph structures in a very very awkward manner
  830. # [09:08] <sbuluf> to merge xml is not trivial, to make graphs is, afaik
  831. # [09:09] <sbuluf> s/make/merge/
  832. # [09:09] <mjs> Hixie: sadly they have their own compat issues now
  833. # [09:09] <mjs> but <use> is eyebleedingly insane
  834. # [09:09] <Zeros> Grauw, What do you plan to query the RDF database with?
  835. # [09:10] <Grauw> RDF is based on URLs (which can be dereferenced too) so that data can be combined from various sources
  836. # [09:10] <sbuluf> hixie, i think he meant that xml is suitable to send over the wire
  837. # [09:10] <Grauw> *URIs
  838. # [09:10] <Grauw> (which can not always be dereferenced)
  839. # [09:10] <sbuluf> hixie, as a light interchange format
  840. # [09:10] <Hixie> sbuluf: ah
  841. # [09:10] <Grauw> zeros, SPARQL?
  842. # [09:10] <Hixie> sbuluf: well then conventional databases are also "web database formats", they just use CSV as their interchange format
  843. # [09:11] <Grauw> or HTTP REST requests
  844. # [09:11] <sbuluf> hixie, very much, true
  845. # [09:11] <Grauw> Hixie, you can't just merge arbitrary CSV files
  846. # [09:11] <Grauw> and have their primary keys link together
  847. # [09:11] <Hixie> you can't just merge arbitrary rdf graphs either, if they don't have vocabularies in common
  848. # [09:11] <Grauw> in fact, merging would be a very complicated process, due to the table-structures
  849. # [09:12] <sbuluf> graw, neither xml, i think, but yes rdf?
  850. # [09:12] <Grauw> you can, if the URL is the same, even if you don't know the vocabulary, they reference the same thing
  851. # [09:12] <Hixie> talking about "xml" and "rdf" is like talking about "ink-and-paper" and "english"
  852. # [09:12] * Parts: icaaq (icaaaq@85.228.55.162)
  853. # [09:12] <Hixie> they're different classes of things
  854. # [09:12] <Grauw> sbuluf, it would also be difficult for XML, yes
  855. # [09:13] <Grauw> Hixie, no, English would be like ontologies
  856. # [09:13] <Zeros> Grauw, I don't see any advantage in that over a conventional database. I do some nasty performance hits though.
  857. # [09:13] <sbuluf> hixie points to the problem of rdf mappings, which i do think is a problem
  858. # [09:13] <Grauw> RDF is ink-and-paper, RDFS and OWL are English grammar
  859. # [09:13] <sbuluf> (of vocab mappings, perhaps, better)
  860. # [09:13] * Hixie steps out of the conversation since he really doesn't care to talk about RDF right now
  861. # [09:14] * mjs straps on his abstraction space suit
  862. # [09:14] <Grauw> Zeros, then don't use RDF but a conventional database
  863. # [09:16] * MikeSmith wonders how much any of this discussion has actually helped mjs with the problem he was trying to solve
  864. # [09:16] <Grauw> quote "RDFS and OWL are English grammar" - sorry, I meant to say RDFS and OWL are a grammar to describe language structures (they could contain a description of English grammar)
  865. # [09:17] <mjs> MikeSmith: it made me feel satisfied with Media Independence and Separation Of Concerns as expressing the important points that aren't too abstract to be useful
  866. # [09:18] <sbuluf> the <i> discussion will go on
  867. # [09:19] * Joins: edas (edaspet@88.191.34.123)
  868. # [09:20] <sbuluf> graw, for curiosity..did you see that url of mine?
  869. # [09:21] <Grauw> I briefly looked over it
  870. # [09:22] <sbuluf> i see, thanks.
  871. # [09:24] <Grauw> I don't really see the benefit, I think HTML does the job pretty well, although it misses markup for certain things that are fairly common in documents.
  872. # [09:25] <Grauw> turning everything into attributes instead of elements (basically what I see is span and div with a class attribute on it with certain predefined meanings) isn't really the answe
  873. # [09:25] <Grauw> r
  874. # [09:26] <Grauw> I mean, you have block or inline as top level elements (section and in elements), but you could just as well put those in a class element as well, I do not see why they are so special that they're first-class citizens
  875. # [09:27] * Quits: Lachy (chatzilla@220.245.91.147) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
  876. # [09:27] <sbuluf> html does not allow for extarnal definition plus insertion of arbitrary datastructures. also, this separates not just content from presentation, but also from structure, meaning and behaviour, which i think is a very simple idea to grasp, and hence reduces learning curves for newbies.
  877. # [09:27] <Grauw> in the end however <e c="in e l"> to say ‘this is an inline element that's emphasised and a link’ isn't really author-friendly. Plus it'll be hell to define a schema for it.
  878. # [09:27] <sbuluf> (the rest of the ideas being mostly secondary)
  879. # [09:28] <sbuluf> this also mighe facilitate wymiwyg editing
  880. # [09:28] <Grauw> sbuluf: I don't see the problem in HTML that it solves, and because it's entirely new there's no familiarity with the format, no implementations, etc
  881. # [09:29] <Grauw> and, how is it different from XML?
  882. # [09:29] <Zeros> sbuluf, the XML serialization of HTML allows arbitrary data structures.
  883. # [09:30] <sbuluf> xml is bigger, this is more restricted. same reason why xhtml exist, as opposed to full xml
  884. # [09:30] <sbuluf> zeros, it does?
  885. # [09:30] <Grauw> restricted how?
  886. # [09:30] <sbuluf> restricted to just a few possible elements, mostly sections, as pure containers
  887. # [09:30] <Zeros> sbuluf, Certainly. You can mix namespaces in your XHTML document to add arbitrary data like DC or RSS inline
  888. # [09:31] <sbuluf> zeros, you mean in html5? of in the former xhtml?
  889. # [09:32] <Zeros> You'd just need to style it with CSS, and hope the UA implemented proper styling of arbitrary XML
  890. # [09:32] <Zeros> sbuluf, HTML5 is not XML, though they want to provide an XML reformulation of it.
  891. # [09:33] <sbuluf> zeros, so you meant xhtml5, not the former xhtml, right?
  892. # [09:33] <Zeros> both
  893. # [09:33] <sbuluf> thanks
  894. # [09:33] <Zeros> XML by definition lets you mix namespaces to combine data types.
  895. # [09:33] <sbuluf> right, but no so former html
  896. # [09:33] <Zeros> right
  897. # [09:34] <Zeros> Whether its a good idea to allow that kind of mixing is a matter of heated debate. Do we really need random data snippets mixed with HTML?
  898. # [09:34] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
  899. # [09:35] <Grauw> So this allows you to define block and inline content: HTML does the same. This allows you to add arbitrary meaning: class does the same, and RDFa with an ontology does it more formally. This allows you to mix data with content: XHTML is an XML language and thus you get the benefit of namespaces
  900. # [09:35] <Grauw> zeros: I think not :)
  901. # [09:35] <sbuluf> re styling of arbitrary xml...well, a default possibility is that xml is ultimately always just a bunch of [ordered] label/values pairs, hence, it can always be default-styled as just that, unless the author can specify a custom style for that datastructure
  902. # [09:36] <sbuluf> random data snippets?
  903. # [09:37] <sbuluf> graw, you mean you do not see differences with what is currently being done here?
  904. # [09:38] <Grauw> not just here
  905. # [09:38] <Zeros> Grauw, I see a real advantage to MathML or SVG embedding, the problem is that XML doesn't limit you to /just/ those formats. So people can make up random stuff too.
  906. # [09:38] <Grauw> but yeah
  907. # [09:38] <Grauw> zeros: I agree
  908. # [09:38] <sbuluf> zeros, why would that be a problem, though?
  909. # [09:39] <Grauw> then again, random stuff isn't any less suited to be inserted in XHTML than MathML or SVG really... the definitions of the meaning of the tags are just less public.
  910. # [09:39] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  911. # [09:40] * Joins: anne (annevk@81.68.67.12)
  912. # [09:41] * Joins: icaaq (icaaaq@85.228.55.162)
  913. # [09:41] <Grauw> anne, you'll love this: http://leobard.twoday.net/stories/3520709/
  914. # [09:41] <Grauw> and I'm referring to the markup
  915. # [09:41] <Grauw> of that link
  916. # [09:42] <sbuluf> graw, did you think css, and the separation of content from presentation, plus to have a way to externally deal with presentation, was a good idea? if so doens't this, which extends the same principle to structures, etc, looks better in a similar way?
  917. # [09:43] <Grauw> yes, that's what XML or RDF is for...
  918. # [09:43] <Grauw> you can serialise them to HTML, or in case of XML, style it
  919. # [09:44] <Grauw> s/serialise/transform
  920. # [09:44] <Grauw> XML has better tools support for both (XSLT for transforming and CSS for styling)
  921. # [09:44] <sbuluf> right, and this is not too far from full xml, only more restricted to the needed elements (mostly <section>, as pure nestable containers)
  922. # [09:44] <Grauw> (I wish there was an XSLT for RDF... XUL has some, but it's not ideal)
  923. # [09:45] <Grauw> I don't understand why you would need some kind of section or inline containers?
  924. # [09:47] <sbuluf> graw, you reckon full xml would be better, directly, as a general content authoring language?
  925. # [09:47] <Grauw> For prose documents, XHTML is better. For data, XML is better.
  926. # [09:47] <Grauw> (or RDF)
  927. # [09:49] <sbuluf> graw, why did you mention xhtml, instead of full direct xml? and does that same thing explain why i'd rather use cdl instead of full xml?
  928. # [09:50] <sbuluf> if, so, how would you describe that reason?
  929. # [09:50] <Grauw> Because XML does not have any semantics attached to it. XHTML does.
  930. # [09:51] <Grauw> and I don't understand the other question :)
  931. # [09:51] <sbuluf> lemme think a bit =P
  932. # [09:52] <Grauw> When I say for data, RDF or XML is better, I mean to say of course preferrably one which has a specification or ontology which makes it meaningful, as opposed to your own madde-up format.
  933. # [09:53] <sbuluf> i think first and foremost, you mean for authoring structured content. am i right?
  934. # [09:53] <Grauw> e.g. iCal for calendar data (exists in both RDF and XML), SVG (XML) for graphics, MathML (XML) for formulae, FOAF (RDF) for person information, etcetera.
  935. # [09:54] <Grauw> Along these lines, for prose XHTML is the XML format of choice.
  936. # [09:55] <sbuluf> and does this very same reason for picking xhtml, and not full xml, answer you former question about why cdl, instead of full xml?
  937. # [09:55] <Grauw> and XHTML can also be used as a final-form output medium for various human-oriented serialisations of these data formats.
  938. # [09:55] <Grauw> sbuluf: except it seems to me that you are creating something new with no obvious benefits over existing technologies...
  939. # [09:56] <sbuluf> graw, i see, let me see if i can explain my perceived advantages
  940. # [09:56] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  941. # [09:56] <Grauw> (it's ‘grauw’, btw, with a u in it :))
  942. # [09:56] <Zeros> There's an XML parsing library for just about every language
  943. # [09:57] <sbuluf> oops, sorry!
  944. # [09:57] <Zeros> I think that's a huge advantage over making up you own format for the data
  945. # [09:58] <Zeros> which of course could be XML itself and then why not use XHTML since it already has some support?
  946. # [09:58] <sbuluf> cdl would be xml itself, just a small subset, mostly just <section>. very much like if you coded webpages today just using <div> and <span>
  947. # [09:59] <sbuluf> imho, the problem with xhtml, is that it hardwires some datastructures into the language
  948. # [09:59] <Zeros> Wouldn't that be hugely bloated since you'd have to define the meaning of everything?
  949. # [09:59] * anne isn't sure what there's to like about that page
  950. # [09:59] <sbuluf> examples of datastructures: ol, ul, table, p
  951. # [10:00] <Zeros> 61 errors, xml prolog, xhtml transitional
  952. # [10:00] <sbuluf> but not, for example, employee, car, haiku, and infinite more possibilities
  953. # [10:00] <Zeros> its the poster child for XHTML usage
  954. # [10:00] <Zeros> kind of sad
  955. # [10:01] <sbuluf> what i propose is exqctly the opposite: nothing (no datastructure) predefined. instead, just a mechanism to define any arbitrary datastructure externally, in some schema language
  956. # [10:02] <Zeros> sbuluf, that'd render screen readers and semantic data extractors (ex. search engines) useless
  957. # [10:02] <sbuluf> izeros, why so?
  958. # [10:02] <Zeros> The data on every site could be in a radically different structure because everyone can use their own description of what it's supposed to mean
  959. # [10:03] <sbuluf> is that different than creating some datastructure today in xml or rdf?
  960. # [10:04] <Zeros> No, but its very different than using XHTML which has defined meaning attached already.
  961. # [10:04] <sbuluf> and are those "meanings useful? and in fact, are they really "meanings"? or are *datastructures, instead?
  962. # [10:05] <sbuluf> for example, do you any time ask google to list all paragraphs in the net?
  963. # [10:05] <sbuluf> or all tables?
  964. # [10:05] <sbuluf> do you use those structures for searching, at all?
  965. # [10:05] <Zeros> Of course they're useful
  966. # [10:05] <Grauw> anne, in the context of your thought that xml-well-formedness checking is fairly worthless
  967. # [10:05] <Grauw> this is a nice example of where it indeed is quite worthless
  968. # [10:06] <Zeros> how else do you think google figures out what's a heading and what's a paragraph and what is relevant sbuluf? How do you think a screen reader knows how to read a documenet?
  969. # [10:06] <Zeros> document
  970. # [10:07] <Zeros> Grauw, Its not worthless, that document isn't being sent as xml at all. Its malformed HTML.
  971. # [10:07] <Grauw> well-formed, in case of HTML5
  972. # [10:07] <Zeros> That document is well formed HTML5?
  973. # [10:07] <sbuluf> zeros does google really figures what is a heading, and what is a paragraph? what would google do with that? is it of any use, search-wise?
  974. # [10:08] <Grauw> from what I gather, XHTML appendix C constructs are now conformant according to HTML5
  975. # [10:08] <Grauw> but anyway, the point is, had it been sent as XML, it would not have helped the broken markup
  976. # [10:08] <anne> almost all XHTML documents served as text/html are like that, btw
  977. # [10:09] <sbuluf> zeros, do we agree, first, that things like ol, ul, etc, are structures, more than meanings?
  978. # [10:09] <Grauw> although this does seem like a case where some mechanism has tried to automatically fix up errors in non-well-formed XML
  979. # [10:10] <Zeros> Grauw, It would have helped because the markup would have bombed entirely as its invalid, in which case the author would be compelled to fix it.
  980. # [10:10] <Grauw> Zeros, for the record I agree completely with you :)
  981. # [10:10] <Zeros> And can we even allow Appendix C constructs and still be valid SGML?
  982. # [10:11] <Grauw> Zeros: never mention SGML again in relation to HTML :)
  983. # [10:11] <Zeros> /> is a NET feature which means something else entirely
  984. # [10:12] <Grauw> HTML is not an SGML language
  985. # [10:12] <Zeros> um, sure it is.
  986. # [10:13] <Zeros> XML is a SGML subset too
  987. # [10:13] <hsivonen> Zeros: as of HTML5, HTML is officially not an SGML language
  988. # [10:13] <Zeros> hsivonen, HTML5 is not a standard, its an adhoc spec that some people put together.
  989. # [10:13] <hsivonen> Zeros: as far as browser implementations go, it has never been
  990. # [10:13] <anne> much like HTML1
  991. # [10:14] <anne> Zeros, HTML5 reflects the web, not some pipedream the HTML2 guys had
  992. # [10:14] <Grauw> Zeros, the W3C HTML WG operates on the same premises, quote from the charter "the Group will not assume that an SGML parser is used for 'classic HTML'"
  993. # [10:14] <Zeros> Citing HTML5 as being the definition of HTML is not correct
  994. # [10:14] <anne> whatever suits you
  995. # [10:14] <Zeros> heh
  996. # [10:14] <Zeros> Well if we take HTML5 as the gospel why have this WG at all?
  997. # [10:14] <anne> patent stuff
  998. # [10:14] <hsivonen> Zeros: some people say it is inappropriate to cite CSS 2.1 as the definition of CSS
  999. # [10:14] <Zeros> Lets just let the WHATWG do it for us
  1000. # [10:14] <Zeros> since we have no authority
  1001. # [10:15] <anne> we certainly don't have the authority to keep it SGML based
  1002. # [10:16] <anne> you can read that in the charter
  1003. # [10:16] <Grauw> exactly. it's part of the charter.
  1004. # [10:16] <Zeros> the charter mentions classic HTML
  1005. # [10:16] <Zeros> it makes no mention that HTML5 is not SGML
  1006. # [10:16] <anne> you should read better
  1007. # [10:17] <anne> any, this discussion is pretty pointless
  1008. # [10:17] <hsivonen> Zeros: that's charterese for "neither SGML nor XML"
  1009. # [10:17] <anne> s/any,/anyway,/
  1010. # [10:17] <Zeros> You're right it is
  1011. # [10:18] * Joins: tylerr (tylerr@24.16.148.66)
  1012. # [10:18] <Zeros> And okay, if you define not assuming as not being
  1013. # [10:19] <tylerr> Hey folks.
  1014. # [10:19] <anne> morning
  1015. # [10:19] <sbuluf> hi
  1016. # [10:19] <Zeros> hsivonen, abomination?
  1017. # [10:19] <anne> Zeros, but you want it to be SGML based?
  1018. # [10:19] <tylerr> What do you all think of the <term> element proposal?
  1019. # [10:20] <anne> I think <term> should be <i xref>
  1020. # [10:20] <Zeros> anne, not particularly
  1021. # [10:20] <anne> and <code xref> etc.
  1022. # [10:20] * Parts: icaaq (icaaaq@85.228.55.162)
  1023. # [10:20] * Joins: icaaq (icaaaq@85.228.55.162)
  1024. # [10:20] <tylerr> Where you define the meaning behind the formatting as an attribute eh?
  1025. # [10:20] <anne> (not making xref global though, just let it apply to all current elements partaking in the definition/term stuff)
  1026. # [10:20] <tylerr> Interesting way of looking at it.
  1027. # [10:21] <Zeros> Should probably add a for attribute for referencing a local definition too
  1028. # [10:22] <anne> that can happen automatically by the UA
  1029. # [10:22] <tylerr> @longdesc ;-)
  1030. # [10:22] <Zeros> anne, how so?
  1031. # [10:22] * anne tries to find a pointer
  1032. # [10:23] <anne> http://www.whatwg.org/specs/web-apps/current-work/#dfn
  1033. # [10:23] <Grauw> anne, my problem with <i> is that it also indicates ‘mood’, and not just terms. xref is nice, although there shouldn't necessarily be a need to cross-reference.
  1034. # [10:23] <anne> just marking up a term for the sake of it doesn't have much value imo
  1035. # [10:23] <tylerr> Ah hello Grauw. Now you've gone and made me start thinking before bed time! ;-)
  1036. # [10:24] <Grauw> tylerr, did I :)
  1037. # [10:24] <Grauw> I think <term> is common enough to be justified its own element
  1038. # [10:25] <tylerr> 01:25 here and you've got me thinking about the meaning behind something being italic, my brain doesn't normally do that at this hour :-D
  1039. # [10:25] <Grauw> plus, in combination with <dfn> it could actually be useful in referencing back to the definition (or a definition list somewhere)
  1040. # [10:25] <Zeros> anne, hmm. Okay.
  1041. # [10:26] <Zeros> Odd that the <dl> example shows both <dfn> nested in the <dt>, isn't that redundant since both mark it as the definition of the term?
  1042. # [10:26] <anne> introducing a new element is way more typing than the current mechanism for doing cross references
  1043. # [10:26] <Grauw> Zeros, I think that would be so, yes
  1044. # [10:27] <Grauw> except that maybe HTML5 redefines dl to be also appliccable to conversations etc
  1045. # [10:27] <anne> i think an attribute that applies to some elements you would typically use to mark up a term is more useful
  1046. # [10:27] <anne> Zeros, <dl> is defined to be a data structure
  1047. # [10:27] <Grauw> I always find the ‘length’ argument and ‘amount of typing’ not very convincing :)
  1048. # [10:27] <anne> Zeros, not just pairs of terms and their definitions
  1049. # [10:28] <anne> Grauw, and that for someone who advocates href=
  1050. # [10:28] <tylerr> I've always read <dl> as "data list".
  1051. # [10:28] <Grauw> anne, I advocate href=? :)
  1052. # [10:28] * anne got things mixed up maybe
  1053. # [10:28] <anne> HTML5 calls it description list
  1054. # [10:29] <hsivonen> Zeros: do you mean that SGML is an abomination? do you mean that HTML5 syntax is a abomination?
  1055. # [10:29] <Grauw> I probably just said that it was a nice idea, but I would not argue for it based on length alone
  1056. # [10:29] <anne> Grauw, conversations are done with <dialog>
  1057. # [10:29] <Grauw> aha
  1058. # [10:29] <tylerr> hsivonen: He's saying we should all go back to using Word to design our web pages. ;-)
  1059. # [10:29] <Grauw> http://www.w3.org/TR/html4/struct/lists.html#h-10.3
  1060. # [10:29] <anne> which does indeed use <dt> and <dd> inside for speaker and what they say...
  1061. # [10:29] <Grauw> HTML4 says ‘Definition list’
  1062. # [10:30] <anne> yeah, it was changed to match reality
  1063. # [10:30] <Grauw> I don’t know why HTML5 is changing that.
  1064. # [10:30] <Zeros> hsivonen, I meant what's evolved from HTML and XHTML is an abomination. Its half XML, half SGML, mostly wrong everywhere. Entities <,>,& aren't encoded in most places, /> in HTML docs that shouldn't be there if it was SGML, that kind of thing
  1065. # [10:30] <Grauw> might as well redefine <span> to mean ‘a heading’
  1066. # [10:30] <tylerr> It's used in a larger scope than definitions.
  1067. # [10:30] <anne> people use <dl> for all kind of stuff
  1068. # [10:30] <Grauw> if you’re trying to match reality
  1069. # [10:30] <anne> mostly for grouping name/value stuff
  1070. # [10:31] <sbuluf> <term>, <dialog>, <haiku>, <car>, <employee>...endless series. and all hardwired, instead of externally definable via some schema language
  1071. # [10:31] <Zeros> tylerr, ...
  1072. # [10:31] <tylerr> I used a <dl> to express a transcript I was posting to a webpage a few days ago, that's a good example.
  1073. # [10:31] <hsivonen> Zeros: well, we have to deal with the real Web--warts and all
  1074. # [10:31] <tylerr> Zeros: :-)
  1075. # [10:31] <Zeros> hsivonen, of course
  1076. # [10:31] <Grauw> I think I’d prefer to keep it to the original specification, but I haven’t really thought about that :)
  1077. # [10:31] <anne> Grauw, UAs could certainly consider <span> with a certain font-size to be a heading... Opera does that iirc
  1078. # [10:31] <tylerr> Zeros: It's late and I'm ornery, haha.
  1079. # [10:31] <Zeros> :)
  1080. # [10:32] <Zeros> sbuluf, <car> isn't a document construct though :p
  1081. # [10:32] <Grauw> there will always be incorrect usages, the specification should not try to cover them all, otherwise you might as well say that every element is as generic as a span
  1082. # [10:32] <anne> the specification should try to cover as much as reasonably possible
  1083. # [10:32] <sbuluf> zeros, right, neither <employee>, but they all are dastastructures, though
  1084. # [10:33] <tylerr> <noun>, <verb>, etc.
  1085. # [10:33] <anne> which is pretty vague, but I think so far it goes quite well :)
  1086. # [10:33] <Zeros> sbuluf, So transform them into HTML with XSLT
  1087. # [10:33] <anne> or invent a microformat
  1088. # [10:33] <Zeros> tylerr, sure, if we wanted to get that specific
  1089. # [10:33] <anne> so you don't need XML
  1090. # [10:33] <anne> or XSLT
  1091. # [10:33] * Lachy_ is now known as Lachy
  1092. # [10:34] <tylerr> Hey there Lachy.
  1093. # [10:34] <Grauw> The WHATWG specification isn’t redefining <em> to be equivalent to <i>...
  1094. # [10:34] <Grauw> So why should it redefine <dl>.
  1095. # [10:34] <Grauw> Surely both have equal amounts of incorrect usage.
  1096. # [10:34] <Lachy> Hey tylerr
  1097. # [10:34] <sbuluf> zeros, thats kind of what i had in mind, precisely. each <section> says whare to insert, and structure, meaning, behaviour, etc, can be externally defined
  1098. # [10:34] <anne> prolly because the spec itself abuses <dl> too
  1099. # [10:34] <anne> "abuses"
  1100. # [10:35] <hsivonen> Grauw: I think it should redefine <em> and <i> to have the same semantics and default presentation
  1101. # [10:35] <Grauw> it’s funny when a spec uses things it itself describes :)
  1102. # [10:35] <anne> and maybe <em> will be redefined in due course...
  1103. # [10:35] <Grauw> Well, I don’t think that’s a good idea.
  1104. # [10:35] <anne> Grauw, the spec also uses the cross references stuff
  1105. # [10:35] <anne> (as do several other specs, such as XMLHttpRequest)
  1106. # [10:36] <anne> (with a generator that outputs <a> around them though)
  1107. # [10:36] <Grauw> I can't find that xref attribute you mentioned or any mention of ‘cross reference’ in the spec...
  1108. # [10:36] <anne> Grauw, the idea was to introduce that to make the mechanism opt-in instead of opt-out
  1109. # [10:36] <anne> Grauw, it would also help with performance in browsers for dynamic updates
  1110. # [10:37] <Zeros> Grauw, docbook has one
  1111. # [10:37] <sbuluf> what is that xref thingie? first time i see
  1112. # [10:37] <tylerr> I'm wondering anne how much emphasis we'll be placing on "emotional" elements like <em> and <strong>? Are we leaving them alone for the most part?
  1113. # [10:37] <Grauw> I'm missing what it does exactly :)
  1114. # [10:37] <anne> Grauw, <dfn>test</dfn> <i>test</i> currently gives you a pointer from <i> to <dfn>
  1115. # [10:38] <anne> Grauw, the proposal is: <dfn>test</dfn> <i>test</i> <i xref>test</i>
  1116. # [10:38] <Grauw> I see
  1117. # [10:38] <anne> only the second <i> will give you a pointer
  1118. # [10:38] <Grauw> I’d say might as well use <term> then
  1119. # [10:38] <Grauw> :)
  1120. # [10:38] <Grauw> and automatically add xrefs
  1121. # [10:38] <anne> <dfn title="test test">test</dfn> <i xref="test test">blah</i> would be another sample
  1122. # [10:39] <Zeros> sbuluf, moving all the abstractions out like you want to doesn't solve anything. You're just making XML in itself
  1123. # [10:39] <anne> and xref= would apply to <i>, <code>, <samp>, <span>, <abbr>, <var>
  1124. # [10:39] <anne> or something
  1125. # [10:39] <Grauw> do you not think it would actually be better to just use href?
  1126. # [10:39] <Grauw> it does not necessarily have to exist in the same document...
  1127. # [10:40] <anne> using this mechanism myself, it would be very inconvenient i think...
  1128. # [10:40] <Grauw> it starts to sound awfully much like XHTML2 :)
  1129. # [10:40] <anne> what you're suggesting does, yes
  1130. # [10:40] <Grauw> why, just use IDs
  1131. # [10:40] <Grauw> it's the same thing
  1132. # [10:40] <anne> it's way more typing
  1133. # [10:40] <Grauw> <dfn id="test">test</dfn> <term href="#test">test</term>
  1134. # [10:41] <Grauw> no it's not, only add a #
  1135. # [10:41] <anne> you'd use <a> I hope
  1136. # [10:41] <Zeros> it'd make more sense to use id since title doesn't usually imply uniqueness.
  1137. # [10:41] <Grauw> and you can make the id as cryptic and short as you want :)
  1138. # [10:41] * Parts: htmlr_ (htmlr@203.206.237.84)
  1139. # [10:41] <Grauw> anne, or an <a> element
  1140. # [10:41] <hsivonen> anne: does the CSS WG generator have a real parser or is it a regexp hack?
  1141. # [10:41] <Grauw> was just making the XHTML2 reference complete ;p
  1142. # [10:41] <anne> hsivonen, real parser iirc
  1143. # [10:41] <sbuluf> zeros, quite close to full xml, just a restricted subset, very much like xhtml. however, the clear separation of content, structure, meaning, etc, is, on one hand, very clear mentally, easy to grasp, learning curve shortener. on the other...did you ever consider the problem of doing wymiwys editors? would cdl be way easier than the current specs, with everincreasing complexity?
  1144. # [10:41] <Zeros> If <dfn title="foo">bar</dfn> is the only dfn allowed with that title then why not use id?
  1145. # [10:41] <Grauw> given that you want to put the xref attribute directly on the elements as well
  1146. # [10:41] <Zeros> The behavior of being unique already exists
  1147. # [10:42] <anne> Zeros, because yo uwant the term defined to be accessible?
  1148. # [10:42] <Grauw> also, I think it’s actually very good if every term had an ID
  1149. # [10:42] <Grauw> it makes it lots easier to reference it
  1150. # [10:43] <Zeros> anne, Provide the title too. I'm saying that making the title attribute the link specifier doesn't make sense since you can't get to it with a simple dom call in legacy browsers (getElementById however does work)
  1151. # [10:43] <anne> yet more typing
  1152. # [10:43] <Grauw> (not that I’m saying the id attribute should be required)
  1153. # [10:43] <Zeros> If typing is all this is about we should not use <video> and instead use <v>
  1154. # [10:43] * anne agrees that having ID on <dfn> would be nice
  1155. # [10:44] <sbuluf> zeros, more particularly? why are we forcing end-users all over the plante to have to learn html, at all? shouldn't they be able to write content without *ever* having to see code? and could we do that with the corrent very complex specs? how?
  1156. # [10:44] <anne> Zeros, <video> is not something you'd use as often as terms
  1157. # [10:44] <Grauw> because <dfn> is a separate element, you could just auto-generate an ID, wouldn’t be a need to type
  1158. # [10:44] * anne isn't sure terms are needed though
  1159. # [10:44] <anne> the only real use case is technical documents
  1160. # [10:44] * Joins: Shunsuke (kuruma@219.110.80.235)
  1161. # [10:44] <Grauw> anne, which there are a *lot* of on the internet
  1162. # [10:44] <Zeros> anne, I don't think the amount of typing should change what we use for attributes and element names.
  1163. # [10:44] <Grauw> plus ‘je ne sais qois’
  1164. # [10:44] <anne> Zeros, well, then we disagree
  1165. # [10:45] <Grauw> that’s hardly limited to technical documents
  1166. # [10:45] <Grauw> that example
  1167. # [10:45] <anne> that's not a term
  1168. # [10:45] <tylerr> sbuluf: It's a big issue we're facing at work right now. We're helping a client develop an internal publishing tool that blends content editing/publish with page development. We're talking WYSIWYG on steroids and it's a VERY complex and mind-boggling task.
  1169. # [10:45] <Zeros> anne, why are they adding the <header> element and not <h>?
  1170. # [10:45] <Grauw> it is, a foreign term
  1171. # [10:45] <Grauw> that’s why it’s italicised
  1172. # [10:45] <anne> that's just a foreign language phrase
  1173. # [10:45] <sbuluf> <Zeros> If typing is all this is about we should not use <video> and instead use <v> <--if we had wymiwys editors, then we would never worry about how much to type, since we would never ever need to see the code
  1174. # [10:45] <anne> Zeros, same reason, you don't use it so often
  1175. # [10:46] <Zeros> I don't see dfn used very often on most sites
  1176. # [10:46] <sbuluf> tylerr, is it even possible at all, with today's specs being so complex?
  1177. # [10:47] <anne> Zeros, I already mentioned I'm not completely convinced this is needed, although it can be useful for technical documents
  1178. # [10:47] <tylerr> Also I think code should be readable enough to where I can sim through the source and see the <article><section><para><etc>, it helps developers locate blocks of data much quicker than seeing smaller <a><s><p> tags.
  1179. # [10:47] * anne uses <dfn> a lot in specs
  1180. # [10:47] <Grauw> me too
  1181. # [10:47] <Grauw> in my definition, foreign words would be included in <term>
  1182. # [10:47] <Grauw> after all, you can use <dfn> on them too
  1183. # [10:47] <tylerr> sbuluf: Nope! That's why I'm here and looking to influence the development of this publishing platform to go along with what this WG comes out with.
  1184. # [10:47] <Grauw> the basic function of them is the same
  1185. # [10:48] <anne> tylerr, yeah, indeed, code should be readable
  1186. # [10:48] <sbuluf> tylerr, if we ever need to see the soruce, at all, then to expand <v> to <video>, should be trivial
  1187. # [10:48] <tylerr> s/sim/skim
  1188. # [10:48] <anne> sbuluf, that is not a common authoring practice
  1189. # [10:48] <Grauw> do consider that whatever names you give them, to a chinese person it’s still gibberish ;p
  1190. # [10:48] <anne> sbuluf, please take into account the real world here...
  1191. # [10:48] <Grauw> but anyway, I also agree there’s benefit in having short, but not too short names
  1192. # [10:49] <tylerr> <?> for a copyright element would go over well then ;-)
  1193. # [10:49] <sbuluf> anne, true. which is why i can not quite contribute to this group, other than just marginally.
  1194. # [10:50] <Grauw> You mean <©>? Awesome :).
  1195. # [10:50] <anne> sbuluf, you don't live in the real world? :)
  1196. # [10:50] <Zeros> tylerr, we should add that make every XML parser choke on it.
  1197. # [10:50] <tylerr> I'm of the camp that code should be beautiful and functional at the same time. I enjoy skimming code that envokes a sense of aesthetics.
  1198. # [10:50] * tylerr chuckles
  1199. # [10:51] <sbuluf> anne, i do. and i know about installed bases, and chaos theory, and error perpetuation. hence, i think we need another language to replace html from scratch, before we are all doomed by ever increasing legacy
  1200. # [10:51] <sbuluf> anne, hence, i'm just marginal here =P
  1201. # [10:51] * anne thinks it's better to try to understand the legacy first
  1202. # [10:51] <Grauw> sbuluf, I ask you, do you think than that this group is the right place for you to be, or that you’re wasting our time?
  1203. # [10:51] <tylerr> I prefer <xlink> over <a>, and <section> over <s>. I love reading code like a novella.
  1204. # [10:51] <Zeros> sbuluf, that was XHTML2, which no one adopted...
  1205. # [10:51] <anne> replacing it will be hard otherwise
  1206. # [10:52] <anne> XHTML2 is not what sbuluf is talking about I think
  1207. # [10:52] <anne> at least, I hope not
  1208. # [10:52] <Grauw> it’s not.
  1209. # [10:52] <tylerr> Sure anne. We need to have a clear understanding of the semantics behind the current elements, then take it from there.
  1210. # [10:52] <Zeros> anne, I meant in the sense they tried to fix everything and ignored what they might break. They wanted a new language
  1211. # [10:52] <tylerr> Sort of an Oxford English version of HTML4.01
  1212. # [10:52] <Zeros> anne, which is what sbuluf is suggesting
  1213. # [10:53] <sbuluf> grauw, i just had a interest in clear definition of scope, myself. i will not continue after that. i mentioned other stuff just cause i was here and some could be of use. it was friendly, though, not my intention to stop this, since is impossible.
  1214. # [10:53] <Grauw> I'm not trying to be not-nice, but just asking an honest question :)
  1215. # [10:53] <sbuluf> zeros, anne, xhtml2, however, has some flaws already. i think it could be done better. so i have to cook my own, can't even join that, they would not listen.
  1216. # [10:53] <anne> But XHTML2 is actually just a minor update to HTML, it's not really revolutionary... It won't be adopted because of that I think.
  1217. # [10:54] <sbuluf> grauw, nono, i understood it that way, and your question was logical
  1218. # [10:54] <anne> (Mostly because it's a minor update, not well defined and not backwards compatible.)
  1219. # [10:54] <tylerr> Anything we do here cannot break today's pages.
  1220. # [10:54] <Zeros> anne, What you suggest is impossible. You can't fix all the problems with HTML4 and make it backwards compatible at the same time.
  1221. # [10:54] <tylerr> There shouldn't be a "join us or die" mentality.
  1222. # [10:54] <tylerr> :-)
  1223. # [10:55] <anne> Zeros, HTML5 is doing that...
  1224. # [10:55] <sbuluf> tylerr, right, hence my questions here yesterday. my interest was delimitation of scope
  1225. # [10:55] <tylerr> Ah interesting sbuluf I was out all day with the g/f so I missed that.
  1226. # [10:55] <anne> Zeros, for my definition of "problems with HTML4" anyway
  1227. # [10:56] <Zeros> anne, For you, likely not for the XHTML2 group.
  1228. # [10:56] <anne> XHTML2 didn't fix any of the problems
  1229. # [10:56] <Hixie> i'd recommend avoiding the term "backwards compatible" in this discussion, as it is somewhat ambiguous. better to use the terms mjs defined in the principles.
  1230. # [10:56] <Grauw> i agree :).
  1231. # [10:57] <Grauw> (with Hixie)
  1232. # [10:57] * anne waits for someone to say +1
  1233. # [10:57] <Zeros> anne, sure they did. <img> was given alt text in the body which was definitely needed. They removed all the presentational attributes and elements once and for all.
  1234. # [10:57] <Zeros> Added <h> and <section>
  1235. # [10:58] <anne> Zeros, "definitely needed"? People hardly ever use alt="" and when they do a string of characters is mostly enough.
  1236. # [10:58] <sbuluf> zedros, compared with the xhtml2 group, i'm the che guevara in terms of revolutionarity =P
  1237. # [10:58] <Zeros> anne, A string of characters is all that is allowed
  1238. # [10:58] <tylerr> Would it be at all crazy to suggest some persona work so that everyone has a more clear understanding of whom this spec is written for?
  1239. # [10:58] <anne> Zeros, some accessibility indoctrinated people might complain about it daily, but it's not too bad
  1240. # [10:59] <Zeros> anne, If <audio> and <video> warrant alternate content in the body then it should be provided for img as well
  1241. # [10:59] <anne> Zeros, HTML5 also removed all presentational stuff
  1242. # [10:59] <Grauw> there’s always <object>. And <img> can get alt text in the body once XHTML really starts to be adopted in all browsers
  1243. # [10:59] <tylerr> We could say "people", but there are various groups of people that would be utilizing this. We're talking designers, developers, publishers, producers, etc.
  1244. # [10:59] <anne> Zeros, it's impossible to change <img>
  1245. # [10:59] <anne> Zeros, except maybe in XHTML5 but I don't really see the major advantage it gives. And indeed, <object> is there
  1246. # [10:59] <Grauw> so HTML6 or HTML11 can define alt text in the body.
  1247. # [11:00] <Grauw> *XHTML6 or XHTML11
  1248. # [11:00] <anne> tylerr, everybody concerned with the "browsable" web + other folks
  1249. # [11:00] <Zeros> anne, It wasn't for the XHTML2 group. Like I said, they fixed all these things ignoring compatibility with legacy UAs. Fixing everything for HTML5 is impossible if you keep that principal
  1250. # [11:00] <tylerr> Sure anne, who are those other folks, and what are their needs?
  1251. # [11:01] <Zeros> HTML5 will forever suffer from the mistakes made with HTML4 to ensure it works in older browsers
  1252. # [11:01] <tylerr> That I feel is what (and who) we need to personify.
  1253. # [11:01] <Grauw> zeros: indeed.
  1254. # [11:01] <Grauw> or actually: only as long as reality requires it.
  1255. # [11:01] <sbuluf> if something defines the scope of this group, is, roughly "back compat" (sorry, hixie, just rough and short general expression)
  1256. # [11:01] <anne> Zeros, you can drop stuff on the authoring side but still require UAs to support it. Dropping the legacy completely is impossible. We have to support the content mankind created...
  1257. # [11:01] * Parts: icaaq (icaaaq@85.228.55.162)
  1258. # [11:02] <sbuluf> zeros, exactly. errors forever.
  1259. # [11:02] <Grauw> what I mean with that is, HTML5 is designed with backwards compatibility with today’s browsers in mind
  1260. # [11:02] <Grauw> if tomorrow’s browsers for HTML6 don’t exhibit certain problems that HTML5 has to work around, then those ugly parts can be removed in HTML6
  1261. # [11:02] <tylerr> Anyway, enough of me espousing my own opinions. Lovely discussion tonight everyone, have a wonderful time and I'll see you all in a good 7 or 8 hours. :-)
  1262. # [11:03] <Grauw> byebye
  1263. # [11:03] <sbuluf> later, tylerr
  1264. # [11:03] <Zeros> anne, Well, browsers have to support it.
  1265. # [11:04] <anne> Zeros, that's what I said, yes.
  1266. # [11:04] <Grauw> browser support is something that changes over time. old content on the web doesn't
  1267. # [11:04] <Zeros> We could also add <image> which honestly makes sense with <audio> and <video>
  1268. # [11:04] <anne> Starting from scratch won't help with that though.
  1269. # [11:04] <Zeros> Might as well hit all three bases at the same time :p
  1270. # [11:04] <anne> Zeros, <image> is actually turned into <img> during parsing
  1271. # [11:04] <sbuluf> starting from scratch, would efeectively mean to fork the web
  1272. # [11:05] <Grauw> I think you can divide legacy in two parts: legacy which is there to support older content, and legacy which is there to support older browsers.
  1273. # [11:05] <anne> sbuluf, some university is working on that...
  1274. # [11:05] <Zeros> anne, which legacy UA added that?
  1275. # [11:05] <Grauw> anne, browser support <image>?
  1276. # [11:05] <Grauw> *browsers
  1277. # [11:05] <sbuluf> anne, the clean state internet thing, i think you mean. but that is *internet*, not web
  1278. # [11:05] <anne> in text/html they do, yes
  1279. # [11:05] <Grauw> cool :)
  1280. # [11:05] <anne> it's a syntax error, mind you ;)
  1281. # [11:06] <sbuluf> anne, clean slate, sorry
  1282. # [11:06] <anne> sbuluf, oh right, that's prolly true
  1283. # [11:06] * Joins: ROBOd (robod@86.34.246.154)
  1284. # [11:06] <anne> Zeros, dunno, prolly Netscape x or IE x
  1285. # [11:06] <Zeros> anne, how often is the <image> tag used though?
  1286. # [11:06] <Grauw> why would one create a new internet :/
  1287. # [11:06] <anne> Zeros, enough to be part of the parsing algorithm
  1288. # [11:06] <Zeros> Grauw, we already have internet2 :)
  1289. # [11:06] <sbuluf> anne, good and interesting thing, imho, altough to change physical wires and protocols, is even way more difficult to ever happen than to change just the web
  1290. # [11:07] <Grauw> let's just implement IPv6 everywhere and all be happy :)
  1291. # [11:07] <Zeros> anne, There's plenty of things <bgsound> though that are very rare. Why not just overload <image> to be <image>content</image>
  1292. # [11:07] <Zeros> things such as
  1293. # [11:08] <sbuluf> grauw: http://cleanslate.stanford.edu/
  1294. # [11:08] <anne> Zeros, because that would break stuff
  1295. # [11:08] <anne> Zeros, <bgsound> is also part of the parsing algorithm iirc
  1296. # [11:09] <Grauw> sbuluf, thanks, I'll give it a read
  1297. # [11:09] <anne> I checked, <bgsound> is part of the parsing algorithm
  1298. # [11:09] <Zeros> anne, what would it break? <image src="foo">sometext</image> with an optional end tag would not break anything in legacy UAs. They'd see both the alternate content and the image, but that's not really breaking.
  1299. # [11:10] <sbuluf> if we had basically just a bunch of <section>'s, the parsing algorythm would be pretty simpler, right?
  1300. # [11:10] <Zeros> <image src="foo"> would still be valid in a legacy UA
  1301. # [11:10] <Zeros> anne, your parser mangling would still be valid since the src attribute is the same
  1302. # [11:10] <anne> Zeros, try to study how parsing works before making such claims
  1303. # [11:11] <anne> <image> is not valid, it's a syntax error...
  1304. # [11:11] <Grauw> sbuluf: not more simple than any other XML document
  1305. # [11:11] <Zeros> anne, How is that different than <section> which is also a syntax error in older UAs?
  1306. # [11:11] <Grauw> anne: we could rename <img> to <image> without creating browser compat problems :)
  1307. # [11:11] <Zeros> the tag doesn't exist
  1308. # [11:11] <anne> well, XML is fricking complex due to the internal subset
  1309. # [11:11] <sbuluf> grauw, right. but simpler than current html algorythms, i meant.
  1310. # [11:11] <Zeros> you're correcting it to <img>
  1311. # [11:11] <Zeros> what's the problem?
  1312. # [11:11] <Grauw> sbuluf, anything is simpler than HTML parsing :)
  1313. # [11:11] <anne> Grauw, that would invalidate lots of content for no reason
  1314. # [11:12] <anne> HTML parsing isn't that complex
  1315. # [11:12] <Grauw> anne, I meant it as a joke ;p
  1316. # [11:12] <anne> fair enough
  1317. # [11:13] <Zeros> anne, Opera 9 is fine with <image src="">...</image>
  1318. # [11:13] <anne> Zeros, learn how parsing works, introducing an optional end tag like that wouldn't work
  1319. # [11:13] <sbuluf> grauw, if parsing was tremendously simpler, then perhaps what browser vendors do could become less important (and show stopping), since perhaps anyone could make one
  1320. # [11:13] <Grauw> Zeros, please test in IE6, because that’s what’s really relevant :)
  1321. # [11:13] <Zeros> anne, how is it different than XML?
  1322. # [11:13] <Grauw> sbuluf: I’m not following you here
  1323. # [11:13] <sbuluf> grauw, and perhaps we could finally have wymiwyg editors in the bargain, hence avoiding end-users the need to ever see the code
  1324. # [11:13] <Grauw> parsing is only a tiny little bit of showing the document to the user
  1325. # [11:14] <anne> Zeros, how can you tell whether you have to do with an oldschool <image> element or a new <image> element which requires a closing tag?
  1326. # [11:14] <anne> Zeros, that's just introducing unneeded complexity for no real benefit
  1327. # [11:14] <sbuluf> grauw, ahh. any place where i could learn about percentages of code per task?
  1328. # [11:14] <anne> also, define "Opera 9 is fine"
  1329. # [11:15] <anne> preferably by providing a pointer to a testcase
  1330. # [11:15] <Zeros> anne, if you defined it as strictly inline content since that's where <img> is allowed then next block element or </image>
  1331. # [11:15] <anne> what?
  1332. # [11:15] <Zeros> anne, the same way you close <p>
  1333. # [11:15] <anne> that would break lots of content currently using <image>
  1334. # [11:16] <Zeros> anne, No. If you hit another block element and there was no </image> you assume its empty. If you hit </image> before hand then what proceeded it is the content of the <image>
  1335. # [11:16] <Zeros> That doesn't change how <image> or <img> works at all
  1336. # [11:16] <sbuluf> anne, perhaps you...side request: any page where i could learn about how much of a browser code and complexity belongs, by taks (parsing, rendering, etc)
  1337. # [11:17] <anne> Zeros, that requires look ahead and that's not really acceptable
  1338. # [11:17] <Zeros> Why is that not acceptable?
  1339. # [11:17] <Hixie> that would require backtracking during parsing which is susceptible to XSS attacks when combined with user-provided data and man-in-the-middle DOS attacks
  1340. # [11:18] <Grauw> sbuluf, I don’t know if it can be quantified like that, it'll differ per-browser
  1341. # [11:18] <anne> sbuluf, HTML5 should describe most of the parsing stuff
  1342. # [11:18] <Grauw> what you could do is check out the Mozilla source code and look at how much disk space of source code each component occupies
  1343. # [11:18] <sbuluf> grauw, right. i know so little about it, though, that even aproximations would help
  1344. # [11:18] <Zeros> Hixie, how is backtracking in the parser going to open an XSS hole with user data and a man in the middle?
  1345. # [11:19] <Zeros> You're just shifting the nodes to be children of the <image> instead of the parent node.
  1346. # [11:19] <anne> sbuluf, together with other people I wrote an open source Python implementation of the HTML5 parser, you could play with that...
  1347. # [11:19] <Grauw> sbuluf: just think of the many other technologies involved, CSS (which is hugely complex compared to parsing algorithms), building a DOM from parsed XML, all the UI, network technologies, image rendering, plugin architecture
  1348. # [11:19] <Grauw> parsing is just one of the many bits.
  1349. # [11:19] <sbuluf> anne, more tgeenrally..why are browsers so big and complex? which parts are the biggest and mor complex? any place where i could learn about composition, percentages?
  1350. # [11:20] <anne> sbuluf, trac.webkit.org and lxr.mozilla.org maybe...
  1351. # [11:20] <Hixie> Zeros: actually yeah you're right, with <image> it wouldn't be an XSS attack, it would just be an alternate content replacement, which is no big deal really
  1352. # [11:20] <sbuluf> anne, grauw, yes, i ment whole browsers, not just parsers
  1353. # [11:20] <sbuluf> anne, thanks
  1354. # [11:20] <Hixie> Zeros: still, look-ahead is extremely expensive and browser vendors wouldn't want to add that kind of feature.
  1355. # [11:20] * Joins: karl (karlcow@128.30.52.30)
  1356. # [11:21] <Zeros> Then we need better semantics for <object> when used for images.
  1357. # [11:21] <anne> such as?
  1358. # [11:21] <Zeros> "<object> should be semantically equivalent to <img> when data points to an image resource and the remote resource is loaded correctly"
  1359. # [11:21] <anne> but what's the use case really?
  1360. # [11:22] <Grauw> yes, what’s the use case for <img> <video> and <audio> if you could just use <object> ;p
  1361. # [11:22] <Zeros> anne, alternate content as with the inside of <video>
  1362. # [11:22] <Zeros> Since you can't do it with <img>, you'd be stuck with <object> which is a really generic remote resource since it can be anything
  1363. # [11:23] <anne> When is alt= not good enough?
  1364. # [11:23] <Grauw> what’s the problem with that, Zeros?
  1365. # [11:23] * anne rarely encounters such a case
  1366. # [11:23] <Zeros> anne, why shouldn't <video> just have alt then?
  1367. # [11:24] <anne> it's considered better practice to not hide content in attributes
  1368. # [11:24] <Grauw> Zeros, alt is there for compatibility with HTML parsing algorithms that browsers employ, simple. It’s not ideal, but it works.
  1369. # [11:24] <Zeros> if <audio> or <video> should be allowed complete descriptions why not images? And what's the harm is stating that <object> is semantically equivalent to an <img> when it points to one?
  1370. # [11:24] <anne> in the case of <video> it allows some fallback for legacy browsers
  1371. # [11:24] <Grauw> Zeros: wouldn’t that be stating the obvious?
  1372. # [11:24] * anne would expect anything besides fallback to be used inside <video>
  1373. # [11:25] <anne> wouldn't*
  1374. # [11:25] <Grauw> alternate text is fallback
  1375. # [11:25] <hsivonen> Zeros: compatibility trumps consistency
  1376. # [11:25] <anne> fallback for legacy browsers*
  1377. # [11:25] <Zeros> Grauw, Not necessarily since object could be anything.
  1378. # [11:25] <Zeros> If you just look at the object tag itself its very generic
  1379. # [11:25] <Grauw> if an object includes an image, it's an image
  1380. # [11:26] <Zeros> its an object that embeds an image, its not the same as <img>
  1381. # [11:26] <Grauw> what purpose is there to indicate it with a tag, when really it's the included content that really makes it an image?
  1382. # [11:26] <hsivonen> "22:53 * DanC is sorry for <object>; thinks it's a pretty big waste of everybody's time
  1383. # [11:26] <hsivonen> "
  1384. # [11:26] <Zeros> hsivonen, The argument wasn't either though. It was that I'd be more complicated in the parser to deal with it.
  1385. # [11:26] <hsivonen> (Can't remember which day that was from)
  1386. # [11:26] <Grauw> hsivonen, how does he mean that?
  1387. # [11:27] <sbuluf> <Grauw> what purpose is there to indicate it with a tag, when really it's the included content that really makes it an image? <--same idea for using just <section>'s =P
  1388. # [11:27] <Zeros> And they screwed up object when they allowed the classid nonsense
  1389. # [11:27] <Grauw> sbuluf: no it’s not
  1390. # [11:27] <sbuluf> grauw, instead of ol, ul, table, p, car, employee...
  1391. # [11:27] <hsivonen> Grauw: I guess you have to ask DanC for the details. I can observe that <object> implementability sucks.
  1392. # [11:28] <anne> sbuluf, somehow your idea of a new markup language doesn't strike me as particularly useful to me as an author
  1393. # [11:28] <Grauw> sbuluf, that is not inherent to text
  1394. # [11:28] <Grauw> even not to a human reader, if it is not supported by certain presentation
  1395. # [11:29] <sbuluf> anne, souldn't anyone, including grandma and grandpa be able to write perfectly valid content, ready for the future and all, withour even ever having to learn the language? how could we ever achieve that with current specs complexity?
  1396. # [11:30] <anne> sbuluf, editors?
  1397. # [11:30] <sbuluf> anne, yes
  1398. # [11:30] <Zeros> sbuluf, browsers solved that a long time ago by allowing soup.
  1399. # [11:30] <sbuluf> anne, i mean wymiwyg edotors
  1400. # [11:30] <Grauw> hsivonen, can't find it in the logs on krijnhoetmer.nl
  1401. # [11:31] <Zeros> sbuluf, if your grandma can get markup that's almost right or close to it the browser does the rest.
  1402. # [11:31] <Zeros> They don't need to be that concerned with the spec
  1403. # [11:31] <Grauw> that's too bad
  1404. # [11:31] <hsivonen> Grauw: it was on #whatwg back in the WhatBot days
  1405. # [11:31] <Grauw> ah
  1406. # [11:31] <Grauw> that DanC is Dan Connolly, right?
  1407. # [11:31] <anne> yes
  1408. # [11:31] <hsivonen> Grauw: so the /wii claimed
  1409. # [11:32] <Grauw> is whatbot archived somewhere?
  1410. # [11:32] <sbuluf> zeros, if you expect good code, high-level machine processability (read semweb), etc...then i think it is important.
  1411. # [11:32] <hsivonen> Grauw: I don't know. Charl and Krijn may have a plan
  1412. # [11:33] <Grauw> hsivonen: the DanC here doesn’t necessarily have to be the same as on the whatwg list :)
  1413. # [11:33] <anne> DanC isn't on the WHATWG list
  1414. # [11:33] <sbuluf> only one danc around, afaik
  1415. # [11:33] <Grauw> too bad, I would have liked to see the context
  1416. # [11:33] <Grauw> *whatwg IRC
  1417. # [11:33] <anne> http://whatbot.charlvn.za.net/ looks dead
  1418. # [11:34] <Zeros> sbuluf, well machines already process it. Anyway, the web in terms of code quality sucks. Replacing it with some other language probably wouldn't change that. It'd just get fragmented and messed up again and the new browsers would get to deal with it.
  1419. # [11:34] * Grauw nods
  1420. # [11:34] <anne> yup, happened to XML
  1421. # [11:34] <anne> or happens
  1422. # [11:35] <sbuluf> zeros, isn't hand coding the main source of bad code in the web?
  1423. # [11:35] <anne> all code derives from "hand coding"
  1424. # [11:35] <sbuluf> what if nobody had to hand code anymore (or even have to learn the languages, for that matter)
  1425. # [11:35] <anne> and since people are flawed, it will always go "wrong"
  1426. # [11:36] <sbuluf> anne, what is editors themselves would not allow aerrors?
  1427. # [11:36] <anne> we better just accept that and design the language around it
  1428. # [11:36] <Grauw> sbuluf: you always have to learn something
  1429. # [11:36] <sbuluf> *if
  1430. # [11:36] <anne> sbuluf, editors are made by people
  1431. # [11:36] <sbuluf> anne, bugs aside, of course
  1432. # [11:36] <sbuluf> i mean design
  1433. # [11:36] <anne> bugs will always be there
  1434. # [11:37] <sbuluf> yep, and can be fixed, just like always
  1435. # [11:37] <anne> yes, but at that point you already have deployed content
  1436. # [11:37] <Grauw> bugs are being fixed though, e.g. with regard to <object>
  1437. # [11:37] <anne> you have to take into account that it won't be flawless and design for that
  1438. # [11:37] <Grauw> sometimes it's a problem, but often it's not
  1439. # [11:38] <sbuluf> if you are already in a level of processability like that allowed say by xml...then could you not provide an external routine to upograde legacy content to the newest version?
  1440. # [11:38] <anne> now <object> finally has a halfdecent spec we might get some more fixes, yes...
  1441. # [11:38] <anne> sbuluf, you'd have to solve the halting problem first
  1442. # [11:38] <Grauw> I'm pretty sure Mozilla's not going to build in back compat stuff in their SVG implementation just because they released a half-finished one in Firefox 1.5
  1443. # [11:38] <Hixie> i'm curious as to how you'll create an editor that always generates the write markup
  1444. # [11:39] <Hixie> is it to be omniscient?
  1445. # [11:39] <sbuluf> hixie, so am i! =P
  1446. # [11:39] <Hixie> anne: only half decent? ;-)
  1447. # [11:39] <Hixie> er
  1448. # [11:39] <Hixie> "right" markup
  1449. # [11:39] <Hixie> oops
  1450. # [11:39] <anne> Hixie, it has red boxes and such :)
  1451. # [11:39] <sbuluf> hixie, but my main worry, is that i do not see anyone even trying today
  1452. # [11:39] <Hixie> anne: fair point!
  1453. # [11:40] <Hixie> sbuluf: oh i know people are trying, i've spoken to them. they just don't know how.
  1454. # [11:40] <Grauw> and Microsoft also didn't build in back compat stuff in their XSLT implementation for their old IE5’s XSLT WD implementation
  1455. # [11:40] <sbuluf> hixie, perhaps my cdl model would be simple enough to allow it, as opposed to the current complexity of (x)html specs
  1456. # [11:40] <Hixie> sbuluf: you can only spend so many months prototyping doomed semantic editors before business concerns force you to bite the bullet and make "WYSIWYG" ones
  1457. # [11:40] <Hixie> sbuluf: maybe
  1458. # [11:40] <sbuluf> hixie, if so, then again the problem is...back compat and legacy, or new stuff?
  1459. # [11:41] <Hixie> sbuluf: if so, a simple transform from your language to HTML would then solve the problem :-)
  1460. # [11:41] <anne> sbuluf, I wonder if you can really design a language less complex that solves the same use cases. But it would be nice...
  1461. # [11:41] <Grauw> that is, if his language is XML-based then the transformation would be simple ;p
  1462. # [11:42] <sbuluf> anne, so do i. i would like to gather some serious people to...at least try!
  1463. # [11:42] <Hixie> doesn't have to be XML
  1464. # [11:42] <anne> if it's XML-based it won't be flawless
  1465. # [11:42] <Hixie> so long as there's a parser for it
  1466. # [11:42] <Hixie> and a serialiser from that to HTML
  1467. # [11:43] <sbuluf> what scares the bejesus out of me, is that i do not see anyone even trying
  1468. # [11:43] <sbuluf> i'm no expert, even a techie, myself...but who else is doing such things?
  1469. # [11:44] <hsivonen> I'd love to see oXygen grow a Mathematica-like view to editing XHTML
  1470. # [11:44] <hsivonen> Etna certainly is interesting
  1471. # [11:44] <Hixie> like i said. i know people are trying, i've spoken to them. they just don't know how to do it. they can only spend so many months prototyping doomed semantic editors before business concerns force them to bite the bullet and make "WYSIWYG" ones.
  1472. # [11:44] <sbuluf> hixie, wat if we could leave bussiness out of the equation, altogether?
  1473. # [11:45] <anne> there'd be no funding
  1474. # [11:45] <Hixie> then they'd starve and die, i guess.
  1475. # [11:45] <sbuluf> it would have to be a foss sort of spec making, right
  1476. # [11:46] <Grauw> I don’t think that you can’t make business if your editor isn’t WYSIWYG
  1477. # [11:46] <sbuluf> but would that avoid the problem, if people contributed for free, and we could keep bussiness out of it?
  1478. # [11:47] <Grauw> If you take Word for example, there’s tons of people who just click the center and bold buttons and up the font size when they want to create a heading
  1479. # [11:47] <hsivonen> The way I see it is that a "semantic" editor should expose the document tree but should allow new paragraph to be created by pressing return instead of typing <p>
  1480. # [11:47] <Grauw> yet especially companies are giving trainings to their employees to use the heading functionality in Word
  1481. # [11:48] <sbuluf> graw, but that's what you see, not what you mean
  1482. # [11:48] <Grauw> so that e.g. their documents conform to company style
  1483. # [11:48] <Hixie> sbuluf: Free or Open Source software still has to have a business there, or the people have to have other jobs -- but yes, you could maybe find volunteers willing to prototype new UI ideas for semantic editors. I encourage you to start such a project.
  1484. # [11:49] <sbuluf> hixie...introduce me to all your fiends! i'm not even a programmer, myself. help needed
  1485. # [11:49] <Grauw> no, once you say 'it's a heading' you indicate what you mean (‘WYSIWYM’ or ‘WYMIWYG’), and not what you see (WYSIWYG)
  1486. # [11:49] <Hixie> my friends who have knowledge for making editors are all working on editors already
  1487. # [11:50] <sbuluf> hixie, they, unfortunately )1 want money 2) assume current specs (with which i think the task is just about impossible
  1488. # [11:51] <sbuluf> right?
  1489. # [11:51] <Grauw> If browsers provide a generic control to input semantic markup, I think you can get people to adopt that fairly quickly. Schools will teach it, and companies will give trainings.
  1490. # [11:51] <Grauw> just like they now do so for Word
  1491. # [11:51] <Grauw> I learned to use ‘Heading 1’ and not ‘bold center font size 24’ for heading in high school
  1492. # [11:52] <Zeros> Hixie, kudos on killing off all the ActiveX/IE related properties of <object>
  1493. # [11:52] <Grauw> (iirc :))
  1494. # [11:52] <sbuluf> grauw, i think so too. the problem is that current specs are way too complex for that, imho. on top, these current specs were not thought with editing in mind, for ages
  1495. # [11:52] <Hixie> sbuluf: they want food and a place to live, and to have a happy life; beyond that i doubt they have any fixed requirements.
  1496. # [11:52] <hsivonen> Grauw: Word is easier to create a UI for because there is a sequence of blocks and arbitrary nesting of blocks is not allowed
  1497. # [11:52] <Grauw> sbuluf, I don't see how really
  1498. # [11:53] <Grauw> hsivonen, you can't arbitrarily nest <p> elements either
  1499. # [11:53] <Hixie> sbuluf: if you can make a new language that is easy to make a UI for, then you just need to define a mapping from that language to HTML and back again and you're done.
  1500. # [11:53] <Hixie> sbuluf: that language can be proprietary, an internal aspect of the editor.
  1501. # [11:53] <sbuluf> hixie, by "money" i meant just that, right. burt would they, or instance, be willing to try a new spec for doing it?
  1502. # [11:53] <Hixie> sbuluf: i'm sure they've even tried writing new specs themselves for it
  1503. # [11:54] <sbuluf> hixie, could you contact me, then?
  1504. # [11:54] <Grauw> I think Hixie is a busy man.
  1505. # [11:54] <Grauw> :)
  1506. # [11:54] <sbuluf> i'm sure he is
  1507. # [11:54] <Hixie> sbuluf: like i said, they're already working on editors full time, it's not like they're going to additionally work unpaid on other editors in their free time
  1508. # [11:55] <Hixie> having the same hobbies as fulltime work is not conducive to a healthy lifestyle
  1509. # [11:55] <Grauw> what I mean is, you can do the research and contact them yourself :)
  1510. # [11:55] <sbuluf> hixie, right, sorry, so the money part does not allow for meaningful interaction
  1511. # [11:56] <sbuluf> grauw, not easy even to find them. and i can do brainstorming, right, but only up to some point. no expert myself.
  1512. # [11:56] <anne> sbuluf, if you have an idea that's substantially better than what's out there just publish it and ask for comments
  1513. # [11:57] <anne> sbuluf, if people like it they might join you in some project
  1514. # [11:57] <Grauw> Daniel Glazman is one person with a lot of experience developing editors. His Etna editor, uses existing XML schema languages (I think RelaxNG) with some extensions that are particularly useful for editing, in combination with CSS. There are others too.
  1515. # [11:57] <anne> sbuluf, trying to find commitment without having proven anything seems like an impossible task
  1516. # [11:57] <sbuluf> anne, trying to at the moment, right. (those very beta pages you saw are part of that)
  1517. # [11:57] * anne didn't see anything
  1518. # [11:57] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
  1519. # [11:57] * anne thinks xopus.com is pretty good
  1520. # [11:57] <sbuluf> grauw, daniel was the first person i wanted to contact, right, also lachy here has some interest.
  1521. # [11:58] <sbuluf> anne, sorry: http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm
  1522. # [11:58] <sbuluf> i thought you have seen them
  1523. # [11:58] <Hixie> sbuluf: they've already spent months trying to do this; unless you have a clearly compelling idea for how to solve the problem, i doubt they'd be interested in investing time trying to understand it (as they'd probably have already tried it themselves)
  1524. # [11:58] <sbuluf> anne, i checked xopus, interesting, right
  1525. # [12:00] <Grauw> Anne, heh, Q42 :)
  1526. # [12:00] <Grauw> In Firefox it tells me I can't use it. In IE it tells me I can't be blocking popups (which it does by default).
  1527. # [12:00] <sbuluf> hixie: almost empty content authoring language (just <section>, basically), with hooks to externally define presentation, meaning, datastructure, behaviour, etc. clean separation of content from everything else (css style). that would be the core, and imho, simplifies the editing task.
  1528. # [12:00] <anne> yeah, disclaimer on my about page :)
  1529. # [12:00] <Grauw> If this were a forum, I’d be gone by now ;p
  1530. # [12:01] <MikeSmith> oXygen XML editor (hsivonen mentioned earlier) has a lot of interesting features - http://www.oxygenxml.com/
  1531. # [12:01] <sbuluf> MikeSmith, thanks, xopus, via anne, was interesting too
  1532. # [12:01] * anne doesn't really see how sbuluf's proposal solves any problem
  1533. # [12:02] <Hixie> sbuluf: my understanding is that that kind of thing has been tried, and not found to be successful as a base on which to create a useable editor. But if you can show otherwise, then that would be great.
  1534. # [12:02] <Grauw> Etna does that, to some extent.
  1535. # [12:02] <Grauw> I mean, separating out the styles
  1536. # [12:02] * Grauw really excited about Etna ;p
  1537. # [12:03] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
  1538. # [12:03] <sbuluf> hixie, anne, i'll try. thanks for your time, btw. lachy and daniel glazman might be interested as well.
  1539. # [12:03] <Hixie> the test is "can your mum use it?"
  1540. # [12:03] <Hixie> anyway, i should go to bed
  1541. # [12:03] <Hixie> nn
  1542. # [12:03] <sbuluf> hixie, definitely. granda and grandpa, to be precise.
  1543. # [12:03] <Grauw> mum is good enough
  1544. # [12:03] <Grauw> grandpa and grandma will die soon
  1545. # [12:04] <Grauw> before it's standardised :)
  1546. # [12:04] <sbuluf> =P
  1547. # [12:04] <MikeSmith> my mum is an kernel programmer
  1548. # [12:04] <sbuluf> (see what i meant, grauw?)
  1549. # [12:05] <sbuluf> anne, i'd need to write some more on the editing aspect of things.
  1550. # [12:05] <sbuluf> anne, i can attempt to explain here now, however, if you wish
  1551. # [12:06] * Grauw shrugs * sbuluf, there’s plenty of grandfathers and grandmothers having careers in computer science as well.
  1552. # [12:06] <sbuluf> =P
  1553. # [12:07] <sbuluf> we could still move beta testing to nurseries
  1554. # [12:10] <hsivonen> a guy working for a POS vendor told me they have a requirement that an eight-year-old has to be able to operate their product
  1555. # [12:11] <sbuluf> today's kids can program networks when 3 y/o. scary. but yes, kids are the other beta testing ground
  1556. # [12:12] * MikeSmith imagines a row of eight-year-olds working the cash registers at his local supermarket
  1557. # [12:12] * Quits: st (st@62.234.155.214) (Quit: st)
  1558. # [12:13] <sbuluf> hsivonen, weirdly, an roughly...the lenght of the documentation needed for them to undertand it (which is never exactly zero, no matter how good you might do it), can work as a rough indicator too.
  1559. # [12:15] <sbuluf> hsivonen, which was an argument i had with tim berners lee, btw. i said that before keeping work on semantic web stuff, a "end-user's manual" should be written, screenshots and all
  1560. # [12:16] <Grauw> semantic web stuff is not meant for end-users
  1561. # [12:16] <Grauw> it's a backend thing
  1562. # [12:16] <sbuluf> grauw...but it should be usable by end users.
  1563. # [12:17] <hsivonen> Grauw: haven't you heard the blue sky talk?
  1564. # [12:17] <Grauw> normal users should only have to deal with tools
  1565. # [12:17] <hsivonen> Grauw: ah. tools will save us
  1566. # [12:17] <Grauw> not with URIs and RDF/XML
  1567. # [12:17] <Grauw> hsivonen, >.<
  1568. # [12:17] <hsivonen> I see
  1569. # [12:18] <sbuluf> grauw, but precisely...i wanted to see en end-user manual, an UI anyone could use, etc, without ever having to learn any backend stuff.
  1570. # [12:18] <sbuluf> "what do i show grandma?"
  1571. # [12:18] <Grauw> if a user types in Google Maps that he wants to travel from New York to Paris, it's up to the tool (Google Maps) to interpret the data from data sources and provide the user with meaningful things, such as Pizza Hut icons
  1572. # [12:18] * hsivonen notes that hCal addresses the canonical Semantic Web use case
  1573. # [12:19] <Grauw> Microformats suck :)
  1574. # [12:19] <anne> so does HTML
  1575. # [12:19] <anne> (in a way)
  1576. # [12:19] <Grauw> ;p
  1577. # [12:20] <hsivonen> I want to see markup conformance requirement and consumer processing models for microformats
  1578. # [12:20] * sbuluf refrains from showing a big sign calling everyone for revolution (out of scope here)
  1579. # [12:20] * Joins: hasather (hasather@81.235.209.174)
  1580. # [12:21] <anne> what we're doing might be considered revolution by some people
  1581. # [12:22] <sbuluf> anne, compared to the web stalling for years on end, probably is. i meant bigger one, so to speak.
  1582. # [12:23] <anne> compared to the XML web vision some people have, I meant
  1583. # [12:23] <Grauw> I think the first instinct of many people when something’s not working properly, is to create something new
  1584. # [12:24] <Grauw> but creating something new is often not very productive, and involves a big investment
  1585. # [12:24] <anne> yeah, see the <q> / <blockquote> -> lets have <quote>! i'm brillaint
  1586. # [12:24] <Grauw> (note the implicit reference to <object> and <video> ;p)
  1587. # [12:24] <sbuluf> anne, i have seen your ideas about xml, strictness vs. error handling, etc. i'm your opposite, i'm afraid. altough i'd really value to hear more on your reasons.
  1588. # [12:25] <anne> Grauw, <object> works completely different from the proposed <video> element
  1589. # [12:25] <anne> Grauw, you'd have to add all kinds of attribute and such to it to make it do video in which case you might as well introduce a new element
  1590. # [12:26] <sbuluf> grauw, true. and i tried the incremental thing myself, but i saw flaws that...well, were way to big. my feeling was sort of incredulity. example...the whole web editing by hand, then complaining about bad code. solution to bad code, imho, is to have visual, error-prrof editors (other than bugs, of course)
  1591. # [12:26] <anne> editors are still written by people
  1592. # [12:26] <anne> you can't abstract the problem away like that
  1593. # [12:26] <sbuluf> anne, bugs aside, i mean.
  1594. # [12:27] <Grauw> I’ll write up a proposal when the list is more stable
  1595. # [12:27] <anne> (specs are also written by people, which is another problem)
  1596. # [12:27] <anne> Grauw, WHATWG is where <video> happens mostly...
  1597. # [12:27] <Grauw> for now, I’ve said enough on the subject on the list already :)
  1598. # [12:27] <anne> sbuluf, if you ignore the bugs the design is flawed
  1599. # [12:28] <Grauw> The WHATWG is obsolete now :)
  1600. # [12:28] <sbuluf> anne, is that your argument against strictness, as opposed to error handling?
  1601. # [12:28] <anne> sbuluf, it's one of them
  1602. # [12:29] <anne> Grauw, that largely depends on what this WG does
  1603. # [12:29] <Grauw> I suppose
  1604. # [12:29] <sbuluf> would people not spot bugs, and would not get progrssively fixed?
  1605. # [12:29] <anne> and even then I doubt it given that the WHATWG currently has far more members
  1606. # [12:29] <anne> sbuluf, yes, meanwhile new features are added introducing more bugs, regressions, etc.
  1607. # [12:29] <Dashiva> One web browsers have taught us is that even if you make a better browser, some people will keep using the old ones
  1608. # [12:29] <Grauw> so it's going to be a WHATWG vs. HTML WG after all huh
  1609. # [12:29] <Dashiva> *One thing
  1610. # [12:30] <anne> sbuluf, also, until all bugs are fixed nothing can be deployed because the whole system relies on strictness
  1611. # [12:30] <Dashiva> Once a bug is introduced, it's going to stay around for a long time after it's been fixed
  1612. # [12:30] <anne> which is kind of the problem
  1613. # [12:30] <anne> Grauw, they should just co-exist
  1614. # [12:30] <Grauw> I am really having trouble seeing how that works effectively.
  1615. # [12:30] <sbuluf> anne, presumably, if nothing works mostly, up to some decent point, nobody would deploy to start with.
  1616. # [12:31] <anne> Grauw, give it a few months
  1617. # [12:31] * anne doesn't know it either
  1618. # [12:31] <Grauw> anne, you’re right.
  1619. # [12:31] <Grauw> nobody does.
  1620. # [12:31] <anne> sbuluf, right, that would lead to indefinite delay as the stuff you need to support is so complex you'll never get it right the first time
  1621. # [12:31] <sbuluf> <anne> sbuluf, yes, meanwhile new features are added introducing more bugs, regressions, etc. <--and what about extra code due to legacy errors, which get perpetuated? more code, more room for bugs
  1622. # [12:32] <anne> sbuluf, see all the incremental innovation browsers are doing and how long it takes to get them in line
  1623. # [12:32] <Grauw> if there’s multiple implementations of the same spec, even though their may be individual differences and bugs, at least the set described in the spec would be the common one
  1624. # [12:32] <anne> sbuluf, legacy code can mostly be described in terms of new features
  1625. # [12:33] <Grauw> *there
  1626. # [12:33] <sbuluf> anne, but don't you see xml, for example, as an abstraction of some of the prsing and handling? stuff we do not need to repeat anymore, and that can be reused?
  1627. # [12:33] <anne> sbuluf, for instance, lots of presentational elements can be described in terms of CSS
  1628. # [12:33] <hsivonen> Grauw: here's how it could work:
  1629. # [12:33] <hsivonen> (disclaimer: no legal statements implied)
  1630. # [12:33] <Grauw> problem with HTML was that there’s only been a short time during which there have actually been multiple implementations
  1631. # [12:33] <Grauw> (that is, during the time IE and NS were competing, before that it was only NS and after that it was only IE)
  1632. # [12:34] <hsivonen> Hixie edits a sigle spec in the WHATWG SVN, creates a WHATWG version every time he commits
  1633. # [12:34] <hsivonen> once in a while a W3C snapshot is published under /TR/
  1634. # [12:34] <hsivonen> with different headers
  1635. # [12:34] <hsivonen> basically the XBL2 model
  1636. # [12:34] <sbuluf> grauw, i asked timbl that w3c make a browser. or at least core libraries, that browser vendors could all use. that way, no more loss of synchrony among implementations. unfortunately, he did not answer
  1637. # [12:34] <anne> prolly also published on dev.w3.org
  1638. # [12:35] <Grauw> the problem is the segmentation of the discussion
  1639. # [12:35] <anne> sbuluf, I don't think browser vendors would want that
  1640. # [12:35] <hsivonen> Grauw: I expect people who truly care to subscribe to both lists eventually
  1641. # [12:36] <Grauw> sbuluf: the W3C doesn’t have the resources to make a browser for all their technologies
  1642. # [12:36] <Grauw> plus, there’s Amaya, http://www.w3.org/Amaya/
  1643. # [12:36] <anne> and even if they did, it wouldn't support the real world
  1644. # [12:36] <hsivonen> Grauw: the WHATWG list can't be obsoleted, because there are people who are barred from subscribing to the HTML WG list
  1645. # [12:36] <anne> of which Amaya is the perfect evidence :)
  1646. # [12:37] <sbuluf> anne, from a pure efficiency POV...isn't it to have many teams (one per vendor) doing just about the same a crazy thing? also, each gets to be slightly different, driving everyone else crazy...
  1647. # [12:37] <Grauw> hsivonen: why would they be barred
  1648. # [12:37] <anne> sbuluf, I think it helps driving innovation
  1649. # [12:37] <hsivonen> Grauw: if they have a financial relationship with a W3C Member and the AC rep of the Member decides not to nominate them
  1650. # [12:37] <sbuluf> grauw, amaya, close, but no cigar, unfortunately. i asked him to make a massively deployable one
  1651. # [12:38] <anne> less people working on the same problem likely leads to less innovation
  1652. # [12:38] <Grauw> hsivonen, afaik there’s a lot of Mozilla people on the list as ‘invited experts’
  1653. # [12:38] <anne> IBM employees for instance
  1654. # [12:38] <anne> Y! employees are another example
  1655. # [12:38] <sbuluf> anne, right, amaya does not quite make it. but spec makers doing also the core libraries, would solve also the problem of they spitting specs with both hands, while everyopne else tries to implement them
  1656. # [12:39] <hsivonen> I know of one IBM employee and one Nokia employee who would like to join but are barred from joining
  1657. # [12:39] <Grauw> why can Mozilla people join as invited experts, but IBM and Nokia people not?
  1658. # [12:39] <anne> sbuluf, spec writers, implementors and testsuite creators are at best separate persons
  1659. # [12:39] <sbuluf> anne, innovation could be, in the form of feedback, concentrated in just one point, instead of dispersed among many different implementations
  1660. # [12:39] <anne> Grauw, W3C Patent Policy
  1661. # [12:40] <anne> sbuluf, I don't see how that would work
  1662. # [12:40] <Grauw> if it’s the patent policy, it’s a good thing that they can’t join then
  1663. # [12:40] <sbuluf> anne, which part?
  1664. # [12:40] <Grauw> because otherwise everything they suggest might be patented by IBM or Nokia in the future
  1665. # [12:40] <anne> "in the form of feedback"
  1666. # [12:40] <Grauw> I wouldn’t put it past them either
  1667. # [12:41] <Grauw> Both companies have huge patent libraries.
  1668. # [12:41] <sbuluf> anne, we all debug just one implementation, that we all use (including opera, mozilla, tec)
  1669. # [12:41] <Grauw> sbuluf: it's not going to happen, period.
  1670. # [12:41] <hsivonen> Grauw: I guess the answer is one of the following: 1) the invited expert Mozilla people contribute to Mozilla without getting money from a Member or 2) they did not make the required disclosure or 3) the W3C is not applying its policies uniformly
  1671. # [12:41] <Grauw> and diversity is good.
  1672. # [12:41] <anne> yes
  1673. # [12:42] <Grauw> the whole nature of the web is rooted in diversity, and not a sole provider for content/implementations/ontologies.
  1674. # [12:44] <sbuluf> graw, take any soft category (picture viewers, for instance). many people started differently, almost all ended up doing, at the end, just about the same. the process converges towards trhe logical features for the task. meantime, however, we, the world, splitted our valuable feedback among scores of people repeating the same thing., if we concentrated feedback on just one, we could debug way faster, no?
  1675. # [12:44] <sbuluf> (need to disconnect, will be back in some ten seconds)
  1676. # [12:45] <hsivonen> Grauw: I think you are mischaracterizing the effect of the Patent Policy and the implications of IBM or Nokia employees joining
  1677. # [12:45] <anne> maybe you should read up about Mozilla and Firefox
  1678. # [12:45] <Grauw> hsivonen: the policy is there for a reason.
  1679. # [12:45] <anne> I mean, the Mozilla Suite and Firefox
  1680. # [12:45] * Joins: pk (udshq@200.49.140.168)
  1681. # [12:45] <Grauw> anne, you mean Seamonkey? :)
  1682. # [12:45] * pk is now known as sbuluf-
  1683. # [12:45] <anne> Grauw, it wasn't called that way back then
  1684. # [12:46] <hsivonen> Grauw: yes.
  1685. # [12:46] <Grauw> ah, you mean the history.
  1686. # [12:46] <anne> only because Firefox started of as a separate project innovation could take place
  1687. # [12:46] <anne> it's a pretty good example of why centralizing everything doesn't have to be good
  1688. # [12:47] <hsivonen> Grauw: but making the mailing list public and archived is already a partial defense against Nokia and IBM people suggesting something and then proceeding to patent it
  1689. # [12:47] <Grauw> there’s not one way to do things.
  1690. # [12:47] <sbuluf-> i think it depends how it is done
  1691. # [12:47] * Quits: sbuluf (hem@200.49.140.228) (Ping timeout)
  1692. # [12:47] <sbuluf-> grauw, if there is real reason for more than one, then more than one implementation is justified.
  1693. # [12:47] <Grauw> hsivonen: if it were sufficient, Microsoft (and others I presume) wouldn’t have pressed for having the group at the W3C
  1694. # [12:47] <hsivonen> Grauw: the Policy helps with the case where the order of events is the other way round. And it makes your case less expensive to defend against
  1695. # [12:48] <hsivonen> Grauw: having all the major players agree to the Patent Policy is good
  1696. # [12:48] <anne> Grauw, even Invited Experts have to declare all known patents
  1697. # [12:48] <anne> Grauw, so they can't just suggest something their company has patented with themselves knowing about that
  1698. # [12:49] <Grauw> anne, yes, that’s exactly what I mean...
  1699. # [12:49] <Grauw> hsivonen, IBM is a major player if it comes to software patents :)
  1700. # [12:50] <hsivonen> Grauw: but it still makes sense to listen to people who make random comments and have not explicitly agreed to the Policy
  1701. # [12:50] <hsivonen> Grauw: it would certainly be good to get IBM to join
  1702. # [12:50] <anne> sbuluf-, I think you have to come up with some more substantial evidence than "I think". There's far more evidence supporting a decentralized approach atm.
  1703. # [12:51] * Quits: loic (loic@90.29.252.98) (Ping timeout)
  1704. # [12:51] <Grauw> sbuluf: it’s simple, if I want to make a web browser I don’t want to be forced to use this ‘base implementation’. There can be several reasons why I wouldn’t want to, e.g. because it doesn’t scale to my needs (either mobile or something bigger), or I just don’t like the way it’s programmed, or I want it in a different programming language, etc.
  1705. # [12:51] <Grauw> hsivonen: it would be good to put a little more pressure on them to do so by moving everything to the HTML WG
  1706. # [12:52] <sbuluf-> anne, i included "i think" as a form of courtesy, i think =P . talking more seriously, the pattern i mentioned for shareware cemeteries, is pretty easy to see, imho.
  1707. # [12:52] <Grauw> or I don’t agree with the license terms
  1708. # [12:52] <anne> whatever
  1709. # [12:52] * anne grows tired of this silly discussion
  1710. # [12:53] * Grauw too
  1711. # [12:53] <Grauw> I’m going to get dinner!
  1712. # [12:53] <anne> around lunchtime here
  1713. # [12:54] * hsivonen wonders what Grauw's PeopleLocation is
  1714. # [12:54] <sbuluf-> grauw, otoh, there is the very nature of making standards. if a standard is, by definition, a shared thing...why not to share the core of it's implementation either? browser makers could compite on UI, usability, etc, and still all use the same standard libraries
  1715. # [12:54] <hsivonen> oh. Japan
  1716. # [12:54] * sbuluf- wonders what was silly about it
  1717. # [12:54] <Grauw> I filled it in :)
  1718. # [12:55] <Grauw> sbuluf: it’s out of touch with reality
  1719. # [12:55] <hsivonen> I though the Netherlands
  1720. # [12:55] <Grauw> I’m studying here for a year
  1721. # [12:55] <hsivonen> thought
  1722. # [12:55] <hsivonen> cool
  1723. # [12:55] <Grauw> in august I go back
  1724. # [12:55] <Grauw> yup
  1725. # [12:56] * anne saw some other people from the HTML WG are NL based
  1726. # [12:56] <anne> maybe we should suggest the W3C office in Amsterdam as meeting location? :)
  1727. # [12:56] <Grauw> +1
  1728. # [12:57] <sbuluf-> grauw, i thought we all assumed a variety of feasability levels. that does not make the conversation silly, imho.
  1729. # [12:57] <Grauw> sbuluf, it is if it goes on for lengths :)
  1730. # [12:57] <anne> "Uncertainty Reasoning for the World Wide Web Incubator Group Charter" http://www.w3.org/2005/Incubator/urw3/charter
  1731. # [12:58] <Grauw> plus, I do not want to offend, but I think in order to argue sensibly on certain topics you should have a little more knowledge of the field
  1732. # [12:58] <sbuluf-> sbuluf, "i'm tired, enough for now" would not do, without implying sillyness?
  1733. # [12:59] <sbuluf-> i see. i wonder which part on my side was so out of place.
  1734. # [13:00] * Joins: alexf (alejandro@85.152.42.1)
  1735. # [13:00] <sbuluf-> )rethoric question, no need to answer if tired, of course)
  1736. # [13:00] <alexf> hello everybody
  1737. # [13:00] <sbuluf-> hi
  1738. # [13:01] <hsivonen> anne: interesting
  1739. # [13:03] <anne> yeah
  1740. # [13:05] * MikeSmith (seeing anne's comment about reading up on Firefox and Mozilla) wonders how many people know/remember where what became Firefox came from (who was the driving force behind it)
  1741. # [13:06] * Joins: loic (loic@90.29.147.122)
  1742. # [13:06] <MikeSmith> hsivonen - why do you say the person you know from Nokia is blocked from joining?
  1743. # [13:08] <Grauw> mike, it’s not *that* long ago :)
  1744. # [13:08] <hsivonen> MikeSmith: I noticed that a Nokia-employee tried to follow the instructions for joining as a public invited expert but noticed that the process was not meant for employees of Members. and so far, no one has joined as a Nokia rep.
  1745. # [13:09] <MikeSmith> Grauw - long enough ago that some people don't seem to actually know who it was
  1746. # [13:10] <MikeSmith> hsivonen - OK. I thought that you were saying that Nokia had some reason for not joining.
  1747. # [13:12] <anne> MikeSmith, who was it?
  1748. # [13:12] <MikeSmith> anne - you tell me
  1749. # [13:12] <hsivonen> MikeSmith: I meant that the W3C blocks employees of Members from routing around the AC rep and it appears that at least for the time being the Nokia AC rep has not unblocked Nokia employees.
  1750. # [13:12] <anne> dhyatt and someone else who left the Mozilla project now iirc
  1751. # [13:12] <anne> who both*
  1752. # [13:13] <MikeSmith> the someone else is still with Mozilla, as far as I know
  1753. # [13:13] <hasather> Blake Ross?
  1754. # [13:13] <MikeSmith> yeah
  1755. # [13:14] * Joins: zcorpan_ (zcorpan@84.216.43.95)
  1756. # [13:18] <sbuluf-> later, everyone
  1757. # [13:20] <MikeSmith> anne - more than a few people I have talked with -- including people who know about dhyatt's work on Safari -- don't seem to know that he was involved with Firefox at al
  1758. # [13:21] * Quits: sbuluf- (udshq@200.49.140.168) (Ping timeout)
  1759. # [13:21] <anne> I don't think he cares much for fame
  1760. # [13:23] <MikeSmith> yeah, I guess not
  1761. # [13:26] <MikeSmith> I just wonder sometimes how many people realize that much that creation and characteristics of the applications they use have come from real people, not from, well, corporate marketing departments
  1762. # [13:27] * Parts: alexf (alejandro@85.152.42.1)
  1763. # [13:28] * Joins: Philip (excors@80.177.163.133)
  1764. # [13:35] <anne> woha, 20 events for HTMLMediaElement
  1765. # [13:55] <Grauw> got a link, anne?
  1766. # [13:56] <anne> #media
  1767. # [13:58] <Grauw> well events are usually easy to implement
  1768. # [13:58] <Grauw> just create an event object at the proper location
  1769. # [14:00] <anne> i'm not opposed
  1770. # [14:00] <Grauw> events nice :)
  1771. # [14:02] <Grauw> why doesn’t it enforce OGG Vorbis support, btw, only wave...
  1772. # [14:03] <Grauw> for <audio>, that is
  1773. # [14:03] <Grauw> anyway, I’m seeing a significant overlap between <audio> and <video>, and e.g. why there’s a "Which frame in a video stream corresponds to a particular playback position is defined by the video stream's format." note for video but not for audio I don’t really understand
  1774. # [14:04] <anne> someone said because it was enforced for <video>
  1775. # [14:05] <Grauw> basically, a lot of arguments against <object> (because of the supposed complexity of having different media types on one element) apply to the current phrasing in the spec as well
  1776. # [14:05] <Grauw> *current definition
  1777. # [14:07] <anne> Nokia just joined the WG
  1778. # [14:07] <zcorpan_> ms still missing?
  1779. # [14:07] <Grauw> that’s great news.
  1780. # [14:07] <anne> Mikka Honkala is their guy.
  1781. # [14:08] <anne> zcorpan_, yes
  1782. # [14:09] <anne> Grauw, you mean because the common things between video and audio have been abstracted into a single interface?
  1783. # [14:13] <MikeSmith> anne - I don't know Mikka Honkala yet. Do you know if he works on the S60 browser?
  1784. # [14:13] <anne> he worked on X-Smiles iirc
  1785. # [14:14] <anne> http://hsivonen.iki.fi/honkala-xforms/ has some info
  1786. # [14:14] <hsivonen> Mikko Honkala was one of the main developers of the XForms functionality for X-Smiles
  1787. # [14:14] <MikeSmith> aha
  1788. # [14:15] <hsivonen> my understanding is that in January he was involved with some Nokia-internal XForms stuff. The S60 browser team showed up at his thesis defence, though.
  1789. # [14:15] <anne> From the excerpts on that page he seems like a sensible guy
  1790. # [14:16] <MikeSmith> and he's a bonfied implementor/developer, I guess
  1791. # [14:16] <MikeSmith> bonified
  1792. # [14:17] <MikeSmith> and regardless of what you might think of XForms, you kinda gotta admire somebody who's implemented it
  1793. # [14:18] <MikeSmith> the work of implementing it
  1794. # [14:19] <anne> Like I said, he seems like a sensible guy
  1795. # [14:19] <Grauw> anne, there’s hardly anything ‘uncommon’ left.
  1796. # [14:20] <anne> default presentation
  1797. # [14:20] <Grauw> mike, I think you were looking for is ‘bona fide’
  1798. # [14:20] <anne> contextmenu
  1799. # [14:21] <Grauw> anne, for mp3s with cover art in them, it shouldn’t show anything?
  1800. # [14:21] <anne> <audio>?
  1801. # [14:21] <Grauw> yes
  1802. # [14:21] <anne> dunno
  1803. # [14:22] <Grauw> well the current spec certainly prevents it from doing that if it says audio is not shown
  1804. # [14:22] <Grauw> and it’s not <video> either, so if a browser wants to do that, he’s proably going to create a new <audio-coverart> element
  1805. # [14:22] <Grauw> :)
  1806. # [14:23] <anne> or just <audio> + <img>
  1807. # [14:23] <Grauw> it’s embedded in many MP3s...
  1808. # [14:23] <anne> yeah, dunno what you'd want to do with it
  1809. # [14:24] <anne> how DVD like stuff would work is not entirely clear to me either for instance
  1810. # [14:24] <anne> the default presentation of <video> is pretty clear to me (without controls set)
  1811. # [14:24] <anne> with controls set i'm not so sure anymore
  1812. # [14:25] <anne> dunno about <audio>... display:none?
  1813. # [14:26] <Grauw> display should indeed be handled by CSS
  1814. # [14:26] <Grauw> audio without cover art will just get a (0,0) size
  1815. # [14:26] <Grauw> also, what about chapters. can you do <audio src="playlist.m3u">, etc, I think that’s useful
  1816. # [14:26] <MikeSmith> anne - yeah, geez, "bona fide"
  1817. # [14:26] * MikeSmith thinks the longer I'm in Japan the worse my English is getting
  1818. # [14:27] <anne> Grauw, you want to know upfront what the UI will be
  1819. # [14:27] <anne> as an author
  1820. # [14:27] * Grauw at international student house, so I talk more English than Japanese ;p
  1821. # [14:27] <MikeSmith> ボナファイド
  1822. # [14:27] <Grauw> they say that? :)
  1823. # [14:28] <Dashiva> More like pronounce it like that, I'm guessing
  1824. # [14:28] <MikeSmith> Grauw - somebody probably does
  1825. # [14:28] <Grauw> mike, ;p
  1826. # [14:28] <Grauw> anne, actually, I think it should default to having UI, be <object> (of course), and have an attribute/parameter that says noui="noui" or something with a better name
  1827. # [14:29] <Grauw> by the way, you don’t know the size of a <video> in advance either
  1828. # [14:30] <Grauw> mike, my dictionary says they say 誠実に :)
  1829. # [14:31] <anne> Grauw, you do
  1830. # [14:31] <Grauw> (せいじつに)
  1831. # [14:31] <anne> it's a replaced element so the default size will be 300*150 unless you specify something else through CSS
  1832. # [14:31] <Grauw> it doesn’t size to the video’s size by default?
  1833. # [14:31] <Grauw> ugh
  1834. # [14:31] <anne> the video size scales inside the frame created by CSS
  1835. # [14:31] * anne likes that approach
  1836. # [14:32] <MikeSmith> Grauw - I think probably you mean 誠実な
  1837. # [14:32] <Grauw> yes of course it scales :)
  1838. # [14:32] <Grauw> it says 誠実に adv. (Hira=せいじつに) faithfully, truly 誠実な adj. (Hira=せいじつな) faithful, credible
  1839. # [14:33] <Grauw> and bona fide only mentions the first
  1840. # [14:33] <Grauw> other than that, I know nothing, my Japanese is still terrible :)
  1841. # [14:33] <anne> "Video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the aspect ratio of the video, the video will be shown letterboxed. Areas of the element's playback area that do not contain the video
  1842. # [14:33] <anne> should be filled with pure black."
  1843. # [14:33] <Grauw> well I dislike it
  1844. # [14:34] <Grauw> <img> doesn’t have a default size either
  1845. # [14:34] <anne> it does
  1846. # [14:34] <anne> 300*150
  1847. # [14:34] <Grauw> yet nobody complains about the image size being unpredictable
  1848. # [14:34] * Joins: barstow (ce846302@128.30.52.23)
  1849. # [14:34] <hsivonen> Grauw: would you rather have the UA fetch the poster frame of the video before committing to the box size?
  1850. # [14:34] <anne> but it fall back to the intrinsic size of the image
  1851. # [14:34] <Grauw> anne, ke?
  1852. # [14:34] <anne> falls*
  1853. # [14:34] <Grauw> hsivonen: I want it to work like <img>
  1854. # [14:34] <anne> for instance, <img> loading SVG might fallback to 300*150
  1855. # [14:35] <Grauw> if you don’t want ugly reflows, just specify a size
  1856. # [14:35] <hsivonen> anne: where did those dimensions come from? is that what Opera/Gecko/WebKit implment?
  1857. # [14:35] <anne> hsivonen, that's what the defacto behavior is for <iframe> and therefore that's what CSS 2.1 specifies
  1858. # [14:36] <Grauw> a non-loaded <img> or an <img> that failed loading is certainly not 300x150
  1859. # [14:36] <hsivonen> anne: ok. there's so much stuff to learn
  1860. # [14:36] <anne> Grauw, in that case it no longer is a replaced element
  1861. # [14:36] <anne> Grauw, just a simple inline element
  1862. # [14:36] <Grauw> at the point before it is loaded?
  1863. # [14:37] * anne isn't entirely sure about that
  1864. # [14:37] <Grauw> well, it’s not in current implementations.
  1865. # [14:37] <anne> hsivonen, yeah, CSS is fricking complex
  1866. # [14:38] <anne> it's not what? (note that I'm not sure what the behavior should be in that case)
  1867. # [14:38] <anne> well, failed loading is clear
  1868. # [14:38] <anne> loading is not
  1869. # [14:39] <Grauw> if an image tag does not specify a size by means of the width and height attributes or CSS, the default size it occupies is either 0 or the size of a broken-image icon, I think
  1870. # [14:39] <hsivonen> AOL has joined, too
  1871. # [14:39] <anne> yeah, some time ago
  1872. # [14:40] <anne> well, March 28
  1873. # [14:41] <Grauw> anyway, I’m going to update my BIOS, and then retire for the evening
  1874. # [14:41] * Quits: Grauw (ask@202.71.92.74) (Quit: I bid y’all goodbye!)
  1875. # [14:48] * Joins: Lachy_ (Lachlan@124.168.25.222)
  1876. # [14:51] * Quits: Lachy (Lachlan@203.214.144.160) (Ping timeout)
  1877. # [15:05] <MikeSmith> anne - does the Wep Apps 1.0 spec cover something related to delayed script execution?
  1878. # [15:06] <Dashiva> it specifies defer and async properties
  1879. # [15:06] <MikeSmith> Dashiva - OK
  1880. # [15:06] * MikeSmith wonders what the origins of the spec for those is
  1881. # [15:08] <anne> async is new
  1882. # [15:08] <anne> defer is IE
  1883. # [15:08] <anne> iirc
  1884. # [15:08] <MikeSmith> what use case is behind the defer and async attributes?
  1885. # [15:09] <MikeSmith> and are the use cases documented anywhere? (the wiki?)
  1886. # [15:09] <anne> not delaying the parser
  1887. # [15:09] <anne> no, feel free to document usecases
  1888. # [15:09] <anne> WHATWG lacks such an effort atm
  1889. # [15:09] <anne> they're mostly documented on the list
  1890. # [15:11] <MikeSmith> anne - and what advantage is there to not delaying the parser? I mean in what cases is it more important/useful to not delay the parser?
  1891. # [15:11] <anne> "There are three possible modes that can be selected using these attributes. If the defer attribute is present, then the script is executed when the page has finished parsing. If the defer attribute is not present but the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If neither attribute is present, then the script is downloaded and executed immediately, before the user agent continues
  1892. # [15:11] <anne> parsing the page. The exact processing details for these attributes is described below."
  1893. # [15:12] <anne> I'm not entirely sure what the use case for async is, but defer is prolly to show the content first
  1894. # [15:12] <MikeSmith> yeah
  1895. # [15:12] <anne> oh actually
  1896. # [15:12] <anne> async helps with that too
  1897. # [15:12] <Dashiva> async is useful for library scripts and the such
  1898. # [15:13] <anne> nm my last remark
  1899. # [15:13] <anne> what does async help with in that case Dashiva?
  1900. # [15:13] <MikeSmith> Are there implementations already?
  1901. # [15:13] <Dashiva> They don't hold up the page parsing when downloading
  1902. # [15:13] <anne> IE implements defer
  1903. # [15:14] <anne> Dashiva, why not use defer?
  1904. # [15:14] <anne> but what IE does is different from the spec it seems
  1905. # [15:14] <Dashiva> There's no need to limit it to after page load
  1906. # [15:15] <MikeSmith> I think mobile browser (or browsers on "constrained devices") are an obvious use case for this.
  1907. # [15:15] <anne> that sounds like an argument to remove the feature MikeSmith :)
  1908. # [15:16] <MikeSmith> anne - ?
  1909. # [15:16] <anne> authors shouldn't be encouraged to create device specific pages
  1910. # [15:16] <MikeSmith> true
  1911. # [15:16] <MikeSmith> perhaps
  1912. # [15:16] <MikeSmith> or perhaps not
  1913. # [15:16] <MikeSmith> depending on who you talk to
  1914. # [15:17] <MikeSmith> anyway, I think it can create implementation issues and bugs because of complexities with CSS interaction
  1915. # [15:17] <MikeSmith> maybe
  1916. # [15:18] <Dashiva> One of the open issues with async is that you don't know if the script will run before or after load
  1917. # [15:18] <MikeSmith> but I guess that's neither here not there
  1918. # [15:26] <anne> i have no idea how it will effect CSS actually
  1919. # [15:35] * Quits: barstow (ce846302@128.30.52.23) (Quit: CGI:IRC (EOF))
  1920. # [15:45] * Joins: asbjornu (asbjorn@84.48.116.134)
  1921. # [16:13] * Joins: alexf (alejandro@85.152.42.1)
  1922. # [16:28] * Joins: glazou (daniel@80.118.184.70)
  1923. # [16:28] <glazou> hello
  1924. # [16:28] <glazou> anne: ping
  1925. # [16:28] <anne> pong
  1926. # [16:28] <anne> and hi!
  1927. # [16:29] <glazou> anne: hi ; suppose you have a document with CSS styles for 'projection' medium. Should a browser fullscreen mode automatically enable them or ask the user and what does Opera about it ?
  1928. # [16:29] <anne> opera automatically applies projection in F11
  1929. # [16:30] <glazou> hmmm
  1930. # [16:30] <glazou> is opera the only browser enabling projection medium ATM ?
  1931. # [16:30] <anne> There've been some ideas floating around of making a "complicated" UI but I don't think anybody got around doing that
  1932. # [16:30] <anne> glazou, yes
  1933. # [16:30] <glazou> thanks anne
  1934. # [16:30] <glazou> anne: see my blog, last post
  1935. # [16:30] <glazou> firefox
  1936. # [16:32] <anne> cool
  1937. # [16:32] * glazou needs to read about opera slides
  1938. # [16:32] <glazou> do you happen to have a url about it handy ?
  1939. # [16:33] <glazou> opera show
  1940. # [16:33] <anne> http://www.opera.com/support/tutorials/operashow/
  1941. # [16:33] <anne> maybe?
  1942. # [16:33] <glazou> thx
  1943. # [16:35] <glazou> oh so it's based purely on css-generated page breaks, very cool
  1944. # [16:35] <anne> yeah
  1945. # [16:35] <anne> we call it "Opera Show" but it's just CSS :)
  1946. # [16:35] * glazou going to beat it
  1947. # [16:36] <glazou> :)
  1948. # [16:36] <hsivonen> glazou: have you got projection page breaks working in Gecko?
  1949. # [16:36] <glazou> no
  1950. # [16:36] <glazou> well not yet
  1951. # [16:37] <hsivonen> having those would be awesome
  1952. # [16:37] <glazou> but that's not really an issue
  1953. # [16:37] <glazou> yes
  1954. # [16:37] <glazou> would help, but again, I know how to do "Firefox Show" without
  1955. # [16:38] <glazou> in fact Opera show is not really a slideshow system, it's only a paginated mode w/o scrollbar
  1956. # [16:38] <glazou> I'll do a real slideshow system
  1957. # [16:38] <hsivonen> what do you mean by "real" compared to Opera?
  1958. # [16:39] <glazou> where a slide can contain transitions between components ? render one LI at a time ?
  1959. # [16:39] <hsivonen> I see
  1960. # [16:39] <anne> implementing css3-preslev ?
  1961. # [16:39] <anne> ( http://www.w3.org/TR/css3-preslev/ )
  1962. # [16:40] <glazou> not yet, but thinking about it, yes
  1963. # [16:54] * Yudai is now known as colon_equal
  1964. # [17:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
  1965. # [17:14] * Quits: glazou (daniel@80.118.184.70) (Quit: away)
  1966. # [17:17] * colon_equal is now known as Yudai
  1967. # [17:18] * Joins: h3h (bfults@66.162.32.234)
  1968. # [17:19] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
  1969. # [17:53] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
  1970. # [18:01] * Parts: alexf (alejandro@85.152.42.1)
  1971. # [18:01] * Joins: anne (annevk@86.90.70.28)
  1972. # [18:56] * Joins: tylerr (tylerr@66.195.32.2)
  1973. # [18:57] <tylerr> Good day all.
  1974. # [18:57] * Joins: myakura (myakura@60.239.122.32)
  1975. # [19:03] <zcorpan_> g'day
  1976. # [19:04] <anne> it certainly is here
  1977. # [19:05] * Joins: hober (ted@66.162.32.234)
  1978. # [19:06] <zcorpan_> anne: what is?
  1979. # [19:06] * Joins: dbaron (dbaron@63.245.220.242)
  1980. # [19:07] <anne> a good day
  1981. # [19:07] <zcorpan_> ah
  1982. # [19:08] <tylerr> Ah hello anne. How did the discussion wrap up earlier?
  1983. # [19:09] <anne> subject was?
  1984. # [19:10] <tylerr> All the tag talk about <i>'s and <image> and whatnot.
  1985. # [19:14] <tylerr> When I left it was a rather interesting discussion.
  1986. # [19:15] <tylerr> Then again, all the discussions on here are rather interesting. :-)
  1987. # [19:16] * Parts: hasather (hasather@81.235.209.174)
  1988. # [19:21] * Joins: st (st@62.234.155.214)
  1989. # [19:38] * Joins: kingryan (kingryan@66.92.187.33)
  1990. # [19:42] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
  1991. # [20:12] <anne> Microsoft joined
  1992. # [20:12] <anne> Chris Wilson is their only participant so far
  1993. # [20:12] <zcorpan_> finally!
  1994. # [20:13] <h3h> hooray
  1995. # [20:13] <Dashiva> huzzah
  1996. # [20:13] <hsivonen> hooray!
  1997. # [20:13] <hsivonen> http://lists.w3.org/Archives/Public/www-forms/2007Apr/0006.html
  1998. # [20:14] <anne> http://www.w3.org/mid/5C276AFCCD083E4F94BD5C2DA883F05A27946E6FA5@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com
  1999. # [20:17] * Joins: hasather (hasather@81.235.209.174)
  2000. # [20:20] <tylerr> Woo.
  2001. # [20:21] <anne> hsivonen, seems like versioning for the sake of it
  2002. # [20:21] <anne> not really thought through
  2003. # [20:22] <zcorpan_> versioning is the killer feature
  2004. # [20:22] <zcorpan_> :)
  2005. # [20:23] <Dashiva> Next we'll be versioning language in school
  2006. # [20:23] <Dashiva> <report version="2007-urban-slang">
  2007. # [20:23] <zcorpan_> perhaps language tags should have a version parameter
  2008. # [20:24] <zcorpan_> lang="en-GB;version=2.0"
  2009. # [20:24] <anne> perhaps element names should have a version parameter
  2010. # [20:24] <anne> <tag;2>
  2011. # [20:24] <Dashiva> A version parameter in img would work for adding fallback :)
  2012. # [20:25] <zcorpan_> that would be so cool
  2013. # [20:25] <anne> can't believe nobody thought of that!
  2014. # [20:25] <DanC> From: Chris Wilson <Chris.Wilson@microsoft.com>
  2015. # [20:25] <DanC> To: public-html@w3.org <public-html@w3.org>
  2016. # [20:25] <DanC> Subject: Microsoft has now joined the HTML Working Group
  2017. # [20:25] <DanC> Date: Wed, 4 Apr 2007 11:15:50 -0700 (13:15 CDT)
  2018. # [20:25] * Parts: asbjornu (asbjorn@84.48.116.134)
  2019. # [20:25] <anne> DanC, see above :)
  2020. # [20:25] * DanC is late to the party again. oh weel.
  2021. # [20:25] <Dashiva> So, what's the first post on the program now?
  2022. # [20:26] <anne> your announcement prolly wins in geekiness
  2023. # [20:26] <DanC> the list of issues I'm swapped in on is still http://www.w3.org/html/wg/il16
  2024. # [20:26] <DanC> I haven't even read Chris W's msg yet. and I have another appointment just nwo.
  2025. # [20:27] <DanC> it's with my typing tutor.
  2026. # [20:27] <DanC> ;-)
  2027. # [20:27] <hsivonen> DanC: will the WG now proceed to discuss the issue whether to take the HTML5+Hixie package? or are we still waiting for e.g. IBM or Adobe to join?
  2028. # [20:27] <anne> woha, Chris wants versioning
  2029. # [20:27] <DanC> the WG has been discussing that for a while; the question is when we'll stop discussing and call the question
  2030. # [20:27] * anne ponders about the role of a co-chair
  2031. # [20:28] <hsivonen> anne: whoa about versioning indeed
  2032. # [20:29] <Dashiva> Technically, as long as we have backwards compatability as a leading star, shouldn't every document should be eligible for validation/conformance checking based on the latest standard?
  2033. # [20:29] <hsivonen> Dashiva: yes
  2034. # [20:29] <hsivonen> Dashiva: but HTML5 does break conformance compat with HTML 4
  2035. # [20:30] <hsivonen> Dashiva: basically %Flow becomes bimorphic
  2036. # [20:31] <Dashiva> Will that invalidate pages?
  2037. # [20:31] <hsivonen> Dashiva: yes
  2038. # [20:32] <tylerr> So are we talking about an agile method of moving HTML forward, with the "release early, release often" mentality? I mean, release HTML 4.1 then a few months later have 4.2 come out? I'm a bit unclear about the versioning.
  2039. # [20:33] <Dashiva> Well, some browsers are implementing parts of HTML5 even now, so you could say they are at various stages of HTML 4.x
  2040. # [20:34] <Dashiva> But it's not a well-defined progression of features, just pick-and-choose
  2041. # [20:34] <tylerr> Sure, it's like a grab-bag at this point.
  2042. # [20:34] <Philip> Dashiva: It sounds like there's a difference between versioning for conformance checking, and versioning to implement "don't break the web" like in quirks/standards mode - in the latter case, you can't really add new features without breaking existing pages (when they happen to (invalidly, mistakenly) use the new tag name)
  2043. # [20:35] <gavin_> anne, hsivonen: his email makes it sound like he's talking about versinoing the spec, not versioning documents
  2044. # [20:35] <anne> tylerr, not just at this point
  2045. # [20:35] <Dashiva> Philip: I think there's an implicit "don't break [more than 0.001% of] the web"
  2046. # [20:35] <anne> tylerr, on the web incremental evolution is sort of a constant
  2047. # [20:35] <zcorpan_> gavin_: that's how i read it too
  2048. # [20:36] <gavin_> anne: (given the quoted message he's replying to)
  2049. # [20:36] <tylerr> anne: Oh sure! I'm just wondering then what Chris means by versioning.
  2050. # [20:36] <anne> hmm, ok
  2051. # [20:36] * hsivonen is eagerly waiting to see what Chris replies to the messages about adopting the XBL2 spec editing model
  2052. # [20:36] <anne> then I'm confused as to why he mentioned Firefox development cycles
  2053. # [20:37] * zcorpan_ too
  2054. # [20:37] <tylerr> So then do we have a HTML 4.1 that only adds new elements, keeps all the current ones, then slowly start to depricate while introducing replacements?
  2055. # [20:37] <gavin_> anne: as an example of why giving the spec a verisino would be useful, I'm guessing
  2056. # [20:37] <gavin_> i.e. the ability to say "Firefox X supports HTML Y"
  2057. # [20:37] <anne> tylerr, introducing replacements?
  2058. # [20:38] <anne> tylerr, we're fixing the web here, not replacing it
  2059. # [20:38] * tylerr chuckles.
  2060. # [20:38] <Philip> Dashiva: That seems reasonable for the latter case. The former (versioning for conformance checking) seems to be of less practical relevance, given that most HTML4 pages aren't valid, so it doesn't matter whether they'll be valid HTML5 or not
  2061. # [20:39] <tylerr> I should have worded it as "fixes" then. Replacement does have a feeling of finality to it anne. :-)
  2062. # [20:39] <Philip> and I'd guess (with no reasonable basis) Chris was talking about the don't-break-existing-invalid-pages versioning, so the arguments about versioning for conformance checking are not as relevant
  2063. # [20:39] <tylerr> Sure.
  2064. # [20:39] <anne> 95% of the HTML pages are syntactically incorrect. I doubt as much as a percent is actually conforming.
  2065. # [20:39] <Philip> Which may all be obvious and/or wrong, but I was just trying to work out what I was thinking of :-)
  2066. # [20:40] <tylerr> anne: We can blame that on WYSIWYG. :-)
  2067. # [20:40] <tylerr> And poor editors.
  2068. # [20:41] <anne> and hand authoring
  2069. # [20:41] <zcorpan_> and misguided tutorials
  2070. # [20:41] <anne> basically, we can blame the people
  2071. # [20:41] <Dashiva> anne: Well, after the half a million test cases we have to write, it'll be a bit closer to one percent at least :)
  2072. # [20:42] <zcorpan_> lol
  2073. # [20:42] * anne almost never writes conforming testcase documents
  2074. # [20:42] <zcorpan_> you'd have to write a billion test cases to come closer to 1%
  2075. # [20:42] * Joins: mjs (mjs@64.81.48.145)
  2076. # [20:47] <Philip> I've found the best way to create lots of test cases is to write a program which runs through every combination of multiple inputs and generates a test case for each. Thanks to the power of combinatorics, you can just add a couple more inputs each time the web gets an order of magnitude larger, in order to keep up.
  2077. # [20:50] * anne writes them by hand mostly so he can easily tweak them
  2078. # [20:52] <mjs> the tool will rarely be able to predict the correct output for each test case though
  2079. # [20:53] <anne> we did make a specialized format for the parsing testcases
  2080. # [20:53] <anne> where "we" is Hixie who contributed it
  2081. # [20:53] <Philip> If the spec is sufficiently detailed and inflexible, you could write a perfect reference implementation and use that to calculate the correct output
  2082. # [20:54] <anne> http://html5lib.googlecode.com/svn/trunk/tests/tree-construction/tests1.dat
  2083. # [20:54] <anne> etc.
  2084. # [20:54] <Philip> and once you have one small part of the spec which is like that, you can make a billion test cases for that area :-)
  2085. # [20:55] <Philip> (But it's not so good for covering the rest of the spec where it's fluffier, I guess)
  2086. # [20:55] <anne> the spec shouldn't be "fluffy"
  2087. # [20:55] <anne> except maybe about semantics, which you can't really test anyway
  2088. # [20:56] <anne> Microsoft also nominated Miller Abel
  2089. # [20:56] <zcorpan_> Philip: the problem is the reference implementation would most likely also have bugs :)
  2090. # [20:57] <kingryan> Philip: there's no way to assert that a reference implementation is complete and bug free without a test suite (IMO)
  2091. # [20:58] <anne> (a test suite can also contains bugs, fwiw)
  2092. # [20:58] <anne> we should now have a circle
  2093. # [20:58] <mjs> XPointer as an alternative to BLOCKQUOTE, what a great idea
  2094. # [20:58] <zcorpan_> and a spec can contain bugs...
  2095. # [20:58] <anne> right, we missed that one :)
  2096. # [20:59] <anne> mjs, there's something about X that solves all your problems
  2097. # [20:59] <mjs> Philip: if it were that easy to write a perfect reference implementation of the spec, there would be no need for a test suite
  2098. # [21:01] <mjs> ooh, Chris Wilson is on the list, I'd better hurry
  2099. # [21:01] <Philip> anne: Hmm, I suppose all the "should" statements could be considered fluffy - but WA1 has far more "must"s than "should"s, so actually it seems like a lot can be relatively easily tested
  2100. # [21:02] <anne> Philip, all the authoring should are fluffy, but they're related to authoring so can be safely ignored unless you're making testcases for a conformance checker
  2101. # [21:02] <anne> Philip, UA SHOULD requirements are mostly things related to network access and security iirc
  2102. # [21:02] <anne> of which you can safely test the latter
  2103. # [21:04] <anne> "274 group participants"
  2104. # [21:09] <Philip> I noticed http://www.w3.org/TR/grddl/ has mechanical rules - if they were normative, and if the language they're written in has formally defined semantics, then the spec would effectively be the reference implementation, and it would be perfectly self-consistent, and you could define away any bugs because they're really just features
  2105. # [21:09] <Philip> then a test suite would still be useful to compare the output from optimised implementations
  2106. # [21:10] <Philip> But that's sounding like crazy formal semantics that doesn't really scale to work in the real world :-)
  2107. # [21:11] <anne> if you invent some script that deals en-GB-x-Hixie it might
  2108. # [21:11] <anne> deals with*
  2109. # [21:25] <mjs> is it just me, or is Chris Wilson's mail client sending things in weird fonts?
  2110. # [21:25] <anne> Comic Sans?
  2111. # [21:25] * anne only receives HTML e-mail
  2112. # [21:25] <anne> euh, text e-mail*
  2113. # [21:27] <hsivonen> I'm getting what looks like Courier New in Mail.app
  2114. # [21:28] <hsivonen> the last message that is
  2115. # [21:28] <hsivonen> the earlier ones looked normal
  2116. # [21:29] * DanC is away: eye Dr. etc.
  2117. # [21:31] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
  2118. # [21:46] * anne just hears he's free to do something besides work tomorrow, the day after and Monday!
  2119. # [21:48] * Joins: heycam (cam@203.214.79.176)
  2120. # [21:48] <hsivonen> is Maundy Thursday a non-work day in Norway?
  2121. # [21:48] <anne> for Opera, it is
  2122. # [21:48] <mjs> hsivonen: two of his messages came out in a funny font (the most recent was Courier New and the text didn't wrap)
  2123. # [21:49] <Hixie> mmm, microsoft wants versioning
  2124. # [21:49] <mjs> Chris Wilson asked for it, but I'm not sure he's read through the discussions that led to a conclusion of no versioning
  2125. # [21:50] <mjs> I thought versioning was a good idea too when less informed
  2126. # [21:50] <Hixie> sadly, he's our chair, so it might be necessary to convince him
  2127. # [21:51] <Hixie> i like the way people assume that "content sniffing" is a single feature
  2128. # [21:51] <Dashiva> Did you see the rumor about you in #whatwg, Hixie?
  2129. # [21:51] <Hixie> as opposed to a different one for each time it happens, in <img>, in <style>, in <script>, in a browsing context, in an <object>, when downloading, etc
  2130. # [21:52] <Hixie> Dashiva: rumous?
  2131. # [21:52] <Hixie> rumour, even?
  2132. # [21:52] <Dashiva> * Dorward hears a rumour that Hixie is pushing for clients to be allowed to treat text/plain documents as HTML and points out that when Safari did that to http://www.hixie.ch/advocacy/xhtml it became rather difficult to read.
  2133. # [21:52] <Hixie> given that the html5 spec right now specifically disallows treating text/plain as text/html...
  2134. # [21:52] <mjs> I think Hixie specifically didn't push for that
  2135. # [21:53] <mjs> it's true that content sniffing is different in different cases
  2136. # [21:53] <Dashiva> Yeah, I think it's a misunderstanding based on image/* sniffing. But rumors rarely care about fact
  2137. # [21:53] <mjs> binary formats are unambiguously self-describing, so being strict about the type for those is of dubious value
  2138. # [21:54] <anne> especially since authors get it wrong
  2139. # [21:54] <Hixie> some binary formats are unambiguously self-describing
  2140. # [21:54] <Hixie> not all
  2141. # [21:54] <mjs> s/are/are often/
  2142. # [21:54] <Hixie> yeah
  2143. # [21:54] <Hixie> some text formats are too
  2144. # [21:54] <Hixie> PDF, e.g.
  2145. # [21:54] <Hixie> er
  2146. # [21:54] <Hixie> PS, rather
  2147. # [21:55] <anne> am I posting in the past or are other people posting in the future?
  2148. # [21:55] <Hixie> JPEG/JFIF is hard to detect, you only really have three bytes to go on
  2149. # [21:56] <mjs> is it feasible to do a study of how many text/plain documents there are on the web that appear to be HTML by sniffing, and whether it appears those expect to be rendered as HTML or plain text?
  2150. # [21:56] <mjs> I honestly don't know
  2151. # [21:56] <mjs> we added the sniffing for that to Safari a long time ago when we found some sites that broke if you treated plain text strictly, but I don't know what those were and whether that is still common, and now we are scared to change it
  2152. # [21:57] <anne> IE doesn't seem to trigger HTML rendering mode for http://www.hixie.ch/advocacy/xhtml
  2153. # [21:57] <anne> HTML parsing, even
  2154. # [21:57] <Hixie> i can tell you how many text/plain documents google thinks are html, but that tells you more about google than text/plain or HTML
  2155. # [21:57] <Hixie> IE can be tricked into treating text/plain as HTML
  2156. # [21:57] <Hixie> it just takes more than the xhtml page
  2157. # [21:58] <mjs> it would probably require some individual inspection of some of those pages to determine author intent
  2158. # [21:58] <Hixie> http://www.hixie.ch/tests/adhoc/http/content-type/014.html e.g.
  2159. # [21:58] <Hixie> mjs: yeah
  2160. # [21:58] <mjs> but knowing number and surveying a subset by hand would be useful, at least to me
  2161. # [21:58] <Hixie> mjs: firefox never treats text/plain as HTML and has to my knowledge never had much of a problem with it
  2162. # [21:58] <Hixie> mjs: text/plain has to be sniffed for binary content, though, and the HTML5 spec says how to do that
  2163. # [21:59] <Hixie> mjs: remind me when i'm in the office
  2164. # [22:00] <mjs> Hixie: I'm not particularly resolute against changing it, but it's very hard for me to get the data to justify it myself; Firefox not doing it is a fairly strong point
  2165. # [22:00] <mjs> we also do sniffing for RSS, but not sure if that is directly relevant to the HTML spec
  2166. # [22:01] <anne> I think that's covered
  2167. # [22:01] <anne> Opera doesn't seem to treat 014.html as HTML either
  2168. # [22:01] <mjs> It's pretty much impossible to find an RSS feed with a MIME type of application/rss+xml or application/x-rss+xml or whatever
  2169. # [22:01] <Hixie> mjs: sniffing for RSS is already required by HTML5 :-)
  2170. # [22:02] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#content-type3
  2171. # [22:02] <anne> http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing
  2172. # [22:05] <Hixie> the warning given at the top of that section is not hypothetical, btw
  2173. # [22:05] <Hixie> it is possible to trick IE into thinking certain files are HTML, which is actually an XSS hole in many, many web sites
  2174. # [22:05] <Hixie> today
  2175. # [22:06] <mjs> our security guys have raised issues about sniffing for html in text/plain before
  2176. # [22:08] <gavin_> I don't think "Microsoft wants versining" is the right conlusion to make given Chris' email
  2177. # [22:08] <gavin_> it looks to me like there's confusion as to what "versining" means
  2178. # [22:08] * gavin_ wonders how he managed to typo "versioning" twice
  2179. # [22:08] <tylerr> I'd say there is some clarification needed.
  2180. # [22:08] <Dashiva> Now there's confusing about versining too
  2181. # [22:08] <tylerr> gavin_: Improper versioning. ;-)
  2182. # [22:09] <gavin_> the email he was replying to was talking about giving the spec a version
  2183. # [22:09] <gavin_> not about requiring that documents indicate their versions
  2184. # [22:09] <hsivonen> the spec has an SVN revision id. :-)
  2185. # [22:09] <anne> yet he also mentioned he disagreed with the design principle
  2186. # [22:11] <gavin_> maybe he just disagrees with what he believes it the design principle after reading the unrealted talk about what to call the spec :)
  2187. # [22:11] <gavin_> I hope so, anyways
  2188. # [22:11] * gavin_ hopes people will forgive his SSH-lag induced typos
  2189. # [22:12] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  2190. # [22:13] <Philip> I thought there was some discussion a while ago (in "Using the HTML5 DOCTYPE as a new quirksmode switch") when he had asked for something that sounds (to me) like a form of document versioning
  2191. # [22:14] <Philip> (so I assume the discussion there, rather than on the HTML WG list, is more relevant)
  2192. # [22:28] * Quits: loic (loic@90.29.147.122) (Quit: hoopa rules)
  2193. # [22:29] * Joins: asbjornu (asbjorn@84.48.116.134)
  2194. # [22:36] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
  2195. # [22:42] * h3h wishes Chris Wilson would send email as plaintext. that MS Word MIME stuff is horrid
  2196. # [22:43] * hober should really get around to figuring out how to tell gmail to prefer text/plain alternatives
  2197. # [22:43] <tylerr> That's Outlook for you h3h. :-(
  2198. # [22:43] <h3h> You can even tell Outlook to use plain text
  2199. # [22:44] * Parts: asbjornu (asbjorn@84.48.116.134)
  2200. # [22:46] * anne only receives text in Opera
  2201. # [22:58] * zcorpan_ would prefer text for emails, but html for feeds. unfortunately opera has the same setting for both at the same time
  2202. # [22:58] * anne uses bloglines.com for feeds atm
  2203. # [22:59] <zcorpan_> opera is by far the best feed reader i've used
  2204. # [23:01] <tylerr> I enjoy Google Reader, but that's because I haven't tried Opera's.
  2205. # [23:04] <zcorpan_> to read feeds, all i have to do is keep hitting space. pretty much like email. very convenient
  2206. # [23:06] <hasather> zcorpan_: same in Google Reader too. I use that so that I can read feeds on different devices
  2207. # [23:07] <zcorpan_> ok
  2208. # [23:10] <tylerr> How does Reader do on mobiles?
  2209. # [23:10] <hasather> there is a mobile version
  2210. # [23:11] <hasather> http://reader.google.com/m
  2211. # [23:11] <tylerr> Ah well, that would help if I searched beyond my own nose. :-)
  2212. # [23:11] <tylerr> Thanks.
  2213. # [23:11] <hasather> no, hmm, was that really it?
  2214. # [23:12] <tylerr> Oh wait, that's Google's search page it seems.
  2215. # [23:12] <hasather> http://www.google.com/reader/m/view/
  2216. # [23:12] <hasather> there it is
  2217. # [23:12] <tylerr> Ah brilliant!
  2218. # [23:21] * Joins: heycam (cam@203.214.79.176)
  2219. # [23:23] * DanC is away: done for the day
  2220. # [23:36] * Joins: mw (chatzilla@84.41.169.151)
  2221. # [23:40] * Quits: mw (chatzilla@84.41.169.151) (Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1/2007011111])
  2222. # [23:40] * Joins: mw_ (chatzilla@84.41.169.151)
  2223. # [23:40] * mw_ is now known as mw
  2224. # [23:43] * mw is now known as mw22
  2225. # Session Close: Thu Apr 05 00:00:00 2007

The end :)