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

Options:

1. # Session Start: Wed Apr 11 00:00:00 2007
2. # Session Ident: #html-wg
3. # [00:03] * Quits: adele (adele@17.255.104.79) (Quit: adele)
4. # [00:05] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
5. # [00:06] * Joins: adele (adele@17.255.104.79)
6. # [00:08] * Parts: adele (adele@17.255.104.79)
7. # [00:10] * Joins: gavin (gavin@74.103.208.221)
8. # [00:11] * anne doesn't get http://www.w3.org/mid/7D3AF0F4-CD6B-4481-8A61-24B407F173B3@gmail.com
9. # [00:11] <anne> didn't Hixie already say as much?
10. # [00:12] <Hixie> i doubt he read my mail
11. # [00:12] <anne> good for you :)
12. # [00:16] * Quits: Yudai (Yudai@59.147.29.149) (Quit: SIGTERM received; exit)
13. # [00:17] * Joins: Yudai (Yudai@59.147.29.149)
14. # [00:18] <anne> at this rate: over 1500 messages for April
15. # [00:20] <anne> Hixie, whatwg.org should probably have some URL parsing for the twitter messages
16. # [00:21] <Dashiva> Is that for just public-html, or whatwg too?
17. # [00:22] <anne> just public-html
18. # [00:23] <anne> WHATWG might reach 450 or so this month
19. # [00:23] <anne> then again, last month WHATWG had 943 e-mails
20. # [00:24] <Dashiva> Next question is how many messages are +1 :)
21. # [00:24] <anne> it's similar to public-html, if it's a topic lots of people know something about they will all chime in and generate lots of e-mail
22. # [00:24] <voluminous> I love my Gmail e-mail threading... I'd go rather insane without it.
23. # [00:24] <anne> Dashiva, heh, right
24. # [00:25] * anne can keep up without threading without much trouble...
25. # [00:25] <voluminous> anne: You have a much bigger brain than I then. ;-)
26. # [00:25] * hober prefers Gnus' threading to gmail's, but uses gmail anyway
27. # [00:25] <Dashiva> I only use the threading view when I have a lot of mails gathered up and want to read them grouped by topic
28. # [00:38] <Hixie> anne: feel free to provide code to do that
29. # [00:38] * Hixie replied to http://www.w3.org/mid/7D3AF0F4-CD6B-4481-8A61-24B407F173B3@gmail.com in www-archive
30. # [00:41] * Joins: Zeros (Zeros-Elip@67.154.87.254)
31. # [00:44] <anne> Zeros, Hixie is member of the HTML WG, obviously he would push for not making changes when he's not convinced they are necessary...
32. # [00:45] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
33. # [00:46] <Zeros> anne, And what if he thinks that all changes that contradict the WHATWG are not necessary?
34. # [00:46] <anne> as long as he convinces the rest of the HTML WG he's doing a good job :)
35. # [00:48] <Zeros> I think there's a definite conflict of interest here since both groups are working toward similar, though possibly different end results. Who's side is he going to be on if both groups come to a different consensus on an issue?
36. # [00:48] <Zeros> And I did read all his emails.
37. # [00:48] * Joins: nickshanks (nicholas@195.137.85.17)
38. # [00:49] <anne> There's a considerable overlap between the groups
39. # [00:49] <anne> But I think he already answered that question
40. # [00:50] <Hixie> Zeros: i'll be on "my" side.
41. # [00:51] <Zeros> Hixie, And seeing as you're the leader of the WHATWG would that be your side?
42. # [00:51] <Zeros> your response sidesteps my question entirely
43. # [00:51] <Hixie> the WHATWG would likely end up on my side, unless the steering committee overrides me, yes
44. # [00:51] <Hixie> but my opinion is shaped by everyone's input
45. # [00:51] <Hixie> so i don't really know what that means
46. # [00:52] <voluminous> Hixie: You're simply the bell of the tuba. It's as simple as that. :-)
47. # [00:53] <Zeros> Hixie, That still isn't clear. If the HTML WG decides on something that contradicts a feature of WHATWG's spec, what is the next step?
48. # [00:53] <Zeros> If we don't accept a feature, and implement something else?
49. # [00:54] <voluminous> Hey hey Zeros.
50. # [00:54] <Zeros> hey voluminous
51. # [00:55] <anne> Hixie is part of the HTML WG and the "we" here...
52. # [00:55] <Zeros> He's one person, yes.
53. # [00:55] <Zeros> Are we going with the consensus model then?
54. # [00:56] <Philip> If the HTML WG decides something and will not change that decision, overriding Hixie's judgement of what would be best, and the WHATWG spec is going to be a superset of the HTML WG spec (which has been stated), the only possible outcome [as far as I can tell] is for the WHATWG spec to be modified so it's compatible with the HTML WG one (even against the WHATWG's preferences)
55. # [00:56] * Quits: voluminous (voluminous@66.195.32.2) (Quit: Leaving)
56. # [00:57] <Zeros> Hixie, is that correct?
57. # [00:57] <Zeros> And is the WHATWG's judgement always going to be "correct" if we disagree?
58. # [00:57] <hober> this sounds like "Zeros: have you stopped beating your wife? Hixie: mu. Zeros: your response sidesteps my question entirely" to me
59. # [00:58] * hober though hixie's email addressed these questions quite well
60. # [00:58] <Philip> The WHATWG members will always think the WHATWG's judgement is going to be correct, because otherwise they wouldn't have made that judgement :-)
61. # [00:58] <anne> yeah, http://lists.w3.org/Archives/Public/public-html/2007Apr/0469.html should answer the above for instance
62. # [00:58] <Zeros> hober, his answers are intentionally vague and political.
63. # [00:59] <hober> Zeros: and your questions aren't? :/
64. # [00:59] <anne> lol
65. # [00:59] <Zeros> hober, I'm asking pretty clear questions
66. # [00:59] <Zeros> Is he going to side with the WHATWG is things diverge?
67. # [00:59] * anne thinks Hixie's pretty clear in his answers
68. # [01:00] * Quits: mjs (mjs@17.255.98.228) (Quit: mjs)
69. # [01:00] <Zeros> Philip, that's the exact attitude I'm talking about.
70. # [01:00] <anne> He said for instance that he will ensure that the WHATWG spec is always a strict superset
71. # [01:00] <anne> It can't be a strict superset if a change decided by the HTML WG is not made in the WHATWG document
72. # [01:00] <anne> Simple logic
73. # [01:01] <Zeros> That doesn't preclude him always siding with the WHATWG an making it his personal mission to convince anyone who disagrees with the WHATWG spec they're wrong.
74. # [01:01] <anne> What's wrong with that?
75. # [01:01] <Zeros> Why have a HTML WG at all then?
76. # [01:02] <Zeros> Might as well nominate the WHATWG as an arm of the w3 and let them handle it
77. # [01:02] <anne> If he can convince people what's wrong with that?
78. # [01:02] <Zeros> anne, He's in a position of influence and power
79. # [01:02] * Joins: mjs (mjs@17.255.98.228)
80. # [01:02] <Zeros> MS convinced the HTML WG that they needed all those extra attributes on the <object> to make ActiveX work...
81. # [01:03] <Zeros> Was there anything wrong with that?
82. # [01:03] <Philip> Zeros: That's a problem if he tries to convince people who disagree with the WHATWG spec that they're wrong, simply because it's the WHATWG spec. But it's not a problem if he tries to convince them because he thinks that solution (as described in the WHATWG spec) is the better solution.
83. # [01:03] <Zeros> As editor his goal shouldn't be to further his own agenda
84. # [01:03] <Hixie> Zeros: yes, what Philip said is correct
85. # [01:04] <Zeros> Hixie, So is the WHATWG spec always a better solution?
86. # [01:04] <Zeros> Simple question.
87. # [01:04] <anne> Zeros, MS is an implementor, not an editor
88. # [01:04] <Hixie> Zeros: better for who?
89. # [01:04] <Hixie> Zeros: i'm not sure what you mean
90. # [01:04] <Hixie> Zeros: obviously if i thought that the whatwg work was less good than the html wg work, i'd not do the whatwg work
91. # [01:05] <Zeros> So there's room to override a WHATWG decision?
92. # [01:05] <anne> there has been no such thing as a WHATWG descision btw so far
93. # [01:05] <Zeros> anne, So hixie just decides for them?
94. # [01:05] <Philip> I believe no WHATWG decisions are final - they can always be changed if new arguments and better solutions are provided
95. # [01:06] <Hixie> i don't understand the question. If the HTML WG spec says something, then the WHATWG spec will be compatible with it, regardless of what process the HTML WG takes to go there, for as long as the HTML WG spec is considered by browser vendors to be a relevant and important spec.
96. # [01:06] <anne> Zeros, no, the specification incrementally evolves based on feedback towards a way that people like
97. # [01:06] <Zeros> heh
98. # [01:06] <anne> Philip, yup
99. # [01:06] <Zeros> Hixie side steps the yes or no again and says "the two specs will be compatible"
100. # [01:07] <Hixie> i don't understand what i'm side stepiing
101. # [01:07] <Hixie> stepping
102. # [01:07] <hober> Zeros: perhaps you could state your question in an, err, answerable way
103. # [01:07] <anne> and he says "i don't understand the question"
104. # [01:08] <Zeros> Hixie, If the HTML WG decides something different, are you going to have the WHATWG change their spec? (Yes or no) or are you going to push the HTMLWG to reconsider? (yes or no)
105. # [01:08] <Hixie> Zeros: yes and yes
106. # [01:08] <Zeros> ah
107. # [01:09] <Zeros> That's my issue right there then. If we decide anything different the editor automatically takes it on to tell us the other group who we're cooperating with is right.
108. # [01:10] <Hixie> no
109. # [01:10] <Zeros> okay
110. # [01:10] <Hixie> because even if the other group didn't exist, i would still be making the exact same argument
111. # [01:10] <Hixie> it has nothing to do with the WHATWG
112. # [01:10] <Hixie> if the HTMLWG makes a decision that i disagree with, then i would have been arguing against it
113. # [01:10] <Hixie> that's what being in a working group is
114. # [01:11] <Hixie> since i'm editor of the WHATWG spec, and i write the spec to my opinion, my opinion being based entirely on research, discussions, case studies, etc, the whatwg spec always agrees with me (once i get around to editing it anyway)
115. # [01:11] <Hixie> my opinion changes as people convince me i'm wrong
116. # [01:12] <Zeros> So its HixieML
117. # [01:12] <Hixie> in the same way that XBL2 is HixieML, and that CSS2.1 is HixieML, and that Selectors is HixieML, sure
118. # [01:12] <Hixie> it's also AnneML
119. # [01:12] <Hixie> and LachlanML
120. # [01:12] <Hixie> and AppleML, and MozillaML, and MicrosoftML, and so forth
121. # [01:12] * Dashiva blames Hixie for the CR status on CSS2.1
122. # [01:12] <anne> I'm at 2.0, actually
123. # [01:12] <Zeros> Weren't there other editors on CSS2.1?
124. # [01:13] <Zeros> The more editors the less bias that ends up in the spec as a result of any one person
125. # [01:13] <Hixie> Zeros: yes, and they, like me, argued for changes to the spec when they disagreed with the spec
126. # [01:13] <Hixie> the more editors, the more messed up and crappy the spec is, imho
127. # [01:13] <Zeros> Hixie, Yes, but your personal opinion held less weight there. That'd be like BosCelikHicksonLieCSS
128. # [01:14] <hober> Zeros: it sounds like you would prefer whoever edits to not be a wg member, is that right?
129. # [01:14] * hober thinks such an arrangement would be very strange
130. # [01:14] <Hixie> my personal opinion is based ENTIRELY on the opinion of the people who put forward use cases and stuff
131. # [01:14] <Zeros> hober, no.
132. # [01:14] <Zeros> hober, I'd prefer the editor not be a single person.
133. # [01:15] <Hixie> you seem to think that i have a personal opinion that is irrational or unrelated to what people say
134. # [01:15] <Zeros> And that the editors be from different vantage points.
135. # [01:15] <hober> That sounds like a good recipe for a bad spec...
136. # [01:16] <anne> I think that multiple editors leads to a poor specification
137. # [01:16] <Zeros> A single editor leads to a specification that reflects the editor's personal agenda
138. # [01:16] <anne> Why?
139. # [01:16] <Hixie> Zeros: um
140. # [01:16] <Zeros> And every person has opinions color their judgement. Hixie isn't immune to bias
141. # [01:16] <anne> If that would happen the editor would be fired
142. # [01:16] <anne> so to say
143. # [01:16] * Joins: sbuluf (eewq@200.49.140.131)
144. # [01:17] <Zeros> anne, Not if that editor convinced everyone they were right
145. # [01:17] <Zeros> like you said
146. # [01:17] <Hixie> Zeros: my personal agenda is "make a spec that is the best thing for web authors, implementors, and users, based on research, case studies, use cases, and feedback, regardless of origin"
147. # [01:17] <Zeros> Of course in 4 years that could be entirely different.
148. # [01:17] <Zeros> You seem to be advocating a dictatorship for all w3 decisions
149. # [01:17] <hober> Zeros: if the editor convinced everyone they were right, and they were in fact not right, how is that at all different if that editor had been merely a wg member?
150. # [01:17] <Hixie> maybe it would help if you could point to something i've decided that you think shows my bias
151. # [01:18] <Zeros> hober, I never suggested they shouldn't be a w3 member. I'm not sure what you're replying to.
152. # [01:18] <anne> reread what he just wrote
153. # [01:18] <hober> err
154. # [01:18] <Hixie> i don't understand the difference between me convincing everyone that i'm right when i'm the editor and when i'm not.
155. # [01:18] <hober> Hixie: exactly
156. # [01:18] <Hixie> either way, the spec reflects my "personal agenda"
157. # [01:19] <Zeros> Hixie, As it is now everyone needs to convince *you* that their right.
158. # [01:19] <Zeros> Since the spec by default is going to be your creation
159. # [01:19] <Zeros> You said "let me write it" and then "people can argue what I write" effectively
160. # [01:19] <Hixie> no
161. # [01:19] <Hixie> i said "tell me what you want and i'll write it"
162. # [01:20] <Zeros> okay
163. # [01:21] <Hixie> if i write something about people disagree with it and i won't change it, i won't last long as editor
164. # [01:21] <Hixie> about which people disagree, even
165. # [01:21] <Hixie> er
166. # [01:21] <Hixie> let me try again.
167. # [01:21] <Hixie> if i write something and people disagree with it and i won't change it, i won't last long as editor
168. # [01:22] <Zeros> hober, And it is different. Since the process now is People -> Hixie -> Spec, all feedback is channeled through him into the spec. That is different than if he was just one of the people providing feedback
169. # [01:22] <Zeros> Either way, I'm satisfied. Thank you for discussing this with me Hixie.
170. # [01:22] <Hixie> not if i convince everyone i'm right, which i'd have to do if i was editor too, otherwise i wouldn't be editor for long
171. # [01:23] <Hixie> np
172. # [01:27] <sbuluf> hixie, i see at least two problems in your statements. i can either talk, or not. since i'm somewhat external to this wg, i rather ask you if you are interested in hearing it, else i will shut up. up to you. the default is not.
173. # [01:28] <Hixie> sure
174. # [01:28] <sbuluf> first one: "otherwise i wouldn't be editor for long" <--i believe this is naive. no disrespect whatsoever to you, but ...well, i can ampliate if necessary
175. # [01:29] <Hixie> how is it naive?
176. # [01:29] <sbuluf> when i say "whatsoever", i mean it
177. # [01:29] <Hixie> (no offense taken)
178. # [01:29] <Hixie> you think people would let me be editor if i was blatently ignoring feedback?
179. # [01:29] <sbuluf> hixie...there are lots of politics in these processes
180. # [01:29] <sbuluf> yep
181. # [01:29] <sbuluf> there are massive particular interests, and politics
182. # [01:30] <sbuluf> so i'm afraid i have to say yes
183. # [01:30] <Hixie> how? i mean, you think the 300+ people on the group wouldn't complain?
184. # [01:30] <sbuluf> they might complain yes. not necessarily they would be heard, though
185. # [01:31] <Hixie> you think the w3c would support me in my ignoring of feedback?
186. # [01:31] <Hixie> they'd probably be the first group to try and get rid of me
187. # [01:31] <sbuluf> they might yes. i guess it depends on the extentx, and particular cases.
188. # [01:32] <sbuluf> i could add that they would *not* want to piss people who pay their bills off, however, that much is definitely true
189. # [01:32] <Dashiva> Well, in that case it isn't relevant to Hixie being editor, it's just politics in general
190. # [01:32] <Hixie> i suppose it would be possible for the universe to go through some sort of "opposite day" cataclysmic event and for my opinions and the opinions of w3c staff to actually line up such that if i ignored feedback they would actually support me
191. # [01:32] <sbuluf> but even then, if they can manage, they might, i think
192. # [01:32] <Hixie> but it seems highly unlikely
193. # [01:32] <Hixie> what was the other problem?
194. # [01:33] * Joins: Lachy_ (chatzilla@220.245.91.147)
195. # [01:33] <sbuluf> (i do not quite think we need to go cataclysimic, many have been ignored befoire in many w3c processes)
196. # [01:33] <sbuluf> the other problem is:
197. # [01:33] <anne> (SVG comes to mind, surprisingly enough!)
198. # [01:33] <sbuluf> <Hixie> Zeros: my personal agenda is "make a spec that is the best thing for web authors, implementors, and users, based on research, case studies, use cases, and feedback, regardless of origin"
199. # [01:34] <sbuluf> imho, that sentence has a problem (perhaps can be clarified to avoid ambiguity)
200. # [01:34] <sbuluf> the problem is that what is desirable to end-users, is not necessarily the same that is desirable for everyone else
201. # [01:34] <sbuluf> hence, there is an unresolved tension there, i think
202. # [01:35] <Hixie> sbuluf: i'm one of the first people to be ignored by the w3c, though, which is why i think it's unlikely they'd support me.
203. # [01:35] <hober> sbuluf: isn't that addressed by PrioityOfConstituencies?
204. # [01:35] <Hixie> sbuluf: yes, it is a problem -- we can't ever get everyone to agree on everything. That's part of what makes my job so fun.
205. # [01:36] <sbuluf> hixie, i think that might have been the case before. but i think timbl gave up, and created this very group. that means endorsment (al least somewhat) to me, see?
206. # [01:36] <sbuluf> fun? you have a sense of humour. i don't envy you =P
207. # [01:38] <sbuluf> i can add oe thing, regarding the w3c proces and end-users
208. # [01:38] <Hixie> i'm pretty sure that the creation of the html wg did not improve most w3c staff's opinion of me personally, if anything i'd assume that being effectively cornered into such an "endorsement" as you put it would only make matters worse
209. # [01:39] <sbuluf> in the w3c process a "standard" amounts to a consensous about check paying corporations. end-users do not get a vote. nobody quite represents them, whatever appearances might be
210. # [01:39] <sbuluf> hixie,t agreed. but they did.
211. # [01:39] <hober> sbuluf: I think N-hundred public invited experts means users will get more of a voice in HTMLWG than they have before
212. # [01:40] <sbuluf> voice. but not vote.
213. # [01:40] <Hixie> yeah
214. # [01:40] <Hixie> it's not clear that's going to be a problem
215. # [01:40] <sbuluf> hence i spoke about "apparent things"
216. # [01:40] <Hixie> i think if 300+ people were ignored by the w3c, the resulting mess in the blogosphere would cause the w3c a lot of damage
217. # [01:41] <sbuluf> hixie, well...the process will happen, and since nobody defends end-users interestes, nothing much will happen, in my opinion. it *does* involve you statement, however, which was my point
218. # [01:41] <sbuluf> (i'm skeptical about blogosphere effectiveness, myself, i'm afraid)
219. # [01:42] <Hixie> the blogosphere is how we ended up with an html working group.
220. # [01:42] <Hixie> and if the w3c really does go off the rails and ignore users, we have the whatwg to take over again, anyway.
221. # [01:42] <Hixie> so i'm not really worried.
222. # [01:42] <sbuluf> hixie,more particularly, take "end-users out of your sentence, and it becomes practically coorrect, oterwise, it is attackable, imho
223. # [01:43] <Hixie> i personally care about the end users
224. # [01:43] <Hixie> so i wouldn't take it out
225. # [01:43] <anne> impl too
226. # [01:44] <sbuluf> you might. the process, however, doesn't quite do it. no end-user representation (i.e, votes) is one expression of that. scores of end users ignored in w3c mailing lists all over, is another
227. # [01:44] <Hixie> sure, but my sentence was about my _personal_ agenda
228. # [01:44] <Hixie> i can't do anything about the w3c's agenda
229. # [01:45] <sbuluf> correct
230. # [01:45] <sbuluf> i see
231. # [01:46] <sbuluf> i *might* argue about the seriousness of your care for end-users. i think being honest, i need to say that (again, no ofense intended. none). i can expand if required.
232. # [01:47] <sbuluf> please do not see this as attack, it isn't, not personally. i just happen to have thught much about end-user's pov
233. # [01:47] <Hixie> please feel free to always expand, and don't worry that i would take anything as an attack
234. # [01:47] <Hixie> i have a very thick skin
235. # [01:47] <Hixie> the users are the real reason for the web
236. # [01:48] <Hixie> without the users, we don't really have anything
237. # [01:48] <Hixie> so the users are paramount, imho
238. # [01:48] <sbuluf> thanks. no matter skin thickness, i do not intend to do nothing undue.
239. # [01:48] <sbuluf> mm, yes, we could agree on that. but without citizens, same would happen with countries. however...you do not seriously think say bush cares at all about citizens, right?
240. # [01:49] <Hixie> some people are shortsighted
241. # [01:49] <sbuluf> ever so right.
242. # [01:50] <sbuluf> perhaps i should illustrate a little: as of 2007, we still have no way for end users to write content half-decently
243. # [01:50] <sbuluf> more particularly...we are still demanding end users to hand code
244. # [01:50] <Hixie> HTML5 defines contenteditable
245. # [01:50] <sbuluf> (else, they can use wysiwyg editors, sure, but the code they output, is usually bad)
246. # [01:51] <sbuluf> i'm afraid more would be needed. the discussion of that particular point might turn longuish, however.
247. # [01:51] <hober> writing a wysiwyg tool that outputs high-quality markup is Hard. I don't see what the WG can do about that -- it's a fundamentally hard thing to try to do
248. # [01:51] <sbuluf> (i have no problems myself, but you might)
249. # [01:52] <sbuluf> hober...i agree. furthermore, with today's specs, might even be technically impossible.
250. # [01:52] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
251. # [01:52] <sbuluf> hober...but see my point, then?
252. # [01:53] <Hixie> bbiab
253. # [01:53] <hober> I think WA1.0 makes some amount of progress, at least insofar as its conformance requirements take wysiwyg tools into account in a pragmatic way
254. # [01:53] <sbuluf> we are, in practical terms, condemning decazillions of grandmothers to have to ever see the code. to learn the languages, at all.
255. # [01:53] * Parts: hasather (hasather@81.235.209.174)
256. # [01:53] <sbuluf> hixie, k.
257. # [01:54] * Joins: karl (karlcow@128.30.52.30)
258. # [01:54] <Dashiva> Well, when you say code, I immediately drift into JS mode
259. # [01:55] <sbuluf> dashiva, i do not quite follow. what do you mean?
260. # [01:55] <sbuluf> (i meant html, baically. perhaps also css)
261. # [01:55] <Dashiva> There's a sequence of increasingly difficult aspects of web technology
262. # [01:55] <Dashiva> How much should grandma be able to do? How much is it realistic to hope for?
263. # [01:56] <sbuluf> a good and decent question. i think we could manage for her to be able to do a tremendous lot more then she can today
264. # [01:57] <sbuluf> and as you well pointed, we can't quite keep adding more and more specs, indiscriminately, without thinking on the most precius resource in the whole web: grandma's mind.
265. # [01:57] <sbuluf> html? css? xml? rdf? xslt?...how many?
266. # [01:58] <sbuluf> *who* really ensures that this does not get out of control in grandma's head?
267. # [01:58] <Dashiva> I think most people consider grandma to be the business of the editor creators
268. # [01:58] <anne> blogs and such make it trivially for people to start contributing content
269. # [01:59] <sbuluf> dashiva, your very sentence worries me. no ofense, no problems, but...see? who is really more important here?
270. # [02:00] <sbuluf> anne, partially true. not trivial. and incomplete. but are you going to call our conversatrion "silly" after a while? if so...should i keep talking?
271. # [02:00] * Quits: hober (ted@69.45.6.105) (Quit: ERC Version 5.2 (IRC client for Emacs))
272. # [02:01] <anne> sbuluf, heh
273. # [02:01] <Dashiva> sbuluf: I'm not sure I can agree. This WG deals with markup, the very markup grandma is not supposed to see. We are completely abstracted away from her world.
274. # [02:01] <sbuluf> again, no ofenses intended. really. i hope you can see it.
275. # [02:02] <anne> I don't really have an opinion on end users. It's hard for to imagine at what level they'd interact with HTML. I tend to think it would be completely abstracted away from them.
276. # [02:02] <anne> for me*
277. # [02:02] <anne> *on end users in the context of the HTML language
278. # [02:03] <anne> so what Dashiva says I think
279. # [02:03] <sbuluf> dashiva, partially true, i'd say. on one hand, we could allow standard makers to just say )as usual) "is someone else's problem. comfy, isn't it? but the end result is this "as of 12007, grandma is in trouble" So should we not start questioning the wisdom of all this? again, who ensures gloabl coherence?
280. # [02:03] <gavin_> what does "end users" mean in the context of the HTML specification?
281. # [02:04] <Dashiva> sbuluf: But how are we supposed to help grandma? W
282. # [02:04] <gavin_> people browsing the web?
283. # [02:04] <anne> yeah
284. # [02:04] <sbuluf> dashiva, on the other hand...does it not affect the spec? are you sure we could do wymiwyg editors, with today's spec? have you considered the problem? particularly, a UI?
285. # [02:05] <Dashiva> As much as I've considered the problem, I consider it practically impossible regardless of the spec
286. # [02:05] <anne> whatever editor there will be, it has to export to HTML at some point
287. # [02:06] <sbuluf> dashiva, a fair enough answer. but...have we devoted concerted time to explore possibnilities? shouldn't we, at least? i might add i mihgt have some ideas about it. i'm no expert, however, can't do it alone.
288. # [02:07] <sbuluf> anne...something not too far away from xopus, might perhaps work. i can expad too.
289. # [02:07] <sbuluf> *expand
290. # [02:07] <Dashiva> I think a wymiwyg editor is a close cousin of the semantic web
291. # [02:07] <Dashiva> They might be possible, but the users form an apparently unsurmountable obstacle
292. # [02:07] <sbuluf> dashiva...yep, somehow. do you think that is bad, though?
293. # [02:08] <Dashiva> I have no faith in the semantic web, myself
294. # [02:08] <sbuluf> noty trivial, dashiva, right.
295. # [02:09] <sbuluf> dashiva, is very questioned, and qwuestionable, right. we could discuss it, anytime. i think at least some ideas are sound, or at least desirable, myself.
296. # [02:09] <Dashiva> I'll leave the discussion to the pros. Until they make some breakthroughs, I'll remain a grumpy young naysayer :)
297. # [02:10] <sbuluf> i'm no expert either =P
298. # [02:10] * Parts: kingryan (rking3@66.92.187.33)
299. # [02:11] <anne> yeah, until someone has made a non-wysiwyg editor that's actually widely adopted by "typical" end users there's not much point in debating it I think
300. # [02:12] <anne> and afaik people have tried to do that and failed
301. # [02:13] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
302. # [02:13] <sbuluf> the problem might be impossible with today's scpecs. they were not thought with that idea as a design goal, precisely.
303. # [02:13] <sbuluf> but i talked too much here already, so i'll shut up. one last thought: unless wymiwyg edtors, beware of including words about caring about end users.
304. # [02:13] <Dashiva> Then the semanticists need to get on the soapbox and tell us what we need to change
305. # [02:13] <anne> end users care about wysiwyg typically
306. # [02:14] <anne> identical results everywhere and such
307. # [02:14] <anne> (visually)
308. # [02:14] <sbuluf> (i could answer...i just do not want to abuse)
309. # [02:15] <Dashiva> I think we all agree it's a noble cause, we just have different degrees of hope
310. # [02:16] <anne> (I also don't think the problem is with the HTML specification. Editors not contrained by HTML also haven't really solved this problem.)
311. # [02:16] * Quits: nickshanks (nicholas@195.137.85.17) (Quit: nickshanks)
312. # [02:17] <sbuluf> anne, we could discuss it, if you wanted. something not to far away from xopus *might* work
313. # [02:18] * Joins: gavin (gavin@74.103.208.221)
314. # [02:18] <anne> feel free to e-mail public-html, www-archive or some other list I follow with persuasive arguments
315. # [02:18] * anne will go to bed now
316. # [02:19] <sbuluf> good night (i tried that, unfortunately, last time tim berners lee himself ignored me)
317. # [02:23] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
318. # [02:25] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
319. # [02:28] <sbuluf> http://lists.w3.org/Archives/Public/www-tag/2006Nov/0077.html <--for those curious, this is me asking timbl for w3c to make a browser (wymiwyg, or similar, perfect code generation, semantic web ready, etc)
320. # [02:29] * Joins: DanC_lap (connolly@128.30.52.30)
321. # [02:29] <sbuluf> hope you do well, danc. we heard.
322. # [02:29] <DanC_lap> hi. thanks.
323. # [02:30] * Joins: myakura (myakura@60.239.122.32)
324. # [02:30] * DanC_lap wonders if karl is around
325. # [02:31] <DanC_lap> I thought the influx of new WG members would die off a bit after hixie's blog post, but it's been weeks and they continue to come in at about the same rate
326. # [02:31] <karl> yes. on 3 discussions on 3 channels
327. # [02:32] <DanC_lap> have you sent anything to www-html@w3.org, karl? I don't think I ever did
328. # [02:32] <karl> hmmm... you mean recently?
329. # [02:33] <DanC_lap> since March 7
330. # [02:33] <karl> hmm I guess one or two mails.
331. # [02:33] <DanC_lap> RRSAgent, pointer?
332. # [02:33] <RRSAgent> See http://www.w3.org/2007/04/11-html-wg-irc#T00-36-43-1
333. # [02:33] <DanC_lap> was either of them an announcement about the new HTML WG?
334. # [02:33] <karl> I don't think
335. # [02:33] <karl> let me check
336. # [02:33] <DanC_lap> RRSAgent, make logs world-access
337. # [02:33] <RRSAgent> I have made the request, DanC_lap
338. # [02:34] <karl> http://www.w3.org/Search/Mail/Public/advanced_search?keywords=&hdr-1-name=subject&hdr-1-query=&hdr-2-name=from&hdr-2-query=karl%40w3.org&hdr-3-name=message-id&hdr-3-query=&index-grp=Public__FULL&index-type=t&type-index=www-html&resultsperpage=20&sortby=date
339. # [02:35] <karl> 3 messages and not announcements about HTML WG
340. # [02:36] <karl> the last message was a message about someone asking about HTML 4.01
341. # [02:36] <karl> so I said to contact the public-html.
342. # [02:36] <karl> but that's all
343. # [02:37] <karl> do you want me to announce the HTML WG on www-html?
344. # [02:37] <DanC_lap> umm... yes, I'd like that.
345. # [02:37] <karl> ok. on my todo pile for today
346. # [02:38] <karl> * 305 group participants,
347. # [02:38] <karl> * 305 in good standing,
348. # [02:38] <karl> * 44 participants from 16 organizations
349. # [02:38] <karl> * 261 Invited Experts
350. # [02:38] <karl> I have some people queued for today too.
351. # [02:39] <karl> I wish we had more Authoring tools developers, and CMS as well
352. # [02:39] <DanC_lap> yeah...
353. # [02:39] <karl> just to improve the ecosystem, having more diversity and variety of inputs.
354. # [02:39] <DanC_lap> any volunteers to write rousing blog articles to encourage CMS folks to join the WG?
355. # [02:40] <karl> I could do that on QA Weblog or maybe I wonder if WASP could help on this.
356. # [02:40] <DanC_lap> perhaps a message to public-evangelist@w3.org would help?
357. # [02:40] <karl> wonder what is the best strategy
358. # [02:41] <DanC_lap> I lean toward the shotgun approach: use all of the above
359. # [02:41] <karl> maybe QA weblog and asking the community to promote the information and to ask people to bug their favourite tool developers to join
360. # [02:42] * karl is not violent ;) shotflower would do better for me
361. # [02:42] <DanC_lap> better if we can give reasons why joining will help the CMS vendors. nobody likes to be bugged
362. # [02:44] <DanC_lap> I have vague impressions that there are accessibility concerns around <canvas>. Anybody have pointers to coherent arguments?
363. # [02:45] <karl> I wonder if we could get people from Pages, iWeb, Mail.app (Apple), FrontPage (Microsoft), Dreamweaver, Golive (Adobe), Textmate, BBedit, etc.
364. # [02:46] * Joins: heycam (cam@130.194.72.84)
365. # [02:47] <DanC_lap> any idea if Mail.app folks will be at the html-email workshop, karl?
366. # [02:47] <karl> no idea. I asked maciej if he could give me a contact in Mail.app Team, but no luck :)
367. # [02:47] <DanC_lap> the evolution email compose thingy is pretty good. I wonder if they're tuned in
368. # [02:48] <karl> and I wonder who is doing the ThunderBird authoring part.
369. # [02:48] <DanC_lap> Dreamweaver... is there a good connection between them at WASP these days?
370. # [02:49] <karl> hmmm I can ping them
371. # [02:50] <Philip> DanC: there are some comments about <canvas> accessibility a little way down http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-May/006394.html - I don't think I've seen any other relevant points, though I've not been watching at all comprehensively
372. # [02:54] <DanC_lap> thanks Philip
373. # [02:54] <karl> maybe Charles McCathieNeville (Opera, ex WAI-W3C) has done an evaluation of accessibility concerns with canvas.
374. # [02:55] <DanC_lap> ah; he's an obvious person to ask, in any case
375. # [02:55] <DanC_lap> I should do that
376. # [02:56] <DanC_lap> I took the versioning thing to www-tag; the answers are mostly "it depends". I guess I should ask a more specific question
377. # [02:57] <DanC_lap> going over the differences between http://esw.w3.org/topic/HTML/ProposedDesignPrinciples and /TR/webarch is slow going. I hope I can get more people involved so that it doesn't stop when I take one in the eye
378. # [02:57] <karl> QA hat - I have the feeling that versioning is important for documents, in the same way that signing it or dating it is important. Now what certain class of products should do with the version number is a different matter.
379. # [02:58] <DanC_lap> simplicity argues for "no; documents should not bear version numbers". I think there are arguments to the contrary, but no strong ones have been articulated yet.
380. # [02:58] <DanC_lap> i.e not bothering with version numbers is simpler than bothering with them.
381. # [02:59] <karl> one of the reasons in terms of forward compatibility. I have the belief that our design choice of today might not be respected in future generations
382. # [02:59] <DanC_lap> as you said, karl, there's an implicit version # in every document: the date it was written.
383. # [03:00] <DanC_lap> yes, it's true that design choices of today might not be respected in the future; but the cost of guarding against that risk is considerable, and it's not clear how much effort is worthwhile.
384. # [03:02] <DanC_lap> a big part of me says "HTML is that language that everybody that does web stuff agrees to. When that agreement breaks down, HTML becomes worthless. so be it."
385. # [03:04] <karl> yep. pretty much the same. I hear different opinions here and there on what is HTML, or should be HTML. My only concerns are when "macho style discussions". Some people will not say interesting things because they are afraid of answers or reputations.
386. # [03:04] <karl> my main struggled is how to ensure that everyone has the possibility to express himself/herself
387. # [03:05] <karl> s/struggled/struggle/
388. # [03:05] <DanC_lap> on a totally different topic: I wonder about a survey about focus areas: test suite development, testing browser X/Y/Z, reviewing the spec as a teaching tool, etc. In fact, I wonder about a separate mailing list for new features. I don't want to hear about them until a proposal has reached some maturity.
389. # [03:06] <DanC_lap> or maybe a separate mailing list for test suite development, and I'd focus on that one.
390. # [03:08] <DanC_lap> maybe I'll start a wiki topic on tasks for HTML WG members
391. # [03:08] <mjs> karl: I think you should assume Apple's reps represent all of our various interests in HTML, and will be in close touch with other teams as appropriate
392. # [03:08] <DanC_lap> and after some wiki-brainstorming, turn it into a WBS survey
393. # [03:08] <mjs> karl: for Mail in particular, the WebKit team does more work on their HTML composition than they do
394. # [03:10] <karl> mjs: could you talk then about the HTML in mail workshop, that would be cool. Daniel Glazman is the chair.
395. # [03:10] <mjs> hi DanC_lap, hope you're feeling better
396. # [03:10] <DanC_lap> do KDE/KHTML and WebKit share new code these days? I wonder if I should recruit KHTML participation
397. # [03:10] <mjs> DanC_lap: there is a Qt port of WebKit, but classic KHTML still exists for now
398. # [03:10] <DanC_lap> somewhat better, thanks. sort of a stupid way to get hurt. very painful and scary all the same.
399. # [03:11] <mjs> I've asked people from both constituencies and none of them think they have time
400. # [03:12] <DanC_lap> you asked fairly recently?
401. # [03:12] <DanC_lap> if so, you saved me the trouble ;-)
402. # [03:12] <mjs> yes, fairly recently
403. # [03:13] <DanC_lap> I should probably ask them anyway... but I should do a lot of things. Since you asked, I think I'll give that pretty low priority.
404. # [03:14] <mjs> karl: I'm not sure what W3C workshops actually do, so I'm not sure what I would be getting them into
405. # [03:14] <mjs> I do want to make sure that any HTML WG specs for HTML are usable for mail
406. # [03:14] <DanC_lap> on a good day, W3C workshops get some exposure to good ideas that deserve more exposure, and get groups who are doing similar work but didn't know it in touch with each other.
407. # [03:15] <DanC_lap> they also collect data on quesitons like "how many people care enough about HTML and email to devote a couple days and a plane ticket on it"
408. # [03:17] <DanC_lap> they're somewhat random by nature. they're intended to introduce a bit of brownian motion into things.
409. # [03:18] * DanC_lap starts to wind down
410. # [03:19] <DanC_lap> karl, anything you want/need before I wander off?
411. # [03:19] <DanC_lap> oh, and it's been said, but it bears repeating: mjs, thanks for collecting all the bits and pieces about HTML5 and putting it in one proposal
412. # [03:19] <karl> nope I think I have already a huge pile of things to iron before the next laundry ;)
413. # [03:21] <mjs> DanC_lap: really I was just the secretary for the people whose names are at the bottom
414. # [03:22] <mjs> DanC_lap: Apple rarely sends engineers to travel to things so generally it would have to be high value
415. # [03:22] <DanC_lap> well, secretarial work is too often thankless work. so thanks.
416. # [03:22] <DanC_lap> yeah, travel decisions are tough
417. # [03:26] * DanC_lap wanders off...
418. # [04:00] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
419. # [04:06] * Joins: Shunsuke (kuruma@133.27.63.42)
420. # [04:10] * Joins: Shunsuke_ (kuruma@133.27.63.42)
421. # [04:11] * Quits: Shunsuke (kuruma@133.27.63.42) (Ping timeout)
422. # [04:15] * Quits: Shunsuke_ (kuruma@133.27.63.42) (Ping timeout)
423. # [04:16] * Joins: htmlr (htmlr@203.206.237.84)
424. # [04:19] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
425. # [04:24] * Joins: gavin (gavin@74.103.208.221)
426. # [04:41] * Joins: Zeros (Zeros-Elip@69.140.48.129)
427. # [04:43] * Quits: myakura (myakura@60.239.122.32) (Quit: Leaving...)
428. # [04:43] * Joins: adele (adele@67.170.236.225)
429. # [04:43] * Parts: adele (adele@67.170.236.225)
430. # [04:53] * Quits: mjs (mjs@17.255.98.228) (Quit: mjs)
431. # [05:00] * Joins: foca (foca@190.64.22.120)
432. # [05:04] * Quits: Philip (excors@80.177.163.133) (Quit: Philip)
433. # [05:37] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
434. # [05:38] * Joins: Shunsuke (kuruma@133.27.53.98)
435. # [05:40] * Quits: sbuluf (eewq@200.49.140.131) (Ping timeout)
436. # [05:41] * Joins: myakura (myakura@60.239.122.32)
437. # [05:50] * Joins: sbuluf (ugl@200.49.140.36)
438. # [05:54] * Joins: dbaron (dbaron@63.245.220.242)
439. # [06:27] * Quits: foca (foca@190.64.22.120) (Ping timeout)
440. # [06:30] * Quits: marcos (chatzilla@131.181.148.226) (Connection reset by peer)
441. # [06:49] * Joins: foca (foca@190.64.22.120)
442. # [06:50] * Parts: foca (foca@190.64.22.120)
443. # [07:25] * Quits: Shunsuke (kuruma@133.27.53.98) (Ping timeout)
444. # [07:27] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
445. # [07:32] * Joins: gavin (gavin@74.103.208.221)
446. # [07:42] <karl> http://esw.w3.org/topic/HTMLAsSheAreSpoke
447. # [07:43] * karl wonder if we could reach some of the people here and if we could create a better list.
448. # [07:48] <Zeros> karl, I'm pretty sure Webkit has a lot of test cases for the HTML parser
449. # [07:48] <Zeros> I'm sure Mozilla does too
450. # [07:49] <Zeros> So much of its ad hoc when a page that's broken is found too...
451. # [07:50] <Zeros> karl, there should be a HTML parser committee of the browser vendors where people can submit inconsistencies or pages that are broken and then everyone can come to a solution.
452. # [07:51] <karl> Zeros: yes that's cool. But I'm greedy. I would like to have more than browser vendors.
453. # [07:51] * Joins: mjs (mjs@64.81.48.145)
454. # [07:51] <karl> I would like to have people who are *producing* HTML and not consuming *HTML*
455. # [07:52] <karl> They have their own constraints, difficulties, and I think their input would be good for the ecosystem of the group.
456. # [07:52] <Zeros> karl, ah okay. I'm just for consistency.
457. # [07:52] <sbuluf> karl, would contacting news organizations be of use for you?
458. # [07:52] <mjs> FWFI, my team at Apple is both a producer and consumer of HTML
459. # [07:52] <Zeros> Right now everyone implements their own fixes for how to handle broken content.
460. # [07:53] <mjs> WebKit is not only a browser engine but also an HTML editing engine, used among other things to create content in Mail and Aperture
461. # [07:53] <Zeros> For example people fix the DOM on bad markup in different ways. HTML needs a big "bug tracker" where failure conditions and solutions can be agreed upon to be implemented.
462. # [07:53] <karl> mjs: that is very good to hear.
463. # [07:54] <karl> When I edit an HTML mail in Mail.app, does it produce valid HTML or XHTML code?
464. # [07:54] <karl> I haven't checked this, I should.
465. # [07:54] <mjs> karl: it produces what I hope is valid HTML
466. # [07:54] <mjs> although our markup output is a bit wonky at times
467. # [07:54] * gavin_ looks up FWFI, figures it must be a typo, and is a little bit disappointed
468. # [07:55] <karl> hehe gavin: invalid English acronym ;)
469. # [07:56] <Zeros> karl, no doctype. some other things are a little weird. Does look like its respecting block vs. inline elements.
470. # [07:57] <Zeros> Doesn't look like it creates <p> elements, makes a lot of divs, spans and brs
471. # [07:57] <Zeros> Interesting it uses -khtml-nbsp-mode: space; and -khtml-line-break: after-white-space; too
472. # [07:58] <mjs> we use weird techniques to get whitespace behavior to be what users expect in a text editor
473. # [07:59] <Zeros> Oh, that prevents white-space collapsing?
474. # [07:59] <karl> mjs, as in more than using CSS?
475. # [08:00] <Zeros> karl, the email I have from outlook (maybe exchange server) is worse. <HTML><BODY><PRE></PRE></HTML><!DOCTYPE ... then the document with lots and lots of font tags.
476. # [08:01] <Zeros> At least Mail.app is a head of that.
477. # [08:01] * Zeros wonders what Thunderbird generates
478. # [08:03] * myakura checks
479. # [08:06] <karl> hmmm we should send an email on the list, with a kind of simple mail template. with an image and one or two colours. and ask people to test vers HTML implementation in their email clients. Then we could send these files to the list
480. # [08:08] <mjs> karl: alternating space and non-breaking space (which all HTML mail composers do afaik) plus a few nonstandard CSS properties to make it work even more nicely in Mail.app
481. # [08:11] <myakura> Tb2 generates <!DOCTYPE...><html><head></head><body bgcolor...> and message w/ b, i, u and etc.
482. # [08:12] <myakura> breaks in <br>, i see no <font>
483. # [08:13] <Zeros> I wonder they don't put the subject line in the <title> element
484. # [08:14] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
485. # [08:15] <Lachy_> Zeros: probably because mail clients don't pay any attention to the title element anyway
486. # [08:15] <myakura> thinking that it's enough w/ Subject:?
487. # [08:16] <Zeros> myakura, HTML requires a <title> anyway
488. # [08:16] <Zeros> I was just thinking of ways to use it
489. # [08:17] <myakura> ah, yeah. totally fogotten about that..
490. # [08:22] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
491. # [08:26] * karl sent to himself an HTML email made with mail.app
492. # [08:27] * Quits: htmlr (htmlr@203.206.237.84) (Quit: htmlr)
493. # [08:31] <Zeros> mjs, is there a way to get Mail.app to groups threads on the subject line?
494. # [08:32] <Zeros> People are forking the discussion and changing the subject and mail still groups them, so I have 63+ email long threads that weave in and out of topics.
495. # [08:32] <mjs> Zeros: it does have thread grouping, but I don't believe there is a way to customize what rule it uses to put things in a thread
496. # [08:34] <Zeros> ah okay
497. # [08:35] * Joins: heycam (cam@203.214.79.176)
498. # [08:41] * Quits: Lachy_ (chatzilla@220.245.91.147) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919])
499. # [08:43] <karl> Zeros: the thread grouping is made on subject line and not on the References: and In-Reply-To: headers
500. # [08:43] <karl> unfortunately
501. # [08:44] <karl> which means if a few people are sending mails which are completely unrelated with the same subject:
502. # [08:44] <Zeros> karl, In Mail.app its not grouping on the subject line for me
503. # [08:44] <karl> Mail.app groups them
504. # [08:44] <Zeros> karl, its grouping on something else
505. # [08:44] <karl> huh
506. # [08:45] <Zeros> karl, http://services.ath.cx/inbox.png is the kind of thing I'm getting
507. # [08:45] <mjs> Zeros: I usually see a new thread when someone changes the Subject line
508. # [08:45] <Zeros> its pretty weird
509. # [08:46] <mjs> I totally don't see all that stuff in the innerHTML thread
510. # [08:46] <karl> oh no then it does in-reply-to AND subject
511. # [08:46] <Zeros> I wonder why mjs's is different
512. # [08:46] <karl> I see why for simple users how it could be useful.
513. # [08:47] <mjs> mine seems to be strictly Subject
514. # [08:47] <karl> I wish it does only in-reply-to
515. # [08:48] <karl> I also wish I could configure my Smart Mailbox with more options (rule A and rule B) and NOT rule C
516. # [08:48] <karl> or (rule A or rule B) and NOT rule C
517. # [08:48] <karl> or more filtering on headers
518. # [08:48] <karl> anyway it is kind of off-topics ;)
519. # [08:48] <mjs> you can make more than one rule that has the same result
520. # [08:49] <mjs> though that's admittedly a pain sometimes
521. # [08:49] <Zeros> Rules can't move into a smart mailbox I don't think
522. # [08:49] <karl> rules and Smart Mailbox have differents UI
523. # [08:50] <Zeros> I wonder if its something gmail is sending that is causing the grouping this way mjs
524. # [08:50] * Joins: loic (loic@90.27.90.144)
525. # [08:50] <karl> basically my mail is in a imap dated space, and all my *topic* mailboxes are smart mailboxes
526. # [08:50] * Joins: tylerr (tylerr@24.16.148.66)
527. # [08:51] * Joins: marcos (chatzilla@131.181.148.226)
528. # [08:52] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
529. # [08:52] * Joins: Voluminous (voluminous@24.16.148.66)
530. # [09:12] <karl> <HTML>
531. # [09:12] <karl> <BODY>
532. # [09:12] <karl> <HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Hi,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="font-size: 13px;
533. # [09:12] <karl> etc.
534. # [09:12] <Zeros> yep
535. # [09:12] <Zeros> not valid
536. # [09:13] <mjs> what's invalid about that?
537. # [09:13] <myakura> no <title> either
538. # [09:13] <Zeros> mjs, missing the title
539. # [09:13] <Zeros> html, head and body are all optional, but title is required
540. # [09:14] <mjs> a <title> is of dubious value for a Mail message, but I suppose it could put an empty one or use the subject line
541. # [09:15] * Joins: anne (annevk@81.68.67.12)
542. # [09:15] <karl> or it could put the subject of the message itself maybe
543. # [09:15] <anne> morning
544. # [09:16] <Zeros> karl, have you looked at the css limitations for outlook 2007?
545. # [09:16] * karl has not touched a windows machine for 7 years
546. # [09:17] <Zeros> http://msdn2.microsoft.com/en-us/library/aa338201.aspx
547. # [09:17] <Zeros> raises a lot of questions for how useful HTML is going to be; Mail.app in leopard adds html templates, but Outlook 2007 supports rather limited subset of css
548. # [09:17] <karl> if I tried to validate forcing the doctype to be HTML 4.01 Transitional
549. # [09:17] <karl> i have 12 errors
550. # [09:18] <karl> no alt on images, and the missing doctype and title create problems
551. # [09:19] <mjs> The doctype and title would be easy to fix (if it does not make other mail clients barf) but adding a made-up alt value would probably do more harm than good
552. # [09:19] <mjs> (as would forcing the user to type something whenever they paste an image)
553. # [09:19] <karl> mjs: yes for the title it requires more UI modification.
554. # [09:20] <mjs> so probably the alt requirement is not appropriate for HTML email
555. # [09:20] <karl> it's why I'm always interested by authoring tools requirements
556. # [09:20] <karl> s/title/alt/
557. # [09:20] <mjs> since the value of making my email to my friends theoretically more accessible is surely outweighted by the cost of typing alt values
558. # [09:21] <karl> mjs it depends on the type of friends you have. But it would be better to ask someone who has real needs for accessibility and using mail app
559. # [09:22] <sbuluf> does any mail app generate not just html, but also easily separatable css? (to an external stylesheet, or to easily editable UI) if not, shouldn't they?
560. # [09:22] <mjs> karl: if I were sending personal email to a blind friend I probably would not include photos
561. # [09:22] <karl> sbuluf: the css is put on each element not in a style element
562. # [09:22] <Zeros> Or describe the photo yourself below it mjs
563. # [09:22] <mjs> and if I had both visually impaired and normally visioned friends that I wanted to Cc on the same email, I'd include the photo and a description in the text
564. # [09:23] <mjs> alt seems unlikely to be good for email unless you are mailing a pre-existing web page
565. # [09:23] <karl> yes it seems a fair approach
566. # [09:23] <karl> mjs: which seems to make the point that there is different class of products with different requirements even for renderers
567. # [09:24] <mjs> karl: this seems more like a content generation issue than a rendering issue
568. # [09:25] <karl> the HTML document would not be valid in the end if no alt.
569. # [09:25] <mjs> you have to either have multiple conformance classes for documents (maybe private vs. public?) or accept that HTML email won't be conforming HTML
570. # [09:25] <mjs> or you give up on alt being mandatory
571. # [09:25] <karl> I vote for 1.
572. # [09:25] <Zeros> mjs, adding a doctype, title and alt="" would make that valid
573. # [09:25] <karl> different conformance requirements depending on the products
574. # [09:25] <Zeros> Outlook already adds an empty title and a doctype
575. # [09:26] <mjs> Zeros: well, adding alt="" would be, in my opinion, more harmful than helpful
576. # [09:26] <Zeros> mjs, how does that differ than no alt at all?
577. # [09:26] <mjs> while it satisfies the letter of the rule, it surely does not satisfy the spirit
578. # [09:26] <karl> conformance requirements are not things to enforce but more a guide on what you need to implement depending on the circumstances.
579. # [09:26] <mjs> it's like cargo cult conformance
580. # [09:26] <mjs> having an empty-valued alt attribute gives you none of the benefits
581. # [09:26] <Zeros> mjs, it prevents inconsistencies. If we don't think alt should be required then it shouldn't be required.
582. # [09:27] <Zeros> Adding special markup rules for every type of renderer just makes implementing a HTML UA harder
583. # [09:27] <karl> Zeros: I think alt="" would be harmful in this case as mjs says
584. # [09:27] <Zeros> I still don't see where its harmful
585. # [09:27] <karl> specifically if the mail goes from mail user agent to Web pages.
586. # [09:27] <Zeros> no alt and alt="" give the same meaning
587. # [09:28] <anne> no it doesn't
588. # [09:28] <karl> alt="" means "ignore completely the image"
589. # [09:28] * Joins: edas (edaspet@88.191.34.123)
590. # [09:28] <anne> alt="" means no content
591. # [09:28] <anne> no alt means there's no alternative content for the image
592. # [09:28] <karl> usually used for spacer and things of this type
593. # [09:28] <karl> ooops I have to catch a train.
594. # [09:28] <Zeros> anne, how does no content and no alternative content differ?
595. # [09:29] <mjs> hmmm
596. # [09:29] <Zeros> you just added the word alternative
597. # [09:29] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
598. # [09:29] <mjs> if empty alt is allowed, then no alt should probably be allowed as well
599. # [09:29] <mjs> the point of requiring alt is supposed to be to encourage accessible authoring, but adding alt="" doesn't satisfy that goal at all
600. # [09:29] <mjs> anyway, would be good for someone to capture these thoughts on the mailing list
601. # [09:30] <Zeros> The validator could still warn, and the spec could encourage its use without making it invalid to not use it.
602. # [09:30] <mjs> is <title> the only mandatory element?
603. # [09:30] <anne> Zeros, it means that the user agent can tell the user there's an image but no alternate content was provided for it
604. # [09:30] <anne> Zeros, for instance, it could read out the URL used to retrieve the image
605. # [09:30] <Zeros> anne, it could do the same for alt=""
606. # [09:30] <anne> Zeros, that would be non-conforming
607. # [09:31] <Zeros> anne, the spec says alt is required. Not having at all is non-conforming.
608. # [09:31] <mjs> Web Apps 1.0 allows alt="" but not missing alt, and says missing alt should be treated same as empty-valued alt
609. # [09:32] <Zeros> :)
610. # [09:32] <anne> That makes the distinction pretty useless
611. # [09:32] <mjs> it says empty alt should mean: "In such cases, the image could be omitted without affecting the meaning of the document."
612. # [09:33] <mjs> I don't think that will be true for end-user-authored HTML emails that contain images
613. # [09:33] <mjs> so adding empty-valued alt would technically be nonconforming
614. # [09:33] <mjs> perhaps the alt requirement should be omitted for content generated by a WYSIWYG editor
615. # [09:33] <Zeros> mjs, how does that apply to dreamweaver then?
616. # [09:34] <Zeros> I'm not sure HTML's rules for conformance should be dependent on who's generating it.
617. # [09:34] <mjs> I don't think dreamweaver is the sort of thing intended to be covered by the wysiwyg exception for <font> tags
618. # [09:34] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
619. # [09:35] <Zeros> mjs, what's the issue with style attributes for fonts?
620. # [09:35] * Quits: Voluminous (voluminous@24.16.148.66) (Connection reset by peer)
621. # [09:36] <Zeros> in a context where a style block isn't possible I guess, and the font needs to be encoded right there
622. # [09:36] <mjs> Zeros: I actually think style should be retained as a global attribute but I haven't heard a lot about the arguments for removing it
623. # [09:36] <mjs> the <font> element in HTML5 is the only thing allowed to have a style attribute
624. # [09:36] <mjs> and is meant to be used for presentational inline styling done by WYSIWYG editor
625. # [09:36] <mjs> s
626. # [09:37] <Zeros> mjs, that invalidates a whole lot of existing web content that uses style
627. # [09:37] <mjs> yes, it does
628. # [09:37] <mjs> (though presumably the rendering section will say UAs must support it on everything)
629. # [09:37] <Zeros> I can't say I agree with undeprecating <font>
630. # [09:38] * Joins: gorme (gorm@213.236.208.22)
631. # [09:39] <anne> It's undeprecated for WYSIWYG editors as it appears they need it
632. # [09:39] * marcos wonders which WYSIWYG editors still use it?
633. # [09:39] <mjs> well, having an official way to do presentational markup seems like the best way to handle the classes of content generators that need to make presentational markup
634. # [09:39] <anne> However, that whole section is in its very early stages at this point
635. # [09:39] <anne> marcos, contenteditable / designMode geneates it
636. # [09:39] <anne> generates*
637. # [09:40] <marcos> k, that makes sense then
638. # [09:40] <Zeros> contenteditable in safari generates spans IIRC
639. # [09:41] <Zeros> mjs, what's to prevent all the content on the web from ending up full of font tags again if its created with in browser WYSIWYG editors?
640. # [09:41] <mjs> Zeros: I doubt the front page of cnn.com will ever be made that way
641. # [09:42] <Zeros> mjs, blogs probably would be, news sites? wikis?
642. # [09:42] * anne doesn't think lots of <span> elements intended for presentation is really better than lots of <font> elements
643. # [09:42] <sbuluf> what about spans with only predefined css classes? would that be an improvement?
644. # [09:43] <mjs> Zeros: well, you can't get WYSIWYG editors to make purely semantic markup, since the very concept of such a thing is presentational
645. # [09:43] <anne> <span class=red>
646. # [09:43] <anne> maybe in amount of bytes...
647. # [09:43] <mjs> <span class="-user-style-1">
648. # [09:43] <anne> however, <font color=red> interoperates better
649. # [09:44] <Zeros> And makes restyling the page from a content editor's perspective a nightmare
650. # [09:44] <Zeros> anyone saving the source of that document is going to get older styles if they override it too
651. # [09:45] <Zeros> font[color=red] { color: blue; }
652. # [09:45] <mjs> html mail clients have special requirements, since they have to generate markup that can be handled by a wide variety of really bad layout engines
653. # [09:45] <gorme> \o Whats the rationale behind the header and footer element ?
654. # [09:45] <mjs> the html engines in many popular mail readers are far worse than popular browsers
655. # [09:45] <mjs> gorme: a lot of web documents have a header and a footer
656. # [09:46] <Zeros> mjs, How does that come into play with Mail 3.0's HTML templates? Do they cater to those old clients?
657. # [09:46] <Zeros> Seems like Apple is pushing HTML mail and MS is fighting it
658. # [09:46] <mjs> for instance on http://amazon.com/ you can probably pick it out
659. # [09:47] <mjs> Zeros: I can't talk about Mac OS X features that haven't shipped yet
660. # [09:47] <mjs> Apple is pushing the possibility of rich text email, because people like to communicate with more than just plaintext
661. # [09:48] <Zeros> mjs, Well from your personal perspective. If you were writing a mail client with html templates for users, what audience of UAs would you be targeting and where would you draw the line on support?
662. # [09:48] <mjs> I think Outlook switching to the Word engine to compose and display HTML email isn't necessarily a vote for or against HTML email
663. # [09:48] <Zeros> Like, would you use <center>?
664. # [09:48] <mjs> thogh it is certainly a vote against standards compliance
665. # [09:48] <mjs> Zeros: I can't really talk about it at that level of detail, sorry
666. # [09:48] <Zeros> alright
667. # [09:49] <Zeros> I can see the point of needing some kind of control, but at the same time HTML5 lets you put <style> elements in the body of the document
668. # [09:49] <Zeros> So why can't a Visual editor generate that instead?
669. # [09:49] <sbuluf> <span class="foreing term> would allow to define another font, another colour, size, and what not. but wouldn't the difference with a font tag be that all those rules can be moved from the middle of the text to an style element, or even to an external stylesheet, hence keeping presentational data separated from content?
670. # [09:49] <Zeros> or line styles I guess
671. # [09:49] <Zeros> inline*
672. # [09:50] <anne> sbuluf, you don't know what you're marking up
673. # [09:50] <anne> Zeros, <style scoped> is a pretty new feature
674. # [09:50] <mjs> sbuluf: but users don't pick "foreign term" from the Font menu
675. # [09:50] <mjs> they pick Italic
676. # [09:51] <Zeros> anne, even if it wasn't scoped. Provided the generated content is bound by an id you could target that specific chunk of the document
677. # [09:51] <sbuluf> msj, what if you allow users to define classes (a bunch of style rules), and let them name them with semantic names, and then pick those names from a drop down?
678. # [09:51] <Hixie> someone should mail the img/alt thing to the whatwg list so i don't forget about it
679. # [09:52] <mjs> Hixie: I was gonna
680. # [09:52] <Hixie> it does make sense to me to have different rules for e-mails than web content
681. # [09:52] <mjs> does email need different rules than WYSIWYG-generated content in general?
682. # [09:52] <mjs> (not sure a priori)
683. # [09:52] <mjs> so is <title></title> the shortest valid HTML document?
684. # [09:53] <sbuluf> hixie, mjs, as a side note...wouldn't setting that info in some wiki be better then just the mailing list? it could later be more orderly transformed into rationale material
685. # [09:53] <mjs> or do you need a doctype in there too (for HTML4)
686. # [09:53] <Hixie> the distinction is in the receive, not hte producer, imho
687. # [09:53] <mjs> well, it's not very useful for a WYSIWYG blog post editor to add alt="" when you past in an image either
688. # [09:54] <Hixie> shortest HTML4 document that is conforming is <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"><title>A</title><p>A
689. # [09:54] <Hixie> a blog post would have to cater for blind users (e.g. search engines, if nothing else)
690. # [09:54] <Zeros> mjs, the body can't be empty
691. # [09:55] <mjs> well, it could prompt you at paste time to type a description
692. # [09:55] <Hixie> so would need alt text that represented the image (which might be alt="" if the image adds nothing that isn't in the prose, but merely repeats it in a different way)
693. # [09:55] <Hixie> alt= is not a description
694. # [09:55] <mjs> but it's hard to imagine users prefering such an editor
695. # [09:55] <Hixie> the HTML5 spec defines <img> very carefully
696. # [09:55] <Hixie> <img> represents _text_ with an _alternative image representation_
697. # [09:56] <Zeros> nice wording
698. # [09:56] <mjs> that's a weird way to define it
699. # [09:56] <Zeros> makes sense to me
700. # [09:56] <mjs> but I guess that would make <img> unsuitable for WYSIWYG editors
701. # [09:56] <mjs> since when the user drags in an image from their desktop, they definitely do not intend the semantic of "text with an alternative image representation"
702. # [09:58] <Hixie> most images on most sites, especially graphics-heavy sites made with WYSIWYG packages, should be in the CSS layer.
703. # [09:58] <Zeros> mjs, "If this image doesn't display in the receiver's client, enter text to display instead: " would work for WYSIWYG editors.
704. # [09:59] <Hixie> mjs: anyway i'd love to discuss this over lunch sometime, but i'm going afk for now
705. # [09:59] <Hixie> ttyl
706. # [09:59] <Zeros> "If your mail recipient can't view this image..."
707. # [09:59] <mjs> later
708. # [10:02] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
709. # [10:05] * Joins: icaaq (icaaaq@85.228.55.162)
710. # [10:08] * Joins: ROBOd (robod@86.34.246.154)
711. # [10:47] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
712. # [11:13] * Quits: myakura (myakura@60.239.122.32) (Quit: Leaving...)
713. # [11:14] <anne> http://www.digital-web.com/articles/html5_xhtml2_and_the_future_of_the_web/
714. # [11:14] <anne> "HTML5 (also sometimes referred to as Web Applications 1.0)" heh
715. # [11:16] * Quits: edas (edaspet@88.191.34.123) (Ping timeout)
716. # [11:21] <MikeSmith> anne - clearly a polemic, though a well written one
717. # [11:21] <mjs> I just saw that on digg
718. # [11:21] * Quits: beowulf (carisenda@91.84.50.132) (Ping timeout)
719. # [11:22] <anne> I think it's accurate though. People more often call it HTML5
720. # [11:24] <anne> The comment always say you cannot use this for business stuff etc. but then Y! Pipes is using <canvas> already.
721. # [11:25] <anne> Or how browser vendors will support XHTML2
722. # [11:26] <anne> At this point it should be pretty clear that no browser vendor has much interest in that
723. # [11:26] <anne> s/comment/comments/
724. # [11:27] * Joins: hasather (hasather@81.235.209.174)
725. # [11:29] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
726. # [11:39] * Joins: htmlr (htmlr@203.206.237.84)
727. # [11:45] * Joins: heycam (cam@203.214.79.176)
728. # [11:56] <gsnedders> woah. despite having been around David (the author of that article) on several forums and mailing lists for several years, I've _never_ seen a photo of him before
729. # [12:01] <sbuluf> i fail to see what is polemic about this article. it might be due to my particular pov, though.
730. # [12:16] * Parts: hasather (hasather@81.235.209.174)
731. # [12:26] <anne> I think that statement was about my quote and not the article
732. # [12:29] <sbuluf> oh, i see thanks.
733. # [12:35] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
734. # [12:38] * Quits: sbuluf (ugl@200.49.140.36) (Quit: sbuluf)
735. # [12:39] * Joins: hasather (hasather@81.235.209.174)
736. # [13:10] * Joins: xover (xover@193.157.66.5)
737. # [13:12] * Joins: edas (edaspet@88.191.34.123)
738. # [13:50] * Parts: icaaq (icaaaq@85.228.55.162)
739. # [14:06] * Quits: loic (loic@90.27.90.144) (Ping timeout)
740. # [14:13] * Parts: hasather (hasather@81.235.209.174)
741. # [14:14] * Joins: hasather (hasather@81.235.209.174)
742. # [14:21] * Joins: loic (loic@90.29.116.63)
743. # [14:28] * Parts: claudio (claudioc@89.97.35.74) (Leaving)
744. # [14:28] * Joins: claudio (claudioc@89.97.35.74)
745. # [14:30] * Quits: claudio (claudioc@89.97.35.74) (Client exited)
746. # [14:32] * Joins: claudio (claudioc@89.97.35.74)
747. # [14:33] * Joins: Philip (excors@80.177.163.133)
748. # [14:41] * Joins: myakura (myakura@60.239.122.32)
749. # [14:43] * Quits: claudio (claudioc@89.97.35.74) (Quit: Leaving)
750. # [14:44] * Joins: claudio (claudioc@89.97.35.74)
751. # [15:01] * Joins: txm (tmcmahon@68.229.88.25)
752. # [15:27] * Parts: txm (tmcmahon@68.229.88.25)
753. # [15:38] <anne> Openwave joined the HTML WG with two participants
754. # [15:39] * Lachy looks up who they are and what they do
755. # [15:40] <anne> Mobile browser
756. # [15:40] <Lachy> is it any good, or just one of the bad ones?
757. # [15:41] <anne> Ask MikiSmith
758. # [15:41] <anne> Mike even
759. # [15:42] <anne> he worked for them before he joined Opera before he joined W3C
760. # [15:43] <Lachy> well, it's good that they've joined. Mobile browsers definately need to participate more
761. # [15:48] * Quits: htmlr (htmlr@203.206.237.84) (Quit: htmlr)
762. # [15:57] * Joins: Lachy_ (Lachlan@124.168.27.56)
763. # [16:00] * Quits: Lachy (Lachlan@124.168.25.222) (Ping timeout)
764. # [16:11] * Joins: DanC_lap (connolly@128.30.52.30)
765. # [16:20] * Quits: marcos_ (chatzilla@203.206.31.102) (Ping timeout)
766. # [16:21] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
767. # [16:23] * Joins: marcos_ (chatzilla@203.206.31.102)
768. # [16:28] * Joins: Shunsuke (kuruma@219.110.80.235)
769. # [16:32] * Quits: marcos_ (chatzilla@203.206.31.102) (Ping timeout)
770. # [16:32] * Joins: beowulf (carisenda@91.84.50.132)
771. # [18:41] * Disconnected
772. # [18:41] * Attempting to rejoin channel #html-wg
773. # [18:41] * Rejoined channel #html-wg
774. # [18:41] * Topic is 'W3C HTML WG http://www.w3.org/html/wg/ - http://krijnhoetmer.nl/irc-logs/ (logged) - http://esw.w3.org/topic/HTML/ProposedDesignPrinciples'
775. # [18:41] * Set by anne on Tue Mar 27 12:28:46
776. # [18:51] * Joins: Zeros (Zeros-Elip@204.97.106.226)
777. # [18:59] * Joins: kingryan (rking3@66.92.187.33)
778. # [19:03] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
779. # [19:08] * Joins: zcorpan (zcorpan@84.216.42.112)
780. # [19:22] <h3h> I think I implicitly assumed that the spec would be as detailed as possible, largely targeted at implementors, and there would be companion documents like "guides", "tutorials", "references" for web authors, etc.
781. # [19:23] <h3h> which is essentially what Dan outlined
782. # [19:23] <h3h> but with the assumption that the spec is for implementors first
783. # [19:23] <zcorpan> i was thinking about having a view of the spec that hides everything that only applies to implementors, probably using the status script for that
784. # [19:24] <zcorpan> but it's hard to figure out with script which parts don't apply to authors
785. # [19:24] <h3h> sounds like a maintenance nightmare
786. # [19:24] <zcorpan> could be
787. # [19:24] <h3h> I'd rather there be a separate document specifically tailored to authors, with plenty of cross-links back to the spec
788. # [19:25] <h3h> that would be the document that would get the PR
789. # [19:25] <zcorpan> yeah, i think there's a spot in the whatwg wiki for such a thing
790. # [19:25] <zcorpan> PR?
791. # [19:26] <h3h> public relations
792. # [19:26] <h3h> (press)
793. # [19:26] <zcorpan> ok
794. # [19:26] <h3h> I'd expect how-to sites, blog posts, etc. to link to the guide document rather than the spec itself
795. # [19:27] <h3h> so now I wonder if the guide document needs an editor of its own
796. # [19:27] <zcorpan> why not have it in a wiki?
797. # [19:27] <h3h> it would seem prudent, for consistent tone and clarity
798. # [19:27] <h3h> a wiki will always be fragmented and non-official
799. # [19:28] <h3h> I think it could easily be developed on a wiki
800. # [19:28] <zcorpan> such a document couldn't be normative anyway
801. # [19:28] <h3h> but when the spec is published, there should be some published guide version that's been edited for tone, content, etc.
802. # [19:28] <h3h> it doesn't need to be normative, just descriptive
803. # [19:28] <h3h> it would defer to the spec for all normative issues
804. # [19:28] <h3h> with links
805. # [19:29] <h3h> and I hesitate to say "document" because I think all of these should be split up into several HTML pages with a table of contents and inter-linking
806. # [19:29] <h3h> the worry about the WA 1.0 draft being too large is extremely valid, IMO
807. # [19:30] <h3h> it's very cumbersome and clumsy
808. # [19:30] * zcorpan doesn't think it's a problem
809. # [19:30] <zcorpan> in fact i prefer it being a single document
810. # [19:31] * h3h shrug
811. # [19:31] <h3h> I wouldn't mind too much if the spec stayed a single document
812. # [19:31] <h3h> but the guide definitely needs to be divided into chapters
813. # [19:31] <h3h> each on a separate page
814. # [19:31] <zcorpan> sure
815. # [19:32] <h3h> right now the page weight is 447KB
816. # [19:32] <zcorpan> knock yourself out: http://wiki.whatwg.org/index.php?title=Tutorials&action=edit
817. # [19:32] <h3h> heh :)
818. # [19:33] <Philip> I have a script that extracts some sections from the WA1 spec into a smaller file, so it doesn't take forever to load and crash browsers - I might try modifying that to make a split-up copy of the whole spec, so it's easier to read small parts of it
819. # [19:36] <h3h> so I guess the summary of what I'd like in an ideal world would be for this WG's shining public achievement to be a comprehensive HTML 5 Guide, geared specifically toward web authors; the spec itself being a more technical deliverable and not nearly as public
820. # [19:36] * anne prefers a single doc too
821. # [19:36] <h3h> "not as public" meaning "not to receive as much press"
822. # [19:37] <h3h> of course it would still be a public document
823. # [19:37] * DanC_lap wanders off ot rest his eyes a bit
824. # [19:37] * Parts: DanC_lap (connolly@128.30.52.30) (Leaving)
825. # [19:39] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
826. # [19:41] <anne> I think the HTML spec should be aimed at authors as well
827. # [19:41] <anne> I don't expect that most authors will look there, but it should state clearly all the requirements on authors etc.
828. # [19:41] <h3h> sure
829. # [19:42] <anne> I personally think that tutorials are best left up to the community
830. # [19:42] <h3h> but I don't think it should be the primary point of reference for authors
831. # [19:42] <zcorpan> why not?
832. # [19:42] <h3h> speaking directly to the previously raised concern that the W3C's specs are too technical
833. # [19:42] <anne> As everyone has different viewpoints on how such a tutorial should be structured.
834. # [19:42] <anne> From the ground up, for authors familiar with HTML4, for authors familiar with XML, etc.
835. # [19:42] * Joins: Hixie (ianh@129.241.93.37)
836. # [19:42] * Joins: Voluminous (Voluminous@66.195.32.2)
837. # [19:43] <h3h> I guess I'm not convinced that one generalized guide wouldn't fulfill all of those viewpoints in a reasonable manner
838. # [19:43] <h3h> with the spec as backup
839. # [19:43] <anne> Write a guide and contribute it to the WG
840. # [19:43] <anne> I suppose there's nothing wrong with having an HTML Primer
841. # [19:43] <h3h> if only I were paid to work on that full time, I would :)
842. # [19:43] <anne> w3.org/tr/html-primer or something
843. # [19:44] <h3h> I wasn't really thinking of a primer
844. # [19:44] <zcorpan> you could start at the wiki
845. # [19:44] <h3h> primer would be more like "tutorial" for me
846. # [19:44] <h3h> and I'm advocating more of a reference-style guidfe
847. # [19:44] <h3h> it's all nebulous in my head anyway
848. # [19:45] <anne> what's a reference guide?
849. # [19:45] <h3h> let me see if I can find an example
850. # [19:45] <anne> it describes each feature in simple language + example?
851. # [19:47] <h3h> yeah
852. # [19:47] <h3h> essentially
853. # [19:47] <h3h> in a narrative format, but not in a contiguous linear format like a book
854. # [19:48] <h3h> also, "simple language" is emphatically non-technical to a degree
855. # [19:48] <h3h> a high school student should be able to read the whole thing and understand everything
856. # [19:49] <gsnedders> *cough* there are high school students who are members of the WG, and are in the process of implementing the WHATWG draft */cough*
857. # [19:49] <gsnedders> but I guess I'm in the minority :)
858. # [19:50] <gsnedders> something like the RSS Profile draft though? <http://www.rssboard.org/rss-profile>
859. # [19:50] <h3h> yes, absolutely
860. # [19:50] <h3h> er, let me check
861. # [19:50] <h3h> eh...they have the TOC + examples down
862. # [19:50] <h3h> but there's no narrative
863. # [19:50] <h3h> like "when should I use this element/attribute?"
864. # [19:51] <h3h> and issues surrounding those types of questions
865. # [19:51] <gsnedders> doesn't the "The x element provides the x of the channel" cover that?
866. # [19:51] <gsnedders> as to when you should use it?
867. # [19:51] <h3h> sure, in spec world
868. # [19:51] <h3h> but for a new-to-HTML 5 web author? no
869. # [19:52] <gsnedders> how else can you phrase it? "The <title> element provides the title of the feed"?
870. # [19:52] <h3h> looking for an example :)
871. # [19:52] * Quits: Zeros (Zeros-Elip@204.97.106.226) (Quit: This computer has gone to sleep)
872. # [19:52] <gsnedders> or something further like, "The <title> element provides the title of the feed when directly within the <channel>, and the title of an item when directly within an <item>"?
873. # [19:54] <h3h> like this... http://www.genevaconventions.org/
874. # [19:54] <h3h> but with markup examples, obviously
875. # [19:55] <h3h> and yes, more like your last quote
876. # [19:56] <h3h> it's like... a glossary mashed up with a TOC, a narrative and examples
877. # [19:56] <h3h> that's the best I can come up with right now
878. # [19:57] <h3h> it shouldn't be (or look) auto-generated in the least
879. # [19:57] <h3h> it should look like it was written as a book
880. # [19:57] <h3h> but be devoid of the start-to-finish continuity of a typical book
881. # [19:58] <Philip> Is something like http://canvex.lazyilluminati.com/wa1/index.xhtml an approximately useful way of splitting the spec into non-enormous readable chunks?
882. # [19:59] <Philip> (Er, I'll change it from XHTML back to HTML when I find an HTML serialiser, to make IE users happy)
883. # [19:59] <h3h> Philip: yeah, works for me
884. # [20:00] <h3h> Philip: with prev/next/up/home links added
885. # [20:01] <gsnedders> Philip: how does it actually split it up?
886. # [20:01] <anne> if someone writes a script that does the splitting up and keeps all the references working...
887. # [20:01] <gsnedders> x.y sections?
888. # [20:02] <anne> we might be getting somewhere
889. # [20:02] <Philip> It's splitting on all <h2> and <h3> elements
890. # [20:02] <Philip> Navigation links/<link>s would be handy - I'll try add those
891. # [20:02] <Philip> anne: I believe that's what I've done :-)
892. # [20:02] <gsnedders> it'd probably be better to do it splitting it in other places, but that would require some sort of intelligence
893. # [20:03] <h3h> I think that works surprisingly well at first glance
894. # [20:03] <Philip> (As far as I can tell, the broken references are the ones that have always been broken, like links to references)
895. # [20:03] <Philip> (and the rest get redirected to the right page)
896. # [20:04] <Philip> The biggest sections are the parsing and embedded ones - probably the latter could be split up more
897. # [20:05] <Philip> (This is from an old copy before the recent <video> changes, so maybe that's got even bigger now)
898. # [20:05] <zcorpan> Philip: is this generated by script?
899. # [20:06] <Philip> zcorpan: Yes - it's just Python/minidom/html5lib
900. # [20:07] <zcorpan> cool
901. # [20:08] <Philip> I'll try to fix some bits and upload it later this evening, in case it's helpful
902. # [20:09] <h3h> definitely, and reply with a link to the thread that was talking about splitting it up, if you want
903. # [20:09] <Philip> Does the list still accept mails from non-members?
904. # [20:10] <h3h> no idea
905. # [20:10] <Philip> I'll try it and see what happens :-)
906. # [20:11] <Philip> *away for a while*
907. # [20:11] <anne> public-html should
908. # [20:12] <anne> Philip, btw, cool!
909. # [20:12] <anne> Philip, maybe you can let Hixie use it so he can generate multiple versions of the spec
910. # [20:18] * Quits: claudio (claudioc@89.97.35.74) (Ping timeout)
911. # [20:18] * Joins: claudio (claudioc@89.97.35.74)
912. # [20:24] <anne> Philip, should be pretty trivial to get HTML serialization from html5lib
913. # [20:24] <anne> Philip, I don't think it's supported by default though
914. # [20:26] * Joins: hober (ted@69.45.6.105)
915. # [20:39] <jgraham> Philip / anne: We could certainly add a HTMLSerializer class to each treebuilder imp. without much difficulty (I was kinda planning to rearrange how that stuff works, at least in the case of SimpleTree nyway).
916. # [20:41] <anne> if you modify --xml or --hilite you get it
917. # [20:42] <anne> oh, you want to redo that, fine
918. # [20:43] <anne> in theory you'd just use innerHTML
919. # [20:54] <Philip> *away for a while*
920. # [20:54] <Philip> Whoops
921. # [20:54] <Philip> *back*
922. # [20:55] <Philip> anne: I'd be fine with Hixie using it - it sounds like it would probably be worthwhile
923. # [20:56] <Philip> I have a HTML5-innerHTML-like serialiser (based on one of the html5lib serialisers) that I did a while ago and which seems to work, so I'll just stick that in for now
924. # [20:57] <anne> it will shut down all the people who complain about file size :)
925. # [20:57] <anne> what are they thinking reading specs from mobile phones anyway :p
926. # [20:58] <zcorpan> oh no! scrollbars! completely inaccessible
927. # [20:59] <anne> it's the same person complaining about style sheets
928. # [20:59] <anne> iirc
929. # [20:59] <anne> maybe he should just get a browser that renders it without scrollbars :)
930. # [20:59] <anne> or get a bigger screen
931. # [21:03] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
932. # [21:03] * Joins: anne (annevk@86.90.70.28)
933. # [21:16] <anne> For those interested in XHTML2: http://www.w3.org/mid/op.tqmvnxh3smjzpq@acer3010.lan
934. # [21:24] <gsnedders> Philip: the parsing section could also be cut down into input stream/tokeniser/tree builder at least
935. # [21:26] * Joins: Sander (chatzilla@80.60.87.115)
936. # [21:35] <Philip> http://canvex.lazyilluminati.com/wa1/ - now in non-X HTML, plus some links and things
937. # [21:35] <gsnedders> re-reading HTML 4.01, it's even more hopeless than I remember
938. # [21:35] <anne> maybe drop the top template for subsequent pages?
939. # [21:36] <gsnedders> how many elements actually have normative definitions!?
940. # [21:36] <anne> see the e-mail from dbaron about HTML4 being a list of desired features
941. # [21:37] * Parts: asbjornu (asbjorn@84.48.116.134)
942. # [21:37] <Philip> Is it worth keeping the title/logo/copyright/etc on the subsequent pages?
943. # [21:37] <gsnedders> yeah, I've seen that already
944. # [21:37] <anne> Philip, I think keeping the title and the date might be
945. # [21:37] <gsnedders> most W3C specs don't have anything more than previous/next/TOC
946. # [21:38] <anne> Philip, for heading consistency and awareness of what you're reading
947. # [21:39] <anne> otherwise you'd have to remap the headings as well and fix the style sheets etc.
948. # [21:45] <Philip> I've cut down the header now
949. # [21:45] <gsnedders> are there actually _any_ implementers involved in XHTML2?
950. # [21:47] <anne> someone from Microsoft seems to be on the public-xhtml2 list
951. # [21:48] <anne> Access (mobile company) is there
952. # [21:48] <anne> IBM and HP (for the XHTML Print Profile I think) too
953. # [21:48] <anne> only 13 WG members in total though
954. # [21:50] <anne> public-forms has 27
955. # [21:50] <Lachy_> the XHTML2WG member list should be made public
956. # [21:50] <anne> I don't think that's feasible
957. # [21:50] <Lachy_> why?
958. # [21:51] <anne> Because people thought their information was shared member only, for one
959. # [21:51] <anne> Because some of those people may no longer be around, etc.
960. # [21:51] <Lachy_> but now they're a pulic group
961. # [21:51] <gsnedders> but if it's been re-chatered…
962. # [21:51] <anne> Yes, all information from now on will be public
963. # [21:51] <gsnedders> they'd all have to agree to the new charter
964. # [21:52] <anne> I expect that w3c-html-wg will become obsolete by the end of April
965. # [22:00] <gsnedders> where is a public list of the members?
966. # [22:00] * gsnedders can't find one
967. # [22:01] <anne> dunno
968. # [22:01] <Lachy_> which members?
969. # [22:01] <gsnedders> XHTML2
970. # [22:01] <Lachy_> it's not public
971. # [22:01] <Philip> (Split some sections up now - the biggest remaining is tree-construction at 148KB, which I don't think can be split further, followed by interactive1 (datagrid) at 111KB)
972. # [22:01] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
973. # [22:01] * gsnedders missed the words "should be made"
974. # [22:02] <anne> Lachy_, oh, you mean the list of members?
975. # [22:02] <anne> Lachy_, not w3c-html-wg?
976. # [22:02] * anne thought Lachy_ argued for making w3c-html-wg archives public
977. # [22:03] * Joins: marcos_ (chatzilla@203.206.31.102)
978. # [22:03] * gsnedders thought he meant the list of members, as that was the current topic of conversation
979. # [22:03] * Lachy_ is now known as Lachy
980. # [22:03] <gsnedders> but I misread what he said anyway :P
981. # [22:03] <hsivonen> interesting that the people who have the most reservations about adopting HTML5 are not (well-known) implementors
982. # [22:04] <hsivonen> I wonder if Matthew Ratzloff has specific spec parts in mind that he'd like to reject
983. # [22:05] <anne> yeah, what's up with people stating things in generic terms instead of just saying: "I'm opposed to feature X, Y and Z"
984. # [22:05] <anne> "... and I don't trust my feedback will be taken care of if we don't do it my way."
985. # [22:08] <gsnedders> how many active members will be left when we actually start work?
986. # [22:08] <gsnedders> unless the WG completely losses relevance, I'll be staying with it
987. # [22:50] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
988. # [22:53] * Joins: gsnedders (gsnedders@86.139.123.225)
989. # [23:34] <marcos_> Lachy, you should again point Danc to your presentation on HTML5
990. # [23:34] <Lachy> marcos_, why?
991. # [23:35] <marcos_> "I'm interested in having someone present HTML5, or the differences
992. # [23:35] <marcos_> between HTML4 and HTML5, in a teleconference. "
993. # [23:35] * Quits: loic (loic@90.29.116.63) (Quit: hoopa rules)
994. # [23:35] <marcos_> I'll get the pointer to the email...
995. # [23:35] <mjs> I think a telecon might be about the worst possible medium for a presentation, but might be worth doing if enough people want it
996. # [23:36] <mjs> I should hassle my work about hosting an f2f in June or something
997. # [23:36] <marcos_> Mjs, lachy has a great MP3 file and powerpoint presentation people can follow
998. # [23:36] <marcos_> far better then a teleconf presentation
999. # [23:37] <Lachy> http://lachy.id.au/dev/presentation/future-of-html/
1000. # [23:37] * Lachy will post that to the list too
1001. # [23:37] <mjs> oh, cool
1002. # [23:37] <marcos_> Lachy, maybe add a link to it from the WHATWG wiki page on the differences between HTML4/5
1003. # [23:40] <marcos_> lachy, this is the email pointer: http://lists.w3.org/Archives/Public/public-html/2007Apr/0529.html
1004. # [23:40] <Lachy> marcos_, I already sent my reply
1005. # [23:41] <marcos_> ok cool
1006. # [23:43] <Lachy> marcos_, the presentation doesn't really belong on the changes from HTML4 page. I'll create an HTML5 Presentations page instead
1007. # [23:45] <marcos_> sounds good
1008. # Session Close: Thu Apr 12 00:00:00 2007

The end :)