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

Options:

1. # Session Start: Sat Apr 28 00:00:00 2007
2. # Session Ident: #html-wg
3. # [00:02] <schepers_> mjs: so, was that an ultimatum or not?
4. # [00:03] <mjs> schepers_: statement of fact
5. # [00:03] * schepers_ is now known as schepers
6. # [00:04] <schepers> that wasn't my question
7. # [00:04] <schepers> if it's an ultimatum, I want to know what the terms are
8. # [00:05] <schepers> so I can decide if it's worth my time to try to have input into the process
9. # [00:05] <mjs> my understanding of "ultimatum" is that it takes the form "you must do X or else I/we will do Y"
10. # [00:06] <schepers> right
11. # [00:06] <mjs> what I said was, basically, "if you try to make browser vendors do something that they are fundamentally unwilling to, then they won't implement the spec"
12. # [00:06] <Hixie> which is always the case, for any spec, of course
13. # [00:06] <mjs> I suppose you could squeeze that into the ultimatum template if you want
14. # [00:06] <Hixie> whether they say it or not :-)
15. # [00:07] <mjs> but I just think it is an obvious statement of fact
16. # [00:07] <mjs> there's also the ancillary statement that I believe non-Microsoft vendors are unwilling to make HTML5 a separate mode, and all vendors are unwilling to stop processing current web documents
17. # [00:08] <mjs> there's probably other things browser vendors are completely unwilling to do, like implement something that compromises security
18. # [00:09] <mjs> that doesn't mean anyone would quit the group over such a thing, necessarily, but it probably will make them not comply with anything in the spec to the contrary
19. # [00:09] <schepers> coyness aside, are you fundamentally unwilling to implement a separate HTML5.0 mode (albeit one that is strongly similar to earlier versions)?
20. # [00:09] <mjs> I think I just said that, and I don't think I was coy about it
21. # [00:10] <mjs> being strongly similar is not necessarily helpful
22. # [00:10] <schepers> separating the statement into 2 long, highly qualified sentences qualifies as coy in my book
23. # [00:10] <mjs> if it has a different parser, a different set of tags, a different set of supported attributes on each tag, and different DOM interfaces, then code reuse becomes very difficult
24. # [00:10] <h3h> seems to have worked the 2nd time: http://lists.w3.org/Archives/Public/public-html/2007Apr/1613.html
25. # [00:11] <mjs> part of one of my sentences was "I believe non-Microsoft vendors are unwilling to make HTML5 a separate mode"
26. # [00:12] <schepers> then I guess there's not much room for "compromise"
27. # [00:12] <schepers> good to know
28. # [00:12] <Hixie> sure, i don't think there's any room to compromise on that
29. # [00:12] <Hixie> i mean, that's why we started the whatwg
30. # [00:12] <mjs> there's room to compromise on all sorts of other things besides compatibility
31. # [00:12] <schepers> this isn't the whatwg... or at least, it wasn't
32. # [00:13] <Hixie> precisely because we didn't want to compromise on that and w3c said they weren't willing to accept that at the compounds document workshop
33. # [00:13] <Hixie> schepers: sure, but the browser vendors gave up on xhtml2 and went to whatwg precisely because of this
34. # [00:13] <mjs> and there's all sorts of ways to limit the added complexity authors must face due to compatibility constraints
35. # [00:14] <Hixie> schepers: so if the same thing happens again here (i.e. w3c requires browser vendors to compromise on what they don't want to compromise on), then the same thing would happen again
36. # [00:14] <Hixie> they'd form the "whenwg" or whatever
37. # [00:14] <Hixie> or go back to the whatwg
38. # [00:14] <mjs> sadly, there's no way to limit the added complexity browser vendors must face due to compatibility constraints, but that is true no matter what the spec says
39. # [00:14] <schepers> yep, this is all sounding like "ultimatum"
40. # [00:14] <gavin> it's sounding like "prediction based on previous events", to me
41. # [00:14] <schepers> it would be nice if this were clearly stated on the list, to stop wasting everyone's time
42. # [00:15] <Hixie> you can call it an ultimatum if you like
43. # [00:15] <h3h> sounds like "ultimatum that should be painfully obviously necessary" to me
44. # [00:15] <Hixie> i don't really see what difference it makes what you call it :-)
45. # [00:15] <Dashiva> It's an ultimatum in the same line as "If the spec tells people they aren't allowed to breathe oxygen, they aren't going to follow it"
46. # [00:15] <h3h> I think my latest reply makes it quite clear
47. # [00:15] <h3h> as does Maciej's
48. # [00:16] <Hixie> as dashiva says, there are certain things that it makes no sense to compromise on
49. # [00:17] <schepers> to you
50. # [00:17] <Hixie> yes
51. # [00:17] <schepers> but you're not big on compromise anyway, be frank
52. # [00:17] <Hixie> i'm sure there are things that you would never compromise on too
53. # [00:18] <h3h> I'd be extremely interested in hearing a coherent argument against supporting current web content
54. # [00:18] <Hixie> uh
55. # [00:18] <h3h> I just can't even begin to understand the rationale behind that
56. # [00:18] <mjs> Hixie isn't even employed by a browser vendor, currently
57. # [00:18] <mjs> so we're not even talking about him
58. # [00:18] <h3h> it's like designing a new car that can't use rubber tires
59. # [00:18] <mjs> except I guess indirectly, in that he'd rather not work on a spec that browsers won't implement
60. # [00:19] <schepers> I guess him being the editor doesn't bear on the conversation
61. # [00:19] * Hixie is very confused about why schepers thinks he doesn't compromise, given the weight of evidence against this in, e.g., the whatwg specs
62. # [00:19] <schepers> I can only speak from my own experience
63. # [00:20] <schepers> anyway, dinner time
64. # [00:20] <schepers> later
65. # [00:21] <Dashiva> It might be fruitful if someone made a post about the difference between a web application and a "regular" application
66. # [00:21] <h3h> why?
67. # [00:21] <Dashiva> I noticed someone was comparing them earlier
68. # [00:21] <Zeros> Dashiva, define regular first
69. # [00:22] <h3h> desktop app?
70. # [00:22] <gavin> first, I think we need to define "define"
71. # [00:22] <Dashiva> "I come from a computer programming point of view. Write incorrect code - program stops."
72. # [00:23] <Zeros> Dashiva, some of that POV has merit, but HTML isn't really executable code, its a document format.
73. # [00:23] <Dashiva> That might work if HTML pages were compiled and then distributed, but they aren't
74. # [00:23] <h3h> heh
75. # [00:23] <Hixie> better tell that to the gcc and msvc++ implementors, given how many times those compilers have had modes added to handle backwards-compatibility issues with earlier bugs
76. # [00:23] <h3h> I don't see how that connects to web apps vs. "regular" apps
77. # [00:24] <h3h> but yeah, look at how many programmers are in the world vs. how many web content authors
78. # [00:24] <Zeros> Dashiva, even then. Music players work around malformed mp3s, Word will load damaged document files, documents are different than executable code. Malformed documents don't usually imply "stop" behavior.
79. # [00:24] <h3h> it becomes terribly clear why HTML can't be handled with strict compile errors when there are implemented alternatives that are forgiving
80. # [00:24] <Hixie> it's a broken argument. Just look at the number of Win32 programs that mis-use Win32 APIs
81. # [00:24] <Hixie> forcing the Win32 API to retain backwards compatibility
82. # [00:25] <Hixie> microsoft bends over backwards to support old applications
83. # [00:25] <Hixie> yeah
84. # [00:25] <Hixie> what y'all are saying :-)
85. # [00:26] <mjs> strictness faced by the developer only can be a good thing for programming environments
86. # [00:26] <mjs> strictness faced by the end user is not
87. # [00:26] * h3h is baffled by this opposite anti-backwards-compatibility thread after Microsoft's lengthy pledge for its explicit support
88. # [00:26] <h3h> (and everyone else's)
89. # [00:26] <h3h> anyway, I'm out for now.
90. # [00:26] <Zeros> h3h, oh but you see, someone reworded the design principals and now that everyone /understands/ they don't agree anymore :P
91. # [00:27] <h3h> :)
92. # [00:27] * Quits: h3h (bfults@66.162.32.234) (Connection reset by peer)
93. # [00:27] <mjs> making HTML more strict is more like making the C standard library less fault tolerant than like fixing compiler bugs
94. # [00:27] <mjs> since it breaks already deployed content
95. # [00:27] <mjs> Zeros: well, I'm glad the lack of agreement is clear at least
96. # [00:27] <Zeros> yeah
97. # [00:27] <Dashiva> I wonder if there's going to be a similar thread about refusing to support un-semantic pages
98. # [00:28] <Hixie> the weird thing about the semantic debate is there are so many camps
99. # [00:29] <mjs> someone should get the microformats people in there
100. # [00:29] <mjs> just to add more camps
101. # [00:30] <Zeros> Might as well get the anti-microformats people too then
102. # [00:31] <mjs> and RDF/a
103. # [00:32] <mjs> can we solve the semantic issues with <i> by adding appropriate RDF/a markup?
104. # [00:32] <mjs> discuss
105. # [00:33] * Dashiva sobs
106. # [00:33] <Dashiva> I must admit I never understood how RDF would manage to agree on which names applied to what
107. # [00:35] * DanC tunes in... sorta...
108. # [00:35] <DanC> microformats? what about them?
109. # [00:36] <DanC> and as to "support existing content", mjs, let's not resort to +1 messages nor popularity contests. It might be worth beefing up the argument a bit, but it's a big reason why I'm here too.
110. # [00:37] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
111. # [00:38] <Dashiva> I can't make the numbers on the latest straw poll add up. 43 listed as non-responders, with 28 answers. Membership says 379 participants.
112. # [00:39] <mjs> DanC: well, Doug specifically asked for the general feeling in the group, and whether there was a large camp that agreed with him in opposing compatibility
113. # [00:39] <mjs> I'd like to know too
114. # [00:40] <DanC> asking for the general feeling of the group is (a) akward to do by email
115. # [00:40] <DanC> and (b) people aren't obliged to answer. _maybe_ the chair can oblige them to answer, but even then, only by formally putting the question
116. # [00:41] <DanC> Dashiva, I think that non-responders list is buggy
117. # [00:42] * Joins: gavin_ (gavin@74.103.208.221)
118. # [00:42] <DanC> mjs, while everybody in the group is welcome to participate in the review of the design principles, I'm mainly looking to you and the 2 reviewers to lead the discussion.
119. # [00:42] <DanC> I perhaps should have picked more diverse reviewers, but still.
120. # [00:43] <DanC> was shepers one of the reviewers?
121. # [00:43] <mjs> yes
122. # [00:43] <Hixie> schepers and myself, i believe. you probably couldn't pick more diverse reviewers :-)
123. # [00:43] <DanC> ah.
124. # [00:43] <DanC> so I did pick diverse reviewers. good for me ;-)
125. # [00:43] <mjs> diversity of reviewers: achieved
126. # [00:44] <mjs> Doug hasn't really given a formal review other than strongly disagreeing with the now-renamed "Support Existing Content"
127. # [00:44] <DanC> ok, I should nudge shepers to elaborate his argument against.
128. # [00:44] <mjs> which has now triggered a lengthy discussion
129. # [00:44] <DanC> goodness... do I have to chair this thing real-time 24x7?
130. # [00:44] <mjs> I think he gave something of an argument, which is that it could allow the development model for future content authors writing content from scratch to be simpler
131. # [00:45] <mjs> to break compatibility
132. # [00:45] <mjs> but I think his argument is outweighed by other considerations, and also not even right on the face of it
133. # [00:45] <DanC> we have 18 people signed up for the tutorial task; I think that's the way to address the "what do we tell authors?" concern.
134. # [00:45] <mjs> thus, debate
135. # [00:47] <DanC> I haven't gotten a response to my attempt to recruit a leader for the tutorial task. http://lists.w3.org/Archives/Public/www-archive/2007Apr/0069.html
136. # [00:48] <DanC> this is beyond absurd... we have a lengthy thread with *no subject*?
137. # [00:48] <DanC> ryan king, help?
138. # [00:48] <mjs> I should have added a subject when I replied, sorry
139. # [00:48] <DanC> I'm inclined to write a "have a nice weekend; I'd rather you didn't send any more mail for a couple days" messag.
140. # [00:49] <Hixie> that probably wouldn't go down very well with those people who can only contribute in their free time :-)
141. # [00:49] <Hixie> hopefully once we start work in earnest the traffic will become more reasonable
142. # [00:50] <DanC> yeah, some folks are in a position to do real work on the weekend; that's why I haven't sent it
143. # [00:50] <Hixie> (at least, that's the only reason i can see for the whatwg list to have more focussed traffic than the htmlwg list, given it has more than twice the participants.)
144. # [00:50] <DanC> the whatwg list is probably more mature
145. # [00:52] <DanC> "In any case, it would be a lot easier to consider this in the context
146. # [00:52] <DanC> of specific proposals to change things incompatibly."
147. # [00:52] <DanC> indeed; this discussion of design principles might be reaching a point of diminishing returns.
148. # [00:53] <DanC> perhaps we'll naturally return to it after looking at some design issues.
149. # [00:54] <mjs> I think the non-responders list on the survey omits the public invited experts
150. # [00:54] <DanC> Hixie, do you have any preferences about how we start to review HTML 5? I'm thinking, vaguely, some sort of section-by-section lightweight review where people mostly just raise issues and we build an issues list.
151. # [00:54] <mjs> it's got only W3C Members and W3C Invited Experts
152. # [00:55] <DanC> right, mjs; fortunately, the bug doesn't prevent the public invited experts from responding.
153. # [00:55] <mjs> DanC: if there's official review as a group, we'll need to get some people and software set up for issue tracking ASAP
154. # [00:55] <Hixie> DanC: i think with a group this size and a spec of this magnitude that's probably teh only way to go -- maybe even further, maybe just have everyone just comment on the bits that they care about
155. # [00:55] <DanC> what do people think about using bugzilla for issue tracking? I think it's dreadful, but maybe it sucks less than everything else? I've had good experience with roundup.
156. # [00:56] <mjs> I do think focused discussion by section would be good
157. # [00:56] <Hixie> DanC: as editor i'd certainly appreciate having the issues tracked for me though, so i don't have to read and reply to every single e-mail like i do on the whatwg list, at least not if the volume continues at this rate :-)
158. # [00:56] <mjs> I have proposed bugzilla for issue tracking before in other groups - I think the main downside is no good way to automatically integrate it with a mailing list
159. # [00:57] <DanC> yes, it would be crazy to expect you to just remember which things you've responded to. plus, we need more transparency.
160. # [00:57] <mjs> it would be nice if you could have email on an issue automatically appended to the relevant issue tracker item, or even create a new issue by email
161. # [00:57] <DanC> roundup seems to do pretty well with email integration.
162. # [00:57] <Hixie> i think it's important that we have a clear separation of "all the e-mail on this issue" and "a summary of the various arguments put forward on this issue"
163. # [00:58] <DanC> unfortunately, roundup isn't supported by the w3c sytems team. bugzilla is. And this new "tracker" thing. I don't trust anything as new as tracker.
164. # [00:58] <DanC> right; the summary is important.
165. # [00:58] <Hixie> dino's tracker thing doesn't, as far as i can tell, have any way of doing the summary part
166. # [00:58] <mjs> the summary would have to be maintained by hand, but linking all relevant emails is also good
167. # [00:58] <Hixie> it's very good for the tracking the list part though
168. # [00:58] <Hixie> maybe we can use tracker for tracking the list, and a wiki for the summary
169. # [00:58] * Hixie shrugs
170. # [00:58] <DanC> tracker seems to not keep a complete audit trail. gives me heebie-jeebies.
171. # [00:59] <mjs> I also like having good query capability, and a way to mark different kinds of resolutions to issues
172. # [00:59] <DanC> roundup: check, and check.
173. # [00:59] <mjs> for instance, some feature ideas we may choose to leave out of HTML5 but we'd want to say they are deferred to a later version, not rejected outright
174. # [00:59] <Hixie> yeah
175. # [00:59] <mjs> also good to be able to mark duplicates
176. # [01:00] <Hixie> definitely
177. # [01:00] <DanC> a wiki for the summaries... that appeals to me...
178. # [01:00] <Hixie> bugzilla doesn't have a good way of having a summary of arguments, as a negative point against that
179. # [01:00] <Hixie> but if we use a wiki for it we can make the URL field point to it
180. # [01:01] <DanC> bugzilla always seems like overkill to me. but I've never really worked on anything near the size of mozilla.
181. # [01:01] <mjs> it's not completely impossible to customize bugzilla, but I don't know if anyone wants to sign up to do it
182. # [01:01] <mjs> bugzilla does have some needless complications though
183. # [01:01] <DanC> (well, not open source; I did some commercial stuff that might be as many lines of code; but nowhere near the # of devs)
184. # [01:01] <Hixie> yeah bugzilla is quite the beast
185. # [01:01] <Hixie> might be too big for our needs
186. # [01:02] <DanC> roundup is sounding better and better all the time... the only issue is support staff... hmm...
187. # [01:03] <DanC> very tricky, with the systems team having just done code review of tracker...
188. # [01:04] * DanC checks the tasks survey to see who's interested in issue tracking..
189. # [01:04] <Hixie> roundup has the other advantage that i know Ka-Ping Yee :-)
190. # [01:04] <DanC> ping isn't still actively involved, is he?
191. # [01:04] <Dashiva> That's quite the name...
192. # [01:04] <Hixie> don't think so
193. # [01:04] <DanC> roundup definitely still glows from his touch
194. # [01:04] <Hixie> is there a demo version running somewhere i can look at?
195. # [01:05] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
196. # [01:05] <DanC> http://dig.csail.mit.edu/issues/tabulator/
197. # [01:05] <DanC> that's the one I have experience with
198. # [01:05] <DanC> I supervised a group of summer students using that.
199. # [01:05] <DanC> it's probably a bit rotten by now; the students have been gone for a while
200. # [01:06] <Hixie> doesn't seem to really have a good way of summarising the arguments either
201. # [01:06] <DanC> ah. indeed. hmm.
202. # [01:06] <Hixie> does it track the e-mails from the list automatically at all?
203. # [01:06] <Hixie> that's the biggest problem i think we'll have
204. # [01:06] * DanC gets SIG_FAIMILY_TIME
205. # [01:07] <Hixie> later
206. # [01:07] * DanC is away: family time
207. # [01:07] <beowulf> ultimatum is a really loaded word
208. # [01:08] <Hixie> it's loaded because it has two meanings
209. # [01:08] <Hixie> 1. A final statement of terms made by one party to another.
210. # [01:08] <Hixie> 2. A statement, especially in diplomatic negotiations, that expresses or implies the threat of serious penalties if the terms are not accepted.
211. # [01:08] <Hixie> the former is what we have here
212. # [01:08] <Hixie> not the latter
213. # [01:08] <Hixie> yet the word usually implies the latter
214. # [01:10] <beowulf> i just took what mjs said to be a statement of fact
215. # [01:10] <beowulf> which as you say is 2
216. # [01:11] <Hixie> 2?
217. # [01:11] <beowulf> sorry, your second definition of ultimatum
218. # [01:11] <mjs> I thought it was more like 1
219. # [01:11] <Hixie> i didn't see any penalties being threatened, which is what i find to be most telling of an ultimatum
220. # [01:11] <mjs> there's no threat of penalties
221. # [01:11] <mjs> I'm not saying anyone will be punished or even that browser vendors would quit the group
222. # [01:12] <mjs> but there's no obligation by working group members to implement the spec that comes out
223. # [01:12] <beowulf> doh, i misread
224. # [01:12] <mjs> and it seems helpful rather than malevolent to point out the kinds of issues that would be showstoppers for implementors
225. # [01:12] <beowulf> absolutely
226. # [01:12] <Hixie> there's never any such obligation, other than the self-imposed obligation encouraged by the ideal of interoperating
227. # [01:32] * Quits: tH (r@87.102.6.103) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
228. # [01:43] * Joins: sbuluf (mpnx@200.49.140.218)
229. # [01:46] * Joins: h3h (bfults@66.75.149.197)
230. # [01:48] * Quits: h3h (bfults@66.75.149.197) (Quit: h3h)
231. # [02:15] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
232. # [02:28] <Hixie> you know there's something weird about someone telling me that i owe the web something
233. # [02:28] <Hixie> i really don't think i owe the web anything.
234. # [02:29] <Dashiva> You owe it your job? :)
235. # [02:29] <Hixie> not really, i spent years unemployed doing exactly what i'm doing now
236. # [02:30] <Hixie> the web didn't give me my job, my commitment to the web even when i was unemployed is what got me my job
237. # [02:30] <mjs> who told you that you owe the web something?
238. # [02:30] <Hixie> http://lists.w3.org/Archives/Public/public-html/2007Apr/1572.html
239. # [02:32] <mjs> oh
240. # [02:33] <mjs> I love his explanation of how doing Apple's shopping site requires a feature that it doesn't actually use
241. # [02:34] <mjs> it sounds like the 'relevant' feature is pretty much analogous to HTML5's 'irrelevant', though, based on what he said
242. # [02:34] <mjs> hidden but still part of form submission
243. # [02:34] <mjs> (except that irrelevant is just a flag, not computed from other values implicitly)
244. # [02:34] <Hixie> yeah, i said as much in an earlier e-mail
245. # [02:35] <Hixie> i figured since he was ignoring my mails, i'd ignore his
246. # [02:35] <Hixie> people tend to lose credibility in my eyes when they tell me that i owe the web something, or when they reply to my e-mails completely ignoring what i said
247. # [02:36] <sbuluf> the first part is *somewhat* more understandable, though.
248. # [02:37] <mjs> I don't understand his focus on spreadsheets, or his belief that adding a constraint solver to HTML is at all helpful for implementing them
249. # [02:38] <Hixie> i'd love to add constraint solving to html, if someone can find a way to do it that is implementable without having to solve the halting problem and without ignoring error handling
250. # [02:39] <Hixie> (and following the proposed design principles, obviously)
251. # [02:40] <mjs> it seems neat
252. # [02:40] <mjs> but not cool enough to add even if broken
253. # [02:41] <mjs> and one must consider the cost more generally
254. # [02:41] <mjs> it's certainly possible to add a constraint solver based on xpath
255. # [02:41] <Hixie> in a way that has graceful degradation? how?
256. # [02:41] <mjs> if only because xpath is limited enough that it can be statically analyzed
257. # [02:42] <mjs> well, it wouldn't degrade more or less gracefully than one based on a JS subset
258. # [02:42] <Hixie> like i said, i haven't found any solution that fits our design principles
259. # [02:42] <mjs> graceful degradation is certainly a good reason for relying as much as possible on existing events
260. # [02:43] <mjs> much as it is a good reason to have range as an <input> type rather than as a separate element (or worse yet, both)
261. # [02:43] <Hixie> this is why we have to find out whether the group agrees with the proposed design principles
262. # [02:44] <Hixie> because if the majority of us don't agree with it, then those who do agree with them are going to have to figure out what to do
263. # [02:44] <sbuluf> if they accept your design principles, they accept the whole thing
264. # [02:44] <Hixie> and vice versa
265. # [02:44] <Hixie> whole thing?
266. # [02:44] <mjs> the design principles don't necessarily inevitably lead to the exact text of HTML5 as it currently stands
267. # [02:44] <sbuluf> most of html5, as you have it now, i mean
268. # [02:44] <Hixie> oh no
269. # [02:44] <Hixie> not at all
270. # [02:45] <mjs> many times there are alternatives that satisfy the principles equally well, or make different tradeoffs w/ respect to different principles
271. # [02:45] <Hixie> web forms 2, for example, went through many many changes from initial proposal to its current semi-stable state, all while trying to fit those principles
272. # [02:45] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
273. # [02:45] <Hixie> what mjs said
274. # [02:45] <mjs> plus, the spec is not nearly done
275. # [02:45] <sbuluf> since i think you guys worked under those ideas for quite some time, and i think you gave quite a bit of thought to the work
276. # [02:45] <Hixie> there are also times where the spec violates the principles, and we need to find those and fix them
277. # [02:46] <sbuluf> well, yes, i ee. but i think you do have quite a head start. and i tend to trust your combined expertise
278. # [02:47] <Hixie> that's why apple, opera, and mozilla are proposing the work to the htmlwg
279. # [02:47] <Hixie> so that we can contribute our "head start" and benefit the whole group
280. # [02:47] <sbuluf> perhaps i should have said "the core" instead of "the wholke thing"
281. # [02:48] <Hixie> well, that's what we're voting on now
282. # [02:48] <Hixie> and that's coming before the vote (if any) on the principles
283. # [02:50] <sbuluf> that's the reverse logical order, to me, to be honest
284. # [02:50] * Joins: gavin_ (gavin@74.103.208.221)
285. # [02:50] <sbuluf> it is the principles who set the tone, i thik
286. # [02:51] <Hixie> i don't necessarily disagree, but that's the order our chairs have decided to do things in
287. # [02:51] <sbuluf> judging by timbl's interventions in the telecon, he apparently thinks the same
288. # [02:51] <sbuluf> hixie, yes, i see.
289. # [02:52] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
290. # [02:55] <sbuluf> yeterday i read a bit about the forms subproblem (which is definitely over my head, mind you all)
291. # [02:56] <sbuluf> once again,i had a sort of analogous problem as i had with the whole html5 vs xhtml2 issue
292. # [02:57] <sbuluf> if w3c wants a path from one to the other, or not
293. # [02:57] <Hixie> the w3c is an organisation
294. # [02:57] <Hixie> organisations don't have wants
295. # [02:57] <Hixie> people have wants
296. # [02:57] <sbuluf> well, timbl, in that case
297. # [02:58] <Hixie> it isn't clear to me that tbl cares, but i could be misrepresenting his opinion
298. # [02:58] <sbuluf> i see some possibilities...but foggy, as of now, myself
299. # [02:59] <sbuluf> for example: he vouches for html5...but asks a xml serialization as well. and he vouches for wf2, but sort of mixing it with xforms...an intermediate
300. # [03:01] <sbuluf> who exactly asked for that transitional forms spec? and why?
301. # [03:06] <Hixie> the xforms wg
302. # [03:06] <Hixie> they are worried that their work is being made irrelevant
303. # [03:07] <sbuluf> dettached frm the web, via you
304. # [03:07] <Hixie> i'm sure they think it's my fault, yes
305. # [03:07] <sbuluf> hehe, no, i did not mean it personally
306. # [03:07] <sbuluf> but via the combined whatwg work, i mean
307. # [03:08] <Hixie> sure. and while i'm honoured that they think the whatwg work has that much power, i really think there might be bigger reasons why xforms has not enjoyed the same success as html.
308. # [03:08] <Hixie> but then i've explained those reasons to them many times
309. # [03:09] <sbuluf> i see. (as i said, unfortunately, the whole forms thing is over my head)
310. # [03:11] <sbuluf> as for whatwg power...well, there is a turning point: w3c launched this group. and that means back compat, graceful degradation, etc. definitely not the way things used to be
311. # [03:12] <Hixie> yeah but that's not because the whatwg is powerful
312. # [03:13] <Hixie> consider: if you have two people, one trying to swim upstream, and one trying to swim downstream, in a huge river with a strong current
313. # [03:13] <Hixie> which one is more powerful?
314. # [03:13] <sbuluf> oh, i do not have quite clear why this turn of events happened. as you might remember, i ask myself why timbl did this.
315. # [03:14] <Hixie> i think tbl saw that the group swimming downstream was getting further, and saw that his organisation might become irrelevant if he built it only with those swimming upstream
316. # [03:14] <Hixie> and so he thought to not put his eggs all in one basket
317. # [03:14] <sbuluf> is a distinct possibility, yes. i tend to agree
318. # [03:15] <Hixie> so it is with things like backwards compatibility: i don't myself have a vested interest in breaking or keeping backwards compatibility
319. # [03:15] <Hixie> and as a spec author, i am only as powerful as the people i am writing the specs for allow me to be
320. # [03:15] <Hixie> so i go with the river, with the people who i am writing the specs for
321. # [03:16] <Hixie> and so i look like i have more power, but really i'm just going with the current
322. # [03:16] <sbuluf> oh, i understand your position, right.
323. # [03:16] <Hixie> that's why i'm baffled when people say that i'm wrong to argue for things like backwards compatiblility
324. # [03:17] <Hixie> it's the way the river goes. it's not like we have a choice on the matter.
325. # [03:17] <sbuluf> you might remember i vote for full revolution, myself. but if not, then i can see the logic in what you do.
326. # [03:17] <schepers> oh, please
327. # [03:17] <sbuluf> is the "pragmatic" path, we could say
328. # [03:17] <schepers> there's lots of ways we can go, it's a choice, it's not destiny
329. # [03:19] <mjs> some choices are just better than others, given context
330. # [03:20] <schepers> true
331. # [03:20] <schepers> but even that is a matter of opinion
332. # [03:21] <mjs> only if you're a relativist
333. # [03:21] <Hixie> you get further by swimming downstream than upstream. that is, your spec will be followed more if you write it according to the constraints of those that will implement it most widely.
334. # [03:21] <sbuluf> you might remember i vote for full revolution, myself. but if not, then i can see the logic in what you do. <--mjs, this is how hixie and myself can interact with minimal friction, i think. we see both paths. he votes for one, i vote for the other. but we both likely understand the logic in both.
335. # [03:22] <Hixie> if the browser vendors say that they'll only implement the spec if i do it a particular way, i have a choice, i can ignore them or do what they say
336. # [03:22] <Hixie> i chose to do what they say because that way my work gets wider use
337. # [03:22] <schepers> I had a think about it, and I've decided that while I strongly disagree with your stance, ultimately, I have little say... I'm not an implementor, after all, and it's not my resources that will be allocated
338. # [03:22] <Hixie> it's not "right" or "wrong"
339. # [03:22] <sbuluf> mjs, what i try to say is that there *is* other logic, that can be argued for. much less likely to happen, perhaps, but logic, after all, i mean
340. # [03:22] <Hixie> schepers: right, i'm in exactly the same position
341. # [03:23] <schepers> I'm afraid I don't quite buy that
342. # [03:23] <schepers> to be frank
343. # [03:23] <mjs> schepers: another thing that may help is thinking about what specific things you'd change if you had the freedom to break compatibility, and how some of the same goals could be achieved without breaking compat
344. # [03:24] <mjs> I try to think that a lot, because I think giving web developers a good model is important, but not at the cost of breaking compat
345. # [03:24] <sbuluf> i do the exact opposite, myself.
346. # [03:24] <mjs> the distinction between UA conformance requirements and document conformance requirements is one point of leverage for simplifying things for authors
347. # [03:24] <schepers> I think that's an artificial argument: the words "break compatibility" are deliberately frictional, and rather fictional
348. # [03:25] <schepers> it's just another catchphrase that seems to make sense until you ask what it means
349. # [03:25] <mjs> schepers: let me put it this way - the difference between implementing HTML5 in a way that also applies to current HTML4 content vs implementing it as a separate mode is real
350. # [03:25] <schepers> agreed
351. # [03:26] <mjs> to make it possible to apply it to current content implies certain design constraints
352. # [03:26] <schepers> but browsers could go either way
353. # [03:26] <schepers> ah, that's where we differ
354. # [03:26] <mjs> as shorthand, I refer to those design constraints as "not breaking compatibility"
355. # [03:26] <Hixie> schepers: how am i _not_ in that position? you think if i said "ok, we're breaking back compat" that browser vendors would just say "ok sir! whatever you say sir!"? because if so, you are sadly mistaken.
356. # [03:26] <schepers> I don't think that current content has to be 100% compatible, because browsers already handle current content
357. # [03:26] <Hixie> much as i'd love it to be true, browser vendors only listen to me because i do what they need
358. # [03:28] * Joins: myakura (myakura@60.239.122.32)
359. # [03:28] <schepers> Hixie: are you saying that you aren't in favor of this "perpetual compatibility" model?
360. # [03:28] * Joins: polin8 (polin8@24.184.204.6)
361. # [03:29] <mjs> "I don't think that current content has to be 100% compatible, because browsers already handle current content" -- I don't see how that follows
362. # [03:29] <Hixie> schepers: if the browser vendors were ready to just start over, i'd be the first one on that bandwagon.
363. # [03:29] <Hixie> schepers: the current state of HTML/JS/DOM/CSS is a mess beyond sanity.
364. # [03:29] <schepers> and yet we're going to perpetuate it?
365. # [03:29] <mjs> browsers handle current content by being compatible with it
366. # [03:29] <mjs> even if browser vendors were ready to start over, I don't think web developers are
367. # [03:29] <Hixie> schepers: i personally do not believe i have a realistic choice.
368. # [03:30] <sbuluf> <Hixie> schepers: if the browser vendors were ready to just start over, i'd be the first one on that bandwagon. <--and his, again, is why, while i vote for revolution, we can talk with almost no problems.
369. # [03:30] <Hixie> schepers: if i wrote specs that didn't do what browser vendors said, i'd be ignored
370. # [03:30] <schepers> hey, you forgot about Poland^H^H^H^H^H^H SVG!
371. # [03:30] <schepers> SVG is just as much of a mess as HTML/JS/DOM/CSS... I resent your leaving it out
372. # [03:31] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
373. # [03:31] <Hixie> svg is a mess due to bad design decisions, not due to a legacy of bad implementations
374. # [03:31] <mjs> SVG isn't a mess for compatibility reasons
375. # [03:31] <Hixie> svg could still be fixed
376. # [03:31] <Hixie> that's up to the svgwg
377. # [03:31] <mjs> I'll also note that when SVG doesn't do what browser vendors say, it gets ignored
378. # [03:31] <mjs> it's not like HTML is that much a special case
379. # [03:32] <Hixie> (i wish i had the time and expertise to fix it myself, but html5 is a bigger fish, and i don't know enough about graphics to write a quality spec)
380. # [03:32] <sbuluf> hixie, your hands are full already
381. # [03:32] <sbuluf> for years to come, too
382. # [03:32] <sbuluf> as i said once, i don't envy you the mess
383. # [03:33] <Hixie> sadly svg needs fixing today
384. # [03:33] <sbuluf> everything does
385. # [03:33] <Hixie> if we don't fix it now, we'll end up stuck with it as we are with html
386. # [03:33] <schepers> I'd like to think that the current constituency of SVG WG is open to vendor needs
387. # [03:34] <sbuluf> why did svg get derailed?
388. # [03:34] <mjs> I sent Ollie to try to help w/ SVG
389. # [03:34] <sbuluf> bad design, of vendor's pressures?
390. # [03:34] <mjs> I do see some signs of improvement
391. # [03:34] <schepers> because it wasn't implemented widely
392. # [03:35] <schepers> mostly, Adobe drove the train
393. # [03:35] <schepers> I'm glad that browsers are picking it up instead
394. # [03:35] <sbuluf> adobe shouldn't exist <--orry, i just had to. i will not do it again.
395. # [03:35] * Joins: polin8 (polin8@24.184.204.6)
396. # [03:36] <mjs> I really want someone to spec things enough that the killer use case of SVG in an <img> or CSS background image can work
397. # [03:37] <sbuluf> hixie, just for the record...html, itself, is not the problem. the problem is even bigger: "standards by consensus"
398. # [03:37] <mjs> maybe I can make olliej write a spec draft for that
399. # [03:37] <schepers> I floated the idea of SVG Core to some browsers and the SVG WG... a leaner, more browser-friendly spec on which to base the rest of the expansions.... maybe that could still happen, if the will is there... I got moderate interest
400. # [03:37] <sbuluf> (ollie was helpful in #webkit, he seems nice)
401. # [03:38] <schepers> ollie does seem like a good guy
402. # [03:38] <schepers> mjs: that's not really SVG, I think... more like CDF
403. # [03:39] <schepers> insofar as it would be an application of SVG in a non-SVG context
404. # [03:39] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
405. # [03:42] <mjs> schepers: I'd rather not leave it up to the CDF WG
406. # [03:42] <mjs> I'm not sure who is responsible
407. # [03:42] * Joins: polin8 (polin8@24.184.204.6)
408. # [03:42] <mjs> SVG, HTML and CSS are all involved
409. # [03:42] <mjs> maybe a Task Force
410. # [03:42] <mjs> or maybe we'll just implement our best shot in WebKit and propose it
411. # [03:42] <mjs> we have an experimental version of that feature, off by default for now
412. # [03:42] <mjs> using an SVG image as a CSS background is totally hot
413. # [03:42] <schepers> I think it works in Opera, you should coordinate with them
414. # [03:43] <schepers> mjs: is it performant?
415. # [03:43] <mjs> I don't think Opera has SVG as a CSS background - I would be highly surprised anyway
416. # [03:44] <mjs> it was fairly performant, yes
417. # [03:44] <schepers> I would like to see a task force like that, for a number of different issues
418. # [03:44] <zcorpan> mjs: they do in some internal build apparently
419. # [03:44] <mjs> zcorpan: then we should definitely coordinate
420. # [03:45] <zcorpan> mjs: http://annevankesteren.nl/2007/04/html5-talk
421. # [03:45] <mjs> neat
422. # [03:46] <schepers> erik dahlstrom's a good guy, you should have olliej talk with him
423. # [03:46] <schepers> are you sending oliver to the next SVG WG F2F?
424. # [03:52] <mjs> I dunno
425. # [03:52] <mjs> where is it?
426. # [03:52] <mjs> depends on if he feels like going
427. # [04:02] <schepers> sorry, afk
428. # [04:02] <schepers> uh... zurich?
429. # [04:04] <schepers> 5-8 June 2007 in Zürich
430. # [04:04] <mjs> that might conflict w/ Apple's World Wide Developer's Conference
431. # [04:04] <schepers> he mentioned something like that
432. # [04:05] <schepers> well, he can chat with Erik anytime
433. # [04:05] <schepers> f2f's are just good for that
434. # [04:07] <mjs> schepers: I'd love to work through one specific thing that you think should be changed incompatibly in HTML sometime
435. # [04:07] <mjs> schepers: or maybe a couple
436. # [04:07] <mjs> schepers: it would either help you see that a compatibility requirement might not be so bad, or help me see the error of my ways
437. # [04:09] <schepers> I will look at it, read the WHATWG spec thoroughly, and give it some serious thought
438. # [04:10] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
439. # [04:17] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
440. # [04:19] * Joins: polin8 (polin8@24.184.204.6)
441. # [04:26] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
442. # [04:30] <schepers> though, of course, that's not the real problem... it's not the specific things that can't be done "compatibly"... it's the sum of all the things that must be done "compatibly" that is where the problem lies
443. # [04:30] <schepers> the overall complexity and incongruity of the system
444. # [04:35] <sbuluf> which is why i vote for revolution, myself.
445. # [04:35] <sbuluf> but is not the path that will happen in this group
446. # [04:35] <Hixie> indeed, the w3c has another group with that goal (the xhtml2wg)
447. # [04:36] <schepers> I think there is a middle ground between revolution and legacy
448. # [04:36] <sbuluf> xhtml2 supposedly breaks back compat
449. # [04:36] <Hixie> sbuluf: right, it's a revolution
450. # [04:36] <sbuluf> yep
451. # [04:37] <schepers> but a browser can implement both... it's not an either/or proposition
452. # [04:37] <schepers> I reckon if IE implements it, the other browser vendors will follow
453. # [04:37] <schepers> but who knows if they will
454. # [04:37] <sbuluf> but they wouldn't
455. # [04:38] <schepers> why wouldn't they?
456. # [04:38] <sbuluf> furthermore, the problem is even bigger
457. # [04:38] <Hixie> the problem is that makes the marketplace extremely hard to compete in in the long term
458. # [04:38] <schepers> which is one reason IE might implement it ;)
459. # [04:38] <schepers> deep pockets
460. # [04:38] <Hixie> personally i _am_ against anything that makes it harder to compete in -- having multiple modes, many of which are undefined or underdefined, makes it hard to compete
461. # [04:38] <Hixie> and that's extremely bad for the human race
462. # [04:39] <sbuluf> > hixie, just for the record...html, itself, is not the problem. the problem is even bigger: "standards by consensus" <--
463. # [04:39] <Hixie> i'm not sure what you mean
464. # [04:39] <schepers> oh, get off the slogans, please!
465. # [04:40] <Hixie> who, me, or sbuluf?
466. # [04:40] <schepers> sbuluf
467. # [04:40] <sbuluf> hixie, a few days back, i posted a couple of lines from a web article about w3c
468. # [04:40] <sbuluf> it basically said w3c works mostly in two modes
469. # [04:41] <sbuluf> in one of them, they are ahead of the curve, and those periods, they do some desginign
470. # [04:41] <sbuluf> in other, they are behind, and in those times, they can just compromise with reality
471. # [04:41] <sbuluf> example of this second type of moment, html3.2
472. # [04:41] <sbuluf> and now, html 5
473. # [04:42] <schepers> Hixie: although the "bad for the human race" thing is a bit over the top...
474. # [04:42] <sbuluf> the bottom line, is that in today's web, nobody can *ënforce* standards
475. # [04:42] <sbuluf> hence...microsoft
476. # [04:43] <Hixie> schepers: it would be bad for us to have only one vendor in control of the web, which is the logical conclusion of several decades of having rendering modes
477. # [04:43] <sbuluf> "standards by consensus" models, can't do much in front of microsoft
478. # [04:43] <schepers> I don't share your conclusion, but I believe you believe it
479. # [04:44] <mjs> more rendering modes is definitely anti-competitive
480. # [04:44] <mjs> especially when some of the modes are defined as "reverse engineer whatever the highest market share browser during this time period did"
481. # [04:45] <sbuluf> but unsttopable, if they so wish
482. # [04:45] <schepers> I think that in the long run, making HTML more and more complex and trying to accomodate more and more errors into the spec itself will make a pice of bloatware that is unimplementable by anyone but the richest companies
483. # [04:45] <sbuluf> in a "standards by consensus" model of web evolution, nobody can enforce any standard
484. # [04:45] <Hixie> schepers: you don't think that having multiple languages that _aren't_ specified but have those same errors will be harder?
485. # [04:46] * schepers reparses without so many negatives... do I think it would be easier to have multiple languages that aren't specified... is that the question?
486. # [04:47] <Hixie> yes
487. # [04:47] <schepers> ok
488. # [04:48] <schepers> so, you're operating on the assumption that the standard we make now will not be implemented correctly, thus qualifying it as an "unspecified language" (no matter how well the spec is written)?
489. # [04:48] <Hixie> microsoft have stated their intent to freeze releases before having fixed all their bugs.
490. # [04:49] <Hixie> freeze their rendering engines, i mean
491. # [04:49] <Hixie> thus introducing their bugs as a pseudo-random specification each time they freeze their rendering engine
492. # [04:50] <sbuluf> (not just *past* error accumulation, but also *future* one)
493. # [04:50] <schepers> "stated their intent" is a bit strong... you solicited that statement from them rather leadingly
494. # [04:50] <mjs> I don't think Hixie solicited anything there
495. # [04:50] <schepers> at some point, Mozilla, Apple, Opera, all will freeze their bugs as well
496. # [04:51] <schepers> sorry, "y'all"
497. # [04:51] <mjs> Apple has no plan to freeze bugs wholesale
498. # [04:51] <mjs> if we find some bug we can't fix due to compat issues, we'll try to feed it back into the spec
499. # [04:52] <Hixie> schepers: on the contrary, Mozilla, Apple, and Opera are still fixing bugs in quirks mode, whereas microsoft has frozen their quirks mode.
500. # [04:52] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
501. # [04:52] <schepers> but neither can you guarantee that your company will follow through on full implementation, correct?
502. # [04:52] <schepers> (which is the boat IE is in)
503. # [04:52] <mjs> IE is promising not to fix bugs in existing content, and at some feature point, HTML5 content
504. # [04:52] <mjs> *any* bugs
505. # [04:53] <mjs> they will make no changes, will not investigate, and will not try to feed it back into the spec
506. # [04:53] <mjs> that is a very different stance
507. # [04:54] <schepers> ok, then, how does specifying HTML-legacy out to the last decimal point win anything, if you think MS is operating in bad faith (or is unable to follow through in good faith because of unforeseen pressures)
508. # [04:54] <Hixie> they aren't the only vendor
509. # [04:54] <schepers> tell 85% of the people who use the Web that
510. # [04:55] <Hixie> you asked why we wanted a detailed spec
511. # [04:55] <Hixie> the answer is, there are vendors who want to implement a detailed spec
512. # [04:55] * schepers wishes he used Opera (and sometimes does), but ends up using FF almost always
513. # [04:56] <schepers> so, AOS is the Greece to IE's Persia?
514. # [04:56] <schepers> oops, MozSafaOpera, I mean
515. # [04:57] <Hixie> i don't understand the reference in this context.
516. # [04:57] <schepers> sorry, making a 300 joke
517. # [04:57] <schepers> lots of small city-states teaming up on the evil empire
518. # [04:57] <sbuluf> he means you are the david, and MS the goliath
519. # [04:57] <Lachy> Hi everyone
520. # [04:58] <schepers> hey, Lachy
521. # [04:58] <sbuluf> hi
522. # [04:58] * Joins: gavin_ (gavin@74.103.208.221)
523. # [04:59] <schepers> Hixie: but the vendors could implement *any* detailed spec, thar isn't an argument for or against legacy-conformance... it's orthogonal
524. # [04:59] <Lachy> Hixie, tantek asked me to pass on his comments about the definition of <p>. See #microformats log from about 11 hours ago if you haven't already read it.
525. # [04:59] <schepers> thar=that
526. # [05:00] <Hixie> Lachy: i saw. didn't really understand why he thought the spec was bad or what he thought it should say instead.
527. # [05:01] * Joins: h3h (bfults@66.75.149.197)
528. # [05:01] <Hixie> schepers: as i mentioned earlier, browser venders have told me they won't implement something that isn't compatible with legacy content.
529. # [05:02] <h3h> we're still on this?
530. # [05:02] <Lachy> I think he wants the spec to say that <p> is only for paragraphs containing prose, according to his strict interpretation of what a paragraph is
531. # [05:03] <Hixie> Lachy: so where do we put stanzas and addresses and parts of forms and stuff in his world?
532. # [05:03] <Lachy> <div> and <span> I think
533. # [05:03] <mjs> that doesn't sound like an improvement
534. # [05:05] <sbuluf> tantek said that?
535. # [05:05] <Lachy> sbuluf, effectively, yes
536. # [05:05] <schepers> that's pretty proscriptionist
537. # [05:05] <sbuluf> he wants to plug his microformats into divs and spans, or am i understanding wrong?
538. # [05:05] <Lachy> that's right
539. # [05:06] <sbuluf> amazing
540. # [05:06] <schepers> I see no way to enforce that in practice
541. # [05:06] <Lachy> see the discussion starting here http://rbach.priv.at/Microformats-IRC/2007-04-27#T133631
542. # [05:06] <sbuluf> thanks, lachy
543. # [05:08] <sbuluf> <Lachy> it doesn't seem right to use <span> for almost everything inside the <address>, so how am I supposed to markup all of postal address, phone numbers, email, URI, etc. in just one <address> element?
544. # [05:08] <sbuluf> that was one of the very reasons why i ended up doing what i did, in case you are interested
545. # [05:09] <Lachy> what did you do?
546. # [05:09] <sbuluf> http://www.teoriadetodo.com.ar/fips/specs/cdl/anatomy.htm <-- structure=""
547. # [05:12] <zcorpan> i've seen the "<p>s should only be used for paragraphs in the English sense" elsewhere too (though that may simply be based on the interpretation of the html4 spec)
548. # [05:12] <Lachy> sbuluf, can you give a quick overview of what CDL is for?
549. # [05:13] <Lachy> The HTML4 spec is virtually silent on the issue, I don't see how anyone can use it to support their argument.
550. # [05:13] <sbuluf> ilachy, a content authoring language (think a html replacement). basically, just a tree of div's. but each div has hooks to externally define presentation, structure, meaning, and behaviour.
551. # [05:13] <mjs> tantek's stance that he can't participate in HTML5 because he has to work on microformats seems short-sighted
552. # [05:13] <zcorpan> html4 says "The P element represents a paragraph."
553. # [05:14] <Hixie> that's what the html5 spec says too, basically
554. # [05:14] <Hixie> except it says what a paragraph is :-)
555. # [05:14] <Lachy> zcorpan, yes, and it doesn't define what a paragraph is
556. # [05:14] <zcorpan> Lachy: right, then you look at the dictionary, no? :)
557. # [05:14] <sbuluf> lachy, the "structure" bit, is because i think a content language shouls allow for insertion of arbitrary structures. for example, not to hardwire some (like <adress>), but to allow you to externally define, and then insert, an adress with as many fields in it as you might wish
558. # [05:14] <mjs> I think the HTML5 definition acceptably matches what Wikipedia says
559. # [05:14] <Lachy> you can, but the dictionary didn't support tantek's claims either
560. # [05:15] <mjs> so I'm not concerned
561. # [05:15] * Joins: Shunsuke (Shunsuke@219.110.80.235)
562. # [05:16] <Lachy> sbuluf, what use cases and problems are you trying to solve? Why are you trying to replace HTML with CDL, which simply won't work?
563. # [05:16] * mjs thinks discussion of replacing HTML is somewhat off-topic here
564. # [05:17] * Joins: Zeros (Zeros-Elip@67.154.87.254)
565. # [05:17] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
566. # [05:17] <sbuluf> oh, if it won't work, then there is no much point in me describing it. and mjs is right, it is off topic, i'm afraid.
567. # [05:17] * schepers thinks we should talk about replacing HTML with ponies, instead
568. # [05:17] <mjs> omg ponies!
569. # [05:17] <schepers> I *luvvv* ponies!
570. # [05:18] * Hixie sighs and gets out IE
571. # [05:18] <Hixie> my life would be so much easier if back compat wasn't a concern
572. # [05:18] <sbuluf> i don't envy you.
573. # [05:19] <zcorpan> not as fun though, right? :)
574. # [05:19] <schepers> come to the dark side, Hixie... oh, wait... ;P
575. # [05:19] <Hixie> well, i still want my work to be relevant :_P
576. # [05:20] <mjs> reverse engineering IE builds character
577. # [05:21] <Hixie> is that what you call it
578. # [05:22] * mjs is reading the discussion
579. # [05:22] <mjs> it's so hard for me to care whether an address block or a stanza of poetry is a paragraph or not
580. # [05:23] <sbuluf> does html 5 allow things like lists inside paragraphs? if so, perhaps that's why tantek don't want that?
581. # [05:23] <sbuluf> (haven't finished reading yet)
582. # [05:23] <Lachy> sbuluf, XHTML5 does
583. # [05:24] <sbuluf> lachy, might that be tantek's problem?
584. # [05:24] <mjs> does it make them possible or make them conforming?
585. # [05:24] <Lachy> I don't think so
586. # [05:24] <Lachy> conforming
587. # [05:24] <mjs> interesting
588. # [05:24] <mjs> it seems suboptimal to have conforming XHTML5 content that has no conforming HTML5 serialization
589. # [05:25] <Lachy> http://www.whatwg.org/specs/web-apps/current-work/#inline-level0 See structured inline-level
590. # [05:25] <mjs> (except as necessary given the language differences)
591. # [05:25] <zcorpan> mjs: agreed
592. # [05:26] <zcorpan> i think the spec should cater for text/html and don't bother with the xml serialization so much
593. # [05:26] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
594. # [05:26] <zcorpan> e.g. don't disallow <base> just because there is xml:base
595. # [05:26] <Lachy> zcorpan, I agree with <base>
596. # [05:27] <zcorpan> and perhaps lang="" too... disallowing <noscript> is ok because it doesn't work and isn't needed in xml
597. # [05:28] <Lachy> it would have helped a little if <address> could contain block level content block-level content
598. # [05:28] * Lachy should review what he types before sending
599. # [05:29] <mjs> it would help if <address> could be any address, not just the contact info for a section
600. # [05:30] <mjs> the latter could be <address class="contact">
601. # [05:30] <mjs> of course that is clearly a redefintion relative to HTML4
602. # [05:30] <mjs> but an element for any address seems more useful than an element for a contact info address
603. # [05:30] <zcorpan> that's an open issue still
604. # [05:30] <Lachy> yeah, but do authors really pay attention to that rule in practice?
605. # [05:31] <Hixie> actually yes
606. # [05:31] <Hixie> as far as i can tell the average number of <address> elements per page with <address> is roughly 1
607. # [05:31] * Lachy notes that tantek would object to that change
608. # [05:31] <Hixie> and most would, i guess, be in things like man pages, which are autogenerated
609. # [05:32] <mjs> do the <address> elements appear to be contact info?
610. # [05:32] <Hixie> hard to say from my survey, but from personal experience, yes
611. # [05:32] <mjs> actually I'm not sure what contact info for a section even means really
612. # [05:33] <sbuluf> does html 5 include microformats?
613. # [05:33] <mjs> is the address on a resume "contact info" for it?
614. # [05:33] <mjs> or the address of a restaurant in a review?
615. # [05:34] <Lachy> for a resume, yes (assuming the resume is the authors)
616. # [05:34] <mjs> is it contact info from the original author of content, the maintainer of the page/server, or the subject at hand?
617. # [05:35] <Hixie> spec says it clearly i tihnk
618. # [05:35] <Hixie> take a look :-)
619. # [05:35] <mjs> it's not clear to me from the spec or examples
620. # [05:35] <mjs> the example it has is "contact persons for the HTML Activity"
621. # [05:36] <mjs> which might not have anything to do with the authors or maintainers of a page about the HTML Activity
622. # [05:36] <zcorpan> i've seen <address> used for author contact info, company contact info, contact info for someone else, and postal addresses, and probably other things too
623. # [05:36] <mjs> so it's unclear to me if it would be appropriate for an address in a restaurant review
624. # [05:36] <mjs> written by someone else
625. # [05:36] <mjs> in a sense it is "contact info" for the restaurant, but I don't know if that makes it contact info for the section
626. # [05:36] <Hixie> well, send mail, and i'll look into it :-)
627. # [05:36] <Hixie> i'm sure there's already a lot of feedback about <address>
628. # [05:37] <Lachy> IMHO, the actual author of the content is irrelevant to users in practice
629. # [05:37] <mjs> me too
630. # [05:37] <mjs> so I probably won't send more mail
631. # [05:38] <Lachy> I have probably already stated my opinion on whatwg list already
632. # [05:41] <sbuluf> can't find anything about microformats in html 5, if i got the right page
633. # [05:42] <sbuluf> there is micro-syntaxes, but that looks more like data types
634. # [05:42] <zcorpan> sbuluf: are you looking for the "predefined classes"?
635. # [05:42] * Quits: DanC (connolly@128.30.52.30) (Ping timeout)
636. # [05:42] <sbuluf> zcorpan, are those microformats?
637. # [05:43] <zcorpan> what's the definition of "microformats"?
638. # [05:44] <mjs> some microformats people claim that only things that follow the microformats process are microformats
639. # [05:44] <mjs> in which case the answer is generally no, everything in HTML5 has so far followed the WHATWG process and will in the future presumably follow the W3C process
640. # [05:44] <Lachy> some microformats people are overly strict in their definitions and interpretations
641. # [05:45] <mjs> in the broader sense of a convention for semantic markup that allows human-readable info to also be machine-parseable, yes
642. # [05:45] <zcorpan> then the predefined classes that followed the microformats process are microformats, i guess :)
643. # [05:46] <zcorpan> (if any)
644. # [05:46] <sbuluf> i see. i wonder if microformats are somewhat off topic here, then.
645. # [05:46] <mjs> I think rel="nofollow" at some point followed the microformats process, but was first used before microformats existed and has a separate definition from HTML5
646. # [05:46] <mjs> I think semantic use of HTML, including by convention, is on-topic
647. # [05:49] * Quits: h3h (bfults@66.75.149.197) (Quit: h3h)
648. # [05:56] * Joins: Shunsuke (Shunsuke@219.110.80.235)
649. # [06:13] * Quits: mw22 (chatzilla@84.41.169.151) (Ping timeout)
650. # [06:16] * Joins: mw22_ (chatzilla@84.41.169.151)
651. # [06:16] * mw22_ is now known as mw22
652. # [06:27] * Joins: DanC_lap (connolly@128.30.52.30)
653. # [06:44] * Joins: heycam (cam@124.168.141.224)
654. # [06:49] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
655. # [07:00] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
656. # [07:00] * Quits: zcorpan (zcorpan@84.216.43.150) (Ping timeout)
657. # [07:05] * Joins: gavin_ (gavin@74.103.208.221)
658. # [08:23] * Joins: MrNaz (Naz@203.214.95.166)
659. # [08:33] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
660. # [09:07] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
661. # [09:12] * Joins: gavin_ (gavin@74.103.208.221)
662. # [09:28] * Joins: zdenko (zdenko@84.255.203.169)
663. # [09:31] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
664. # [09:33] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
665. # [09:47] * anne42 is now known as anne
666. # [10:04] <anne> It looks like http://www.w3.org/2002/09/wbs/40318/htmlbg/results only includes W3C IEs and Members in the Non-responders section
667. # [10:04] <anne> On the other hand, it seems like everyone can vote...
668. # [10:05] <mjs> anne: indeed - DanC said that was a bug
669. # [10:05] <mjs> in the survey tool
670. # [10:05] <mjs> I'm surprised that there is nog a single no vote
671. # [10:08] <xover> Formal Objections must be justified. The "No"s will spend more time considering than the "yes"es.
672. # [10:09] <anne> mjs, could you run "javascript:alert(document.getElementsByTagName('a')[0].pathname)" on something like google.com/search ?
673. # [10:09] <anne> in Safari
674. # [10:09] <anne> It seems that pathname differs for window.location and <a>
675. # [10:10] <mjs> anne: just a sec
676. # [10:10] <Hixie> the list of people who haven't voted is more telling than the list of people who voted yes
677. # [10:11] <mjs> anne: "/url"
678. # [10:11] <anne> MSIE has "url"
679. # [10:11] <anne> Opera has "url?..." which is buggy and we fixed it to "url" now for MSIE compat
680. # [10:11] <mjs> what about other browsers?
681. # [10:12] <anne> but it's inconsistent with location.pathname which is not nice
682. # [10:12] <Hixie> huh
683. # [10:12] <Hixie> interesting
684. # [10:12] <mjs> what would Firefox do?
685. # [10:12] <Hixie> never heard of any compat issues with the leading / problem
686. # [10:12] <anne> mjs, Firefox does "/url", sorry
687. # [10:12] <Hixie> spec says /url
688. # [10:13] <mjs> I haven't either, mainly cause I don't think sites use the broken out components on <a> much
689. # [10:13] <anne> the spec only defines it for location right?
690. # [10:13] <Hixie> no
691. # [10:13] <Hixie> defines one algorithm, which will apply to both
692. # [10:13] <Hixie> might not be explicitly linked to both yet though
693. # [10:13] <anne> i meant the latter, but yeah, i expected as much
694. # [10:13] <mjs> I wouldn't read too much into who hasn't voted yet
695. # [10:14] <mjs> Lachy hasn't, for instance, and I doubt that is out of apathy
696. # [10:14] <mjs> likewise no one from Opera has voted
697. # [10:14] <Hixie> opera did vote
698. # [10:14] <Hixie> i assume wilhelm removed his vote
699. # [10:14] <Hixie> since he's not the official rep :-)
700. # [10:14] <anne> he told me yesterday he was completely done with HTML5 and that he applied for XHTML2 IE status
701. # [10:14] <anne> lachy that is
702. # [10:14] * Lachy will vote now
703. # [10:14] <Hixie> anne: uh huh
704. # [10:15] <mjs> ah, so they did
705. # [10:15] <anne> oh he's awake
706. # [10:15] * anne runs
707. # [10:15] <Lachy> s/now/no/ ;-)
708. # [10:15] <mjs> adele overwrote my vote, but she voted the same so I don't care
709. # [10:15] <mjs> we never decided who was the official rep from apple
710. # [10:15] <anne> lbolstad will vote for Opera I think
711. # [10:16] <mjs> he's been stated to be the official rep by others from Opera before
712. # [10:16] * Hixie voted without talking to his other reps but figured his vote was a fair compromise anyway
713. # [10:16] <mjs> it doesn't seem like a big deal for this group who is "official"
714. # [10:17] <mjs> so how long ago did the group start, a little over a month?
715. # [10:17] <Lachy> mjs, it started on march 7
716. # [10:18] <mjs> so 1 month and 3 weeks to starting to make our first decision of any substance
717. # [10:18] <anne> Hixie, I'm not sure about compat issues either with the /. I think we just want to be on the safe side
718. # [10:19] * anne isn't sure there's much point in differing from IE here
719. # [10:23] <anne> Hixie, I'll ask about Window.postMessage()
720. # [10:24] <Lachy> Masatak Yakura commented "Wonders who'll be the authors." - I wonder why (s)he thinks authors and editors of specs are different people?
721. # [10:25] <anne> Authors are also all the people who contribute
722. # [10:29] <Hixie> anne: cool thanks
723. # [10:48] <anne> whoa, dsr is rude
724. # [10:48] * anne just replied to him
725. # [10:49] <anne> "I think you owe it to the Web" ...
726. # [10:49] <anne> if anything, dsr owes us a better version of HTML4
727. # [10:59] <anne> mjs, I think tag soup refers to HTML parsing in general
728. # [10:59] <mjs> why don't people say "HTML" instead of "tag soup" then?
729. # [10:59] <mjs> since it sounds kind of perjorative, I always assumed it meant non-conforming content
730. # [10:59] <mjs> as in "no more tag soup, use valid semantic markup"
731. # [11:00] <anne> not sure
732. # [11:00] <mjs> or contrasting "tag soup" to "well-formed XML", as if HTML content is inherently nonconformant
733. # [11:01] <Hixie> at least they're not calling it "street HTML" which is what opera people call it :-)
734. # [11:03] <mjs> actually I like that better
735. # [11:03] <mjs> it sounds kind of badass
736. # [11:03] <mjs> like "street fighting"
737. # [11:03] <anne> hehe
738. # [11:03] <mjs> or "street knowledge"
739. # [11:03] <mjs> or "street smarts"
740. # [11:05] <Hixie> mmmhm
741. # [11:06] * Lachy wonders what DanC's original meaning of tag soup was (since he apparently coined the term)
742. # [11:06] <Hixie> it's usually said like "gutter HTML"
743. # [11:09] * xover wonders what Itunes' rumored deal with Gracenote for online song lyrics will do to the whole "How to mark up song lyrics" discussion...
744. # [11:09] <mjs> I guess I'm not a fan of casually using perjoratives to refer to content formats
745. # [11:09] <mjs> but maybe we should start calling XML "tag bondage" or something
746. # [11:10] * mjs can't comment on Apple rumors
747. # [11:11] <Lachy> xover, where is the "how to mark up song lyrics" discussion?
748. # [11:12] <xover> It seems like every talk about markup inevitably uses song lyrics or poems as an example.
749. # [11:13] <Lachy> HTML5 already solves that debate (though tantek would disagree :-))
750. # [11:13] <xover> Probably because those two cases have seemingly presentational needs that are arguably semantic.
751. # [11:13] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
752. # [11:14] <Lachy> what presentational needs? Just use <p> for each verse/chorus/etc. and <br> for line breaks within those.
753. # [11:15] * xover refuses to get sucked into that discussion... :-)
754. # [11:18] <mjs> you could have a <stanza> element instead, but that really doesn't seem better than reusing <p>
755. # [11:18] <mjs> and it's not really clear if a verse or chorus is a stanza
756. # [11:18] <Lachy> <p class="stanza"> would be more appropriate
757. # [11:19] * Joins: gavin_ (gavin@74.103.208.221)
758. # [11:19] <anne> too hard
759. # [11:19] <anne> just use <p>
760. # [11:19] <Hixie> <stanza> .. </stanza> <stanza> .. </stanza> wouldn't have good graceful fallback
761. # [11:20] <anne> well, <p> and <br> or <pre>
762. # [11:21] <mjs> you'd want <pre> for an e.e. cummings poem
763. # [11:21] <xover> In context of the rumor cited, I expect Gracenote will feed the data as a specialized XML format for the purpose (where e.g. a <stanza> element would make sense).
764. # [11:22] <xover> But sooner or later the consumer of that data will want to present it to a user, probably using an embedded web browser-ish view.
765. # [11:22] <mjs> as a courtesy I ask you not to talk about Apple rumors here
766. # [11:22] <mjs> since that just makes the conversation more awkward for me
767. # [11:22] * xover was trying to generalize himself away from the rumor...
768. # [11:22] <xover> Sorry!
769. # [11:23] * Lachy askes mjs to leave so we can hear more rumors about Apple ;-)
770. # [11:23] <xover> heh heh
771. # [11:23] <mjs> I'm sure there's many places on IRC you can hear about hot apple rumors
772. # [11:24] <xover> Hey, there should be special markup for Apple rumors!
773. # [11:24] * Joins: loic (loic@90.29.247.131)
774. # [11:25] <xover> So anyways...
775. # [11:25] <xover> I once took some script code I had and marked it up in my own little XML-based bracket soup.
776. # [11:26] <xover> And then started looking at converting that to something a general web browser would display in a meaningfull way.
777. # [11:26] <xover> i.e. HTML + CSS
778. # [11:28] <xover> After many iterations it essentially ended up being a collection of deeply nested <div>s and <span>s.
779. # [11:28] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
780. # [11:28] <xover> All semantic meaning was hidden away in 'class' attributes.
781. # [11:29] <xover> And the markup weight was significantly larger then then actual content.
782. # [11:30] * Joins: tH (r@87.102.6.103)
783. # [11:31] <Lachy> quick survey results; 9/10 sites used <div> ... <br><br> ...</div> (or tables instead of div), 1/10 used <pre> for song lyrics
784. # [11:31] <xover> It would be interesting to see what others would come up with in a similar situation, if their motivation was, say, shipping an actual product, rather then indulging a personal whim.
785. # [11:33] * xover idly wonders what the syntax-coloring "View Source" functions in general browsers do here...
786. # [11:34] <xover> http://benjamin.smedbergs.us/blog/2006-07-18/marking-up-hymns/
787. # [11:40] * Joins: Shunsuke (Shunsuke@219.110.80.235)
788. # [11:54] <beowulf> the only tag that currently works easily for a poem is <pre>
789. # [11:55] <beowulf> poems have complex indentation, the best way to represent that I've found is let the user add the poem indented as they wish and capture that in a <pre> tag
790. # [12:00] <anne> not all poems have complex indentation
791. # [12:01] <anne> it varies per poem
792. # [12:02] * Joins: ROBOd (robod@86.34.246.154)
793. # [12:02] <beowulf> which makes it even harder
794. # [12:02] * gsnedders feels like slapping everyone sending "+1"
795. # [12:03] <beowulf> "letter to andre billy" has stanzas that shape bottles, an eye and a cathedral
796. # [12:03] <beowulf> try that in html :)
797. # [12:07] <anne> that's clearly a use case for <pre>
798. # [12:07] <anne> oh wait, it's not just straight lines?
799. # [12:08] <anne> if it's not, SVG or something might do it I suppose
800. # [12:08] <Lachy> I couldn't find letter to andre billy, do you have a pointer?
801. # [12:09] <beowulf> I've just looked and it's not on the interweb, I'll scan my copy and put it up
802. # [12:09] <beowulf> http://en.wikipedia.org/wiki/Guillaume_Apollinaire # the poet in question
803. # [12:09] <anne> http://www.netkonect.co.uk/~kram/apollin.htm
804. # [12:09] <beowulf> brilliant
805. # [12:10] <beowulf> between the bottle and the cathedral should be an eye
806. # [12:10] <beowulf> "I see far away \ the cathedral"
807. # [12:11] <anne> XML is complex
808. # [12:12] <anne> HTLM tree construction is too, but at least HTML tokenization doesn't have weird stuff like the internal subset and all that
809. # [12:12] <anne> s/HTLM/HTML/
810. # [12:14] <mjs> I think <pre> is fine for oddly formatted poetry
811. # [12:15] <Lachy> I don't get how the shape of the text is at all relevant to the poem, but then I always hated poetry and never understood it anyway
812. # [12:17] <beowulf> it's an extra layer of meaning
813. # [12:18] <Lachy> I still don't get what meaning it has
814. # [12:20] <beowulf> http://blue.carisenda.com/letter_to_andre_billy.jpg
815. # [12:21] <beowulf> i said bottle, the first shape is more likely a whistle :)
816. # [12:23] <Lachy> ah, it makes a little more sense with the eye in it
817. # [12:24] <Lachy> is the cathedral supposed to be read as "OH MY DEAR ANDRE BILLY"?
818. # [12:24] <beowulf> i think so
819. # [12:24] <beowulf> i'm not an expert at explaining poetry, i'm just a consumer
820. # [12:25] <beowulf> i take it to mean that these things takes shape in his mind as he sits on the front line, there's not really there
821. # [12:25] <beowulf> s/there's/they're/
822. # [12:48] * Joins: kazuhito (kazuhito@222.151.153.91)
823. # [12:48] * Joins: olli- (olli@80.203.95.229)
824. # [12:53] * Quits: sbuluf (mpnx@200.49.140.218) (Quit: sbuluf)
825. # [12:54] * Joins: sbuluf (nlbqyuv@200.49.140.250)
826. # [13:07] * Quits: loic (loic@90.29.247.131) (Ping timeout)
827. # [13:09] <mjs> why does Dave Raggett keep making me hurt him?
828. # [13:10] <anne> he's that kind of person?
829. # [13:11] <mjs> I just want to be nice to people
830. # [13:16] <anne> nice reply
831. # [13:17] <xover> hmm. Dave's example webshop UI is what Dell recently implemented, which works horribly and I hate it, and I much prefer Apple's UI for this.
832. # [13:18] <xover> Ah, as I see you're pointing out on the list. Heh.
833. # [13:22] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
834. # [13:25] <Philip`> Using a subset of JavaScript doesn't seem like the best approach - if it's meant to be like a spreadsheet, presumably people would want e.g. "if(c, x, y)", but you'd have to make compromises to work around JS's reserved words, and it'd probably get a bit ugly
835. # [13:25] <anne> his idea was to still allow custom functions
836. # [13:26] <anne> which sort of kills the idea of "subset"
837. # [13:26] <Philip`> and if you're doing a JS-based implementation for legacy browsers, you'd have to write your own JS-subset parser anyway in order to handle errors in the way the spec will define, so using a JS-subset doesn't seem better than an entirely independent JS-like language
838. # [13:27] * Joins: gavin_ (gavin@74.103.208.221)
839. # [13:36] * Joins: hasather (hasather@81.235.209.174)
840. # [13:45] <mjs> I think his latest idea was to allow a fixed set of built-in functions
841. # [13:45] <mjs> but it was expressed in one sentence so hard to tell
842. # [13:49] * Quits: olli- (olli@80.203.95.229) (Connection reset by peer)
843. # [13:55] <anne> mjs, btw, as for SVG as image... if it has an image/svg+xml MIME type or .svg extension (for local files) I think the idea is to render it as bitmap image and use it
844. # [13:55] <anne> scripting is likely disabled
845. # [13:56] <anne> I haven't tested much though
846. # [13:58] <mjs> anne: I think our plan would be to scale it as needed, turn off interactivity (so it gets no events) and probably turn off scripting
847. # [13:58] * Joins: El (opera@203.173.1.213)
848. # [13:58] <mjs> anne: not sure about turning off SMIL animations
849. # [13:58] <mjs> anne: also sizing when used as a background property and the SVG itself only declares % sizes on the root element is tricky
850. # [13:59] <mjs> anne: maybe you can chat with olliej sometime and come up w/ a rough spec
851. # [13:59] <mjs> (it can just be a whatwg draft for all I care)
852. # [14:01] <anne> that sounds pretty much like our impl
853. # [14:01] * anne tries to find out whether SMIL ani works
854. # [14:03] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Client exited)
855. # [14:04] <anne> <img> has animation but background doesn't
856. # [14:05] <anne> apparently those are done slightly different
857. # [14:06] * anne thinks it would be good if all "image contexts" agree
858. # [14:06] * Quits: sbuluf (nlbqyuv@200.49.140.250) (Ping timeout)
859. # [14:12] * Joins: tH_ (r@87.102.2.18)
860. # [14:14] * Quits: kazuhito (kazuhito@222.151.153.91) (Ping timeout)
861. # [14:14] * Quits: tH (r@87.102.6.103) (Ping timeout)
862. # [14:15] * tH_ is now known as tH
863. # [14:20] <mjs> we would do <img> and CSS images the same
864. # [14:29] * Quits: hasather (hasather@81.235.209.174) (Client exited)
865. # [14:29] * Joins: hasather (hasather@81.235.209.174)
866. # [14:32] * anne just read he's against XML
867. # [14:33] <anne> actually, against the "declarative XML stack of the W3C"
868. # [14:33] <anne> depending on what specs are part of that, I suppose it may be correct
869. # [14:34] * Joins: zcorpan (zcorpan@84.216.43.150)
870. # [14:36] <mjs> I'm not sure why HTML is imperative and XML is delcarative
871. # [14:36] <mjs> perhaps he is conflating HTML with JavaScript
872. # [14:40] <mjs> so wait
873. # [14:40] <mjs> is Sebastian saying that XML is a failure?
874. # [14:41] <mjs> or that I must be wrong about what I heard from website owners, because it would make XML a failure, and that can't possibly be true?
875. # [14:41] <anne> It also led me to think that XML had failed
876. # [14:41] <anne> Because it obviously isn't used
877. # [14:42] <anne> 0.00014% of the web sites within a set of 2 billion use it...
878. # [14:42] <anne> or was it 0.0014%?
879. # [14:43] <zcorpan> the latter i think
880. # [14:44] <mjs> is that leaving out Atom/RSS?
881. # [14:44] <anne> dunno
882. # [14:44] <mjs> and what about SVG?
883. # [14:46] <zcorpan> i would presume that Hixie didn't parse the xml... only excluded text/html feeds using the sniffing algorithm
884. # [14:47] <mjs> I wonder if Google filetype:foo searches are based on MIME type or just file extension
885. # [14:48] <zcorpan> probably file extension
886. # [14:48] <zcorpan> try rss
887. # [14:48] <zcorpan> the first hit is text/plain that looks like html
888. # [14:48] <mjs> looks like just extension
889. # [14:49] <anne> yeah
890. # [14:49] <anne> searching for filetype:foo shows that :)
891. # [14:50] * anne comes past www-html again
892. # [14:58] * Quits: tH (r@87.102.2.18) (Ping timeout)
893. # [15:13] * Quits: El (opera@203.173.1.213) (Ping timeout)
894. # [15:17] * Joins: polin8 (polin8@24.184.204.6)
895. # [15:22] <gsnedders> anne: the latter
896. # [15:22] <gsnedders> mjs: all XML
897. # [15:23] <gsnedders> mjs: or at least that was my understanding of what he said
898. # [15:26] <anne> cheers
899. # [15:26] * anne hopes to make XML less complicated
900. # [15:26] <gsnedders> mjs: looking it up, he did say all XML
901. # [15:27] <anne> maybe his search for documents was influenced by pagerank or something though...
902. # [15:28] <anne> but still
903. # [15:28] * Quits: zcorpan (zcorpan@84.216.43.150) (Ping timeout)
904. # [15:29] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
905. # [15:30] <gsnedders> I think if anything it just shows HTML's share of the web
906. # [15:31] <mjs> anyone who is confident of the number, feel free to follow up to my "less than 1%" claim with more detail if you want
907. # [15:31] * Joins: zcorpan (zcorpan@84.216.43.150)
908. # [15:32] <anne> I wonder why some people think this is about HTML versus XML
909. # [15:32] <anne> both are just strings of characters...
910. # [15:32] <anne> not very interesting
911. # [15:32] <gsnedders> or at a deeper level, a set of 0s and 1s
912. # [15:33] <gsnedders> I mean, what's different? :P
913. # [15:34] * Joins: gavin_ (gavin@74.103.208.221)
914. # [15:40] <Philip`> Maybe they're thinking of the culture/community that has built up around XML, versus the one around HTML? (e.g. XHTML5 seems very much like HTML in XML syntax, whereas XHTML2 seems to have much more of the XML spirit in its design - not that I know what that actually means...)
915. # [15:43] <anne> RDF
916. # [15:45] <Dashiva> "The XML spirit", I wonder what that really is
917. # [15:45] * Parts: hasather (hasather@81.235.209.174)
918. # [15:46] * Quits: polin8 (polin8@24.184.204.6) (Quit: :wq)
919. # [15:46] * Joins: hasather (hasather@81.235.209.174)
920. # [16:25] <anne> can't people leave the +1 somewhere on www-archive or something?!
921. # [16:26] <anne> oh well
922. # [16:26] <anne> enough web nonsense
923. # [16:26] * anne goes to play Zelda
924. # [16:26] <anne> and enjoy the weather here for a bit... quite nice in Oslo for April
925. # [16:32] * Lachy should stop writing messages that people agree with, all they do is generate +1s :-/
926. # [16:34] * Quits: mw22 (chatzilla@84.41.169.151) (Ping timeout)
927. # [16:37] * Joins: Sander (svl@80.60.87.115)
928. # [16:48] <Lachy> hmm. iCab seems to support these &brkbar; &emdash; though no other browser I tested does, so they're probably not too relevant
929. # [16:48] <krijnh> +1
930. # [16:48] <Lachy> (they're undefined in HTML)
931. # [16:49] <Lachy> crap, I forgot! I meant, I'm sure they're the most relevant entities and all browsers must take the time and effort to implement them
932. # [16:50] <Lachy> :-)
933. # [16:51] <Lachy> Lynx supports a whole bunch of enties that aren't defined in HTML http://lynx.isc.org/current/lynx2-8-7/src/chrtrans/entities.h
934. # [16:52] <krijnh> Why do we need entities again?
935. # [16:53] * Quits: mjs (mjs@64.81.48.145) (Connection reset by peer)
936. # [16:53] * Joins: mjs (mjs@64.81.48.145)
937. # [16:53] <Lachy> we probably don't, but it's interesting to know what some minor UAs support anyway
938. # [16:54] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
939. # [16:54] * Joins: gsnedders (gsnedders@86.139.123.225)
940. # [16:54] * Joins: mjs_ (mjs@64.81.48.145)
941. # [16:54] * Joins: tH (r@87.102.2.18)
942. # [16:55] * Quits: mjs (mjs@64.81.48.145) (Connection reset by peer)
943. # [16:55] * Joins: mjs (mjs@64.81.48.145)
944. # [16:55] * Quits: mjs_ (mjs@64.81.48.145) (Connection reset by peer)
945. # [17:11] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
946. # [17:16] * Joins: h3h (bfults@66.75.149.197)
947. # [17:26] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
948. # [17:36] * zcorpan notes that AMP, LT, GT and COPY are not in the tables
949. # [17:37] * Joins: mw22_ (chatzilla@84.41.169.151)
950. # [17:37] * mw22_ is now known as mw22
951. # [17:53] * Quits: Zoffix (Zoffix@99.244.41.243) (Quit: K-Lined)
952. # [18:26] * Joins: Zoffix (Zoffix@99.244.41.243)
953. # [19:16] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
954. # [19:21] * Joins: gavin_ (gavin@74.103.208.221)
955. # [19:34] * Quits: h3h (bfults@66.75.149.197) (Quit: h3h)
956. # [19:47] * Joins: MenRwtas (siko@213.7.99.228)
957. # [19:48] <MenRwtas> Hey m8s , i just want to ask you if is there a college or university for studying web design
958. # [19:50] <MenRwtas> do u know anything ?
959. # [19:51] <Zoffix> MenRwtas, I think you are asking in the wrong place.
960. # [19:51] <Lachy> MenRwtas, what made you think this would be the place to ask?
961. # [19:52] <MenRwtas> you are web standard designer which mean you are web designer which means that you studied web design
962. # [19:52] <Lachy> Try looking up information about universities in your region, wherever you are in the world, and see what they offer.
963. # [19:52] <Lachy> hmm. interesting logic.
964. # [19:52] <MenRwtas> lol thanks
965. # [19:53] <MenRwtas> Is there anything in ur country ?
966. # [19:56] <Lachy> I don't know what universities are offering for web development these days, though I hope they've improved since I finished 3 1/2 years ago
967. # [19:57] <Lachy> though I would expect something like the University of Technology Sydney (UTS) to offer something good
968. # [19:58] <Philip`> Hmm, is it just me or is http://lists.w3.org/ slightly lacking in content?
969. # [19:58] <Lachy> MenRwtas, maybe see what resources the WaSP EduTF have http://www.webstandards.org/action/edutf/
970. # [19:58] <Lachy> Philip`, the server appears to be down
971. # [19:59] <Philip`> Ah, it seems to be responding but by closing the connection without sending any data
972. # [20:00] <Lachy> well, it's an improvement from when I tried 5 minutes earlier :-)
973. # [20:01] <MenRwtas> thanks Lachy
974. # [20:11] * Parts: MenRwtas (siko@213.7.99.228)
975. # [20:16] * Quits: Ashe (Ashe@213.47.199.86) (Connection reset by peer)
976. # [20:17] * gsnedders wonders why Fx 2.0 claims to prefer ISO-8859-1
977. # [20:17] * Joins: h3h (bfults@66.75.149.197)
978. # [20:18] * Quits: xover (xover@193.157.66.5) (Ping timeout)
979. # [20:37] * Quits: myakura (myakura@60.239.122.32) (Ping timeout)
980. # [20:40] * Joins: Ashe (Ashe@213.47.199.86)
981. # [21:03] * Joins: xover (xover@193.157.66.5)
982. # [21:22] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
983. # [21:25] * Quits: Zoffix (Zoffix@99.244.41.243) (Quit: K-Lined)
984. # [21:25] * Joins: Zoffix (Zoffix@99.244.41.243)
985. # [21:27] * Joins: gavin_ (gavin@74.103.208.221)
986. # [21:51] * Joins: sbuluf (pzioji@200.49.140.20)
987. # [22:09] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
988. # [22:12] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
989. # [22:45] * Joins: hasather (hasather@81.235.209.174)
990. # [22:53] * Quits: h3h (bfults@66.75.149.197) (Quit: h3h)
991. # [23:23] * Joins: Zeros (Zeros-Elip@69.140.48.129)
992. # [23:27] * Joins: myakura (myakura@60.239.122.32)
993. # [23:30] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
994. # [23:35] * Joins: gavin_ (gavin@74.103.208.221)
995. # [23:46] * Joins: Sander (svl@80.60.87.115)
996. # Session Close: Sun Apr 29 00:00:00 2007

The end :)