/irc-logs / w3c / #html-wg / 2009-10-05 / end


  1. # Session Start: Mon Oct 05 00:00:00 2009
  2. # Session Ident: #html-wg
  3. # [00:06] * Joins: gsnedders (gsnedders@
  4. # [00:09] * Quits: gsnedders (gsnedders@ (Quit: gsnedders)
  5. # [00:30] * Quits: tlr (tlr@ (Quit: tlr)
  6. # [00:40] <pimpbot> bugmail: [Bug 7645] associate printable pages and less-convenient-to-print pages with link rel value "print" <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0031.html>
  7. # [01:10] <pimpbot> bugmail: [Bug 7736] add tooltip attribute & keep title for other uses <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0032.html>
  8. # [01:18] * Joins: mjs (mjs@
  9. # [01:33] * Joins: tH (Rob@
  10. # [01:34] * Quits: Hixie (ianh@ (Ping timeout)
  11. # [01:39] * Joins: mjs_ (mjs@
  12. # [01:39] * Quits: mjs (mjs@ (Connection reset by peer)
  13. # [01:39] * mjs_ is now known as mjs
  14. # [01:40] <pimpbot> bugmail: [Bug 7645] associate printable pages and less-convenient-to-print pages with link rel value "print" <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0033.html>
  15. # [01:41] * Quits: karl (karlcow@ (Quit: O public road, I say back I am not afraid to leave you, yet I love you, you express me better than I can express myself.)
  16. # [01:42] * Joins: Hixie (ianh@
  17. # [02:17] * Quits: Lachy (Lachlan@ (Quit: Leaving)
  18. # [02:40] <pimpbot> bugmail: [Bug 7800] New: title attribute: add new attr for machine-readable strings <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0034.html>
  19. # [03:01] * Quits: gavin (gavin@ (Ping timeout)
  20. # [03:07] * Joins: gavin (gavin@
  21. # [03:10] <pimpbot> bugmail: [Bug 7657] Redefining dt and dd <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0036.html> ** [Bug 7669] Redefining dt and dd, recommend new element as caption for Figure <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0035.html>
  22. # [03:46] <Hixie> mjs: if you or sam feel something should change, please file a bug -- i'm not sure at this point what conclusion to draw from the thread
  23. # [03:47] <mjs> Hixie: I'm waiting until I understand Sam's point enough to not accidentally file dueling bugs
  24. # [03:47] <Hixie> sure
  25. # [04:13] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  26. # [04:32] <MikeSmith> issue-83: see Dean Edwards message at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023276.html and subsequent thread
  27. # [04:32] * trackbot attempting to add a note to ISSUE-83.
  28. # [04:32] <trackbot> ISSUE-83 Use of the dt and dd elements in figure and details content models notes added
  29. # [04:32] <pimpbot> Title: [whatwg] The new content model for breaks rendering in MSIE5-7 (at lists.whatwg.org)
  30. # [04:41] <pimpbot> changes: hixie: Elaborate on how foreign elements are to be written in the HTML syntax. (whatwg r4075) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Oct/0009.html>
  31. # [05:11] <pimpbot> bugmail: [Bug 7657] Redefining dt and dd <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0038.html> ** [Bug 7669] Redefining dt and dd, recommend new element as caption for Figure <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0037.html>
  32. # [05:41] <pimpbot> changes: hixie: Disallow ` in unquoted attribute values. (whatwg r4076) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Oct/0010.html>
  33. # [06:11] <pimpbot> bugmail: [Bug 7801] New: Shouldn't autofocus be included in this matrix? <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0039.html>
  34. # [06:41] * Joins: shepazu (schepers@
  35. # [06:41] <pimpbot> bugmail: [Bug 7059] Forking XPath <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0041.html> ** [Bug 7669] Redefining dt and dd, recommend new element as caption for Figure <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0040.html>
  36. # [07:11] <pimpbot> bugmail: [Bug 7800] title attribute: add new attr for machine-readable strings <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0042.html>
  37. # [07:15] * Quits: syp (syp@ (Ping timeout)
  38. # [07:15] * Joins: syp (syp@
  39. # [07:15] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  40. # [07:39] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  41. # [07:41] <MikeSmith> issue-73?
  42. # [07:41] * trackbot getting information on ISSUE-73
  43. # [07:41] <trackbot> ISSUE-73 -- Overlap of "predefined vocabularies" with other specifications -- OPEN
  44. # [07:41] <trackbot> http://www.w3.org/html/wg/tracker/issues/73
  45. # [07:41] <pimpbot> Title: ISSUE-73 - HTML Weekly Tracker (at www.w3.org)
  46. # [07:44] <MikeSmith> issue-73: predefined vocabs have now been moved out of HTML5 and into separate drafts; see http://lists.w3.org/Archives/Public/public-html/2009Oct/0087.html & http://dev.w3.org/html5/mdvcard/ & http://dev.w3.org/html5/mdvevent/ & http://dev.w3.org/html5/mdwork/ and note that HTML5 does not reference those drafts nor have any dependency on them.
  47. # [07:44] * trackbot attempting to add a note to ISSUE-73.
  48. # [07:44] <trackbot> ISSUE-73 Overlap of "predefined vocabularies" with other specifications notes added
  49. # [07:44] <pimpbot> Title: Re: Microdata vocabulary specifications from Ian Hickson on 2009-10-04 (public-html@w3.org from October 2009) (at lists.w3.org)
  50. # [08:12] <pimpbot> bugmail: [Bug 7799] If the fragid doesn't match an ID or a name in the document, then surely the browser should revert to doing a text search for the fragid text in the document <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0043.html>
  51. # [08:29] * Quits: Zeros (_icond@ (Quit: Leaving)
  52. # [08:42] <pimpbot> changes: hixie: Register about:legacy-compat. (whatwg r4078) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Oct/0012.html> ** hixie: Make spec consistent in its use of ASCII and Unicode character references and it's references to bytes sequences. (whatwg r4077) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Oct/0011.html>
  53. # [09:12] <pimpbot> bugmail: [Bug 7657] Redefining dt and dd <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0044.html>
  54. # [09:17] * Quits: gavin (gavin@ (Ping timeout)
  55. # [09:23] * Joins: gavin (gavin@
  56. # [09:36] <pimpbot> planet: HTML5 Ajax to a different domain? <http://stackoverflow.com/questions/1500275/html5-ajax-to-a-different-domain>
  57. # [09:42] <pimpbot> bugmail: [Bug 7803] The title element's "value" is earlier defined to be the value of its child text nodes -- not textContent <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0048.html> ** [Bug 7804] New: In Firefox and Safari .text returns the value of the child text nodes -- not textContent <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0047.html> ** [Bug 7803] New: The title element's "value" is earlier d
  58. # [09:44] * Joins: tlr (tlr@
  59. # [10:12] <pimpbot> bugmail: [Bug 7805] New: The tag name of foreign elements aren't necessarily all-lowercase. <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0049.html>
  60. # [10:26] * Joins: annevk (opera@
  61. # [10:42] <pimpbot> bugmail: [Bug 7806] atom ID element generation for feed entries <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0051.html> ** [Bug 7806] New: atom ID element generation for feed entries <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0050.html>
  62. # [10:45] * Joins: ROBOd (robod@
  63. # [10:58] * Joins: gsnedders (gsnedders@
  64. # [11:16] * Joins: Julian (chatzilla@
  65. # [11:29] * Joins: Marcos (Marcos@
  66. # [11:31] <Marcos> Hixie, After "Over the past few weeks, Google has been preparing and then running a usability study to test the microdata feature of HTML5." Write whose the participants were and their background (age and sex, where they were sourced from, etc.). Make it clear that your study had only 7 participants. Also make it clear that the methods used in the study are in question (given the references I cited.)
  67. # [11:31] <Marcos> Also, change study to "preliminary study"
  68. # [11:31] <Marcos> Also, describe what variables where used to determine the following "it became clear that "about" was a very confusing term to use for giving the item's global identifier". Particularly, the use of "very". How many people were confused? all 7?
  69. # [11:31] <Hixie> i can't say who the participants were, because we have a legal agreement with them that precludes me from giving their demographics without the recipient being under NDA
  70. # [11:32] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  71. # [11:32] <Hixie> the blog post makes it quite clear how many people were involved (initialy six, then one canceled, so we added two more)
  72. # [11:32] <Marcos> That should be at the top
  73. # [11:33] <Marcos> Your framing of the article is deceptive
  74. # [11:33] <Hixie> and the methods used aren't in question -- the references you gave don't apply here, they were for testing long-term sites and for long-term game or app development, not for language design
  75. # [11:33] <Hixie> the study wasn't "preliminary", as far as i know it's the only study anyone has planned
  76. # [11:34] <Hixie> the post says "after the first three, it became clear that "about" was a very confusing term", so it seems clear how many people were used in determining that
  77. # [11:34] <Hixie> so basically, i disagree with all your requests, and don't think that the article was "deceptive" at all
  78. # [11:34] <Hixie> it's just describing what we did, matter-of-factly
  79. # [11:35] <Hixie> what do you think the post tries to be deceptive about?
  80. # [11:38] <Marcos> I feel it is deceptive about it's conclusions. When I read it, it felt that it was making over generalisations about how people in general would use/understand micro-data. I wanted to article to be clear that it was only 7 people to which this applied.
  81. # [11:38] <Hixie> the whole point of usability studies is to make such generalisations
  82. # [11:38] <Hixie> as the papers you posted mentioned, problems found by one person often affect many other people
  83. # [11:38] <Marcos> Hence me labelling it as a pseudo science
  84. # [11:39] <Hixie> problems found by three people almost always affect almost everyone
  85. # [11:39] <Hixie> i don't think it's science at all
  86. # [11:39] <Hixie> it's just language design
  87. # [11:40] <Marcos> Hang, so you promise me you will never use this data to support your position about the usability of microdata?
  88. # [11:40] <Hixie> quite the opposite, that would be quite the waste of money
  89. # [11:40] <Hixie> it'd be stupid to find out that people get confused by the term 'about' and then to ignore that!
  90. # [11:41] <Marcos> But you didn't find that! You found that 7 people got confused.
  91. # [11:41] <Marcos> Maybe even less
  92. # [11:41] <Hixie> dude, i generally base changes in the spec on what _one_ person says is confusing
  93. # [11:42] <Hixie> so having three, on video, with a moderator, with one-way-glass, with a prepared script, all finding the same problem, is, like, incredible
  94. # [11:42] <Hixie> of course i'm not going to ignore it
  95. # [11:42] <Hixie> i will take it as input just like i take everything else as input
  96. # [11:43] <Marcos> That's scary Hixie. You are the one that gave use the 1 Billion sample of tag usage on the Web and then you hit us up with this.
  97. # [11:43] <Hixie> o_O
  98. # [11:43] <Marcos> Also, I'm not asking you to ignore it. All data is useful. Just to put it into perspective.
  99. # [11:43] * jgraham does see how those two things are related really
  100. # [11:43] <Hixie> are you saying itemprop=about is clearer than itemid=""?
  101. # [11:44] <Hixie> i really don't understand what you're objecting to here
  102. # [11:44] <Hixie> how else are we supposed to find out if microdata is well-designed?
  103. # [11:44] <jgraham> I mean it is hard to see how one can draw conclusions about the usability of a new feature from surveys of existing usage
  104. # [11:45] <jgraham> And it is very easy to draw incorrect conclusions from studies of 1 billion pages if you don't understand what you are looking at
  105. # [11:45] <Julian> for once, it might be a good idea to post the study to the W3C mailing list, propose a change, and ask for feedback
  106. # [11:45] <Marcos> I don't disagree with you findings and hypothesis. I'm disagreeing that you draw what appears to be hard conclusions from a very small data set. Maybe we should think of conducting a wider study or better harnessing the collective intelligence of the working group to get better data.
  107. # [11:46] <jgraham> (I guess one can look at which existing features authors tend to get wrong and try to avoid those design patterns)
  108. # [11:47] <jgraham> Marcos: Do you have any specific conclusions that you think are wrong?
  109. # [11:47] * jgraham doesn't really understand the issue here
  110. # [11:49] <jgraham> (it looks a lot like getting no data would have been uncontroversial becuase everyone is used to desigining based on no data but getting some data provokes controversy because it is not possible to get perfect data)
  111. # [11:50] * Quits: annevk (opera@ (Quit: annevk)
  112. # [11:51] <Marcos> jgraham: it's an issue of language. The language of the article should be softened to make it clear that the results are relative to the number of participants in the study (an not generally applicable to the population).
  113. # [11:52] <Marcos> for instance s/people/participants in the study
  114. # [11:53] <Hixie> the whole point of usability studies is that they are representative of people
  115. # [11:54] <Hixie> if 3 people out of 3 find something confusing, conclusing that that thing is not confusing is... not the best conclusion
  116. # [11:54] <Marcos> Hixie, that assumption is fundamentally flawed.
  117. # [11:54] <Hixie> no, it's really not
  118. # [11:55] <Hixie> even the papers you cited support that assumption
  119. # [11:55] <Hixie> the papers you cited only suggested that more people would find more problems if you were doing a study to find problems in an arbitrarily complex product (like a game or shopping site)
  120. # [11:55] <Hixie> but we weren't doing that -- we were testing for specific issues
  121. # [11:56] <jgraham> Marcos: It seems to me that one could set some acceptable fraction of the web-author population who would find a feature confusing and work out the statistics for what 3/3 people actually finding it confusing was
  122. # [11:56] <jgraham> Say a feature is OK if 10% of people find it confusing
  123. # [11:57] * Philip notes that confusingness is not a boolean property
  124. # [11:57] <Marcos> Over repeated testing, you can theoretically conclude that a sample of the population will encounter the same problem or specific issue. What would happen if I tested 7 people and got different results?
  125. # [11:57] <Hixie> Marcos: please, do!
  126. # [11:57] <Hixie> Marcos: the more the better!
  127. # [11:57] <jgraham> Philip: Imagine a threshold of confusingness set by the ability to perform some task :)
  128. # [11:58] <Philip> jgraham: But if three people find something incredibly confusing, vs three people find it very slightly above the confusingness threshold, that affects the certainty you can have that other people will also find it confusing
  129. # [11:59] <jgraham> Philip: I'm not sure that's relevant if you set the right criteria
  130. # [12:00] <jgraham> e.g. if your criteria are <10% of the population myst be able to do task x
  131. # [12:00] <jgraham> *must
  132. # [12:00] * Joins: myakura (myakura@
  133. # [12:02] <Hixie> if the feature is ok if 10% fail at a task, and the feature is the worst it could be, i.e. exactly 10% of the population would fail at that task, and you have 3 participants, the chance of them all being those who fail is 1:1000, right?
  134. # [12:02] <Hixie> that's actually even better than i expected
  135. # [12:03] <Philip> jgraham: It seems to be relevant if you attempt to compute statistics, like saying if 7 out of 7 people find something confusing then you're 95% certain at least 65% of the population find it confusing, or whatever
  136. # [12:03] <Hixie> (having not previously thought about it)
  137. # [12:03] <jgraham> Hixie: That sounds right to me but I was never very good at stats
  138. # [12:04] <jgraham> Philip: But if you don'tt worry about "confusingness" and instead work with the boolean property "must be able to do x" I think you can avoid the problem
  139. # [12:04] <Philip> since those statistics are probably true (unless I did the maths wrong, which I probably did) but are less meaningful than if you take account of the range of confusingness that people experience rather than making it binary and losing information
  140. # [12:07] <Philip> Hixie: If all you know is that 3 out of 3 failed, it could easily be that e.g. only 80% of the population would fail, and there'd be a ~50% chance of all 3 failing
  141. # [12:08] <Philip> or it could be that 50% of the population would fail, and you were just unlucky and hit the one-in-eight chance of all 3 failing
  142. # [12:08] <Hixie> right, but whether it's 50% of them failing or 80% or 100% of them failing wouldn't matter, in any case, you'd want to fix the problem.
  143. # [12:09] <Hixie> (assuming you decided that 10% failing is the acceptable limit)
  144. # [12:20] <Philip> Hmm, I see what you mean now
  145. # [12:20] <Philip> but I can't convince myself it's correct
  146. # [12:21] <mjs> it's a well-known result in usability testing that past 6-10 participants, further testing gives diminishing returns
  147. # [12:21] <mjs> i.e. the most common problems will almost certainly be identified by observing just a few test subjects, and the more you test, the fewer additional problems you find per person
  148. # [12:21] <mjs> I don't know if that's ever been corroborated for usability of markup languages as opposed to user interfaces
  149. # [12:23] <mjs> in general user testing can't show you that something isn't a problem, but you can conclude with fairly high likelihood that problems not found are not very common
  150. # [12:23] <jgraham> mjs: Do you knhow of any instances of anyone actually doing usability testing of markup languages before?
  151. # [12:23] <mjs> jgraham: no
  152. # [12:23] <mjs> I wish someone had thought of it sooner and that we'd had more time and funding to test more aspects of HTML5
  153. # [12:24] <Hixie> i actually had been hoping to do it ever since coming to google
  154. # [12:24] <Hixie> but it's very hard to test markup, since generally you want implementations
  155. # [12:24] <Hixie> with microdata we got away with just testing things without an implementation
  156. # [12:24] <mjs> (though for features inherited from HTML4, surveying Web content is a sort of after-the-fact usability testing)
  157. # [12:25] <Hixie> yeah
  158. # [12:25] <mjs> for things that need implementations, it would probably be too high a cost to make throwaway implementations just for testing
  159. # [12:26] <mjs> (well, other than things that can be simulated well enough with CSS or script)
  160. # [12:26] <Hixie> indeed
  161. # [12:26] <Hixie> there are few things for which that isn't hte case though
  162. # [12:26] <Hixie> microdata is the first i've come across
  163. # [12:29] <hsivonen> Marcos: why is the age and sex of the participants relevant?
  164. # [12:30] <Marcos> hsivonen: the participants were 3 years old, and didn't speak english. They found "about" confusing
  165. # [12:30] * Philip supposes his problem in comprehension is that we want to know P(failure rate < 0.1, given 3 out of 3 failed) but only know P(3 out of 3 fail, given failure rate < 0.1) (and only an upper limit on that), and we don't know enough to relate those two
  166. # [12:31] <Hixie> Marcos: as i mention in the blog post, all the participants were web developers familiar with HTML.
  167. # [12:31] <Philip> Aren't most 3 year olds familiar with HTML nowadays?
  168. # [12:31] <Hixie> and not familiar with HTML5, though apparently one had heard of HTML5 in press articles and was looking forward to <header> (and didn't know anything else about it, it was pretty disheartening!)
  169. # [12:32] <Marcos> What does familiar mean? What does web developer mean?
  170. # [12:32] <Marcos> does it mean that they worked professionally?
  171. # [12:32] <Marcos> If so, for how many years?
  172. # [12:34] <Hixie> i can only speak in the most general terms, but we had people from 6 months experience to experienced since the web started (19 years or so)
  173. # [12:34] <Hixie> the length of time had no correlation to their competence
  174. # [12:34] <hsivonen> Marcos: from Hixie's use of personal pronoun on IRC, you can conclude that at least one person was male and at least two were female
  175. # [12:34] <hsivonen> Marcos: unless Hixie was randomizing his pronoun gender for NDA reasons
  176. # [12:34] <mjs> that or Hixie is switching pronouns to be gender-neutral
  177. # [12:35] <Hixie> several were software engineers, several were professional web developers at silicon valley companies, either currently or recently
  178. # [12:35] <mjs> Marcos: when it comes to adults with reasonable familiarity with the target computing platform, traditional usability studies are fairly robust against differences in sex, age and years of computing experience
  179. # [12:35] <Hixie> we have recruiters and screeners to pick a good sample of people
  180. # [12:36] <Hixie> you can look at the raw result files i uploaded to get an idea of how competent each participant was
  181. # [12:36] <mjs> the one thing that can make a big difference is familiarity with the exact software being tested, but usually such people are excluded from being test subjects
  182. # [12:36] <mjs> I don't know if this result generalizes to usability testing a markup language though
  183. # [12:36] <Hixie> yeah we explicitly excluded anyone who claimed to know much about html5
  184. # [12:36] <Hixie> just in case
  185. # [12:36] <hsivonen> Marcos: it seems to me that it doesn't make sense to complain about the change of accidentally picking people whose confusions are opposite to the population in general
  186. # [12:36] <hsivonen> s/change/chance/
  187. # [12:37] * Joins: anne (annevk@
  188. # [12:37] <hsivonen> Marcos: that is, in the absence of evidence to the contrary, it seems quite proper to treat confusions found by a handful of people as fixable items
  189. # [12:37] <hsivonen> Marcos: not necessarily an exhaustive set of fixable items, though
  190. # [12:38] <hsivonen> Marcos: is there any method (short of testing the entire population) that you'd be happy with?
  191. # [12:40] * hsivonen hasn't actually read the blog post yet
  192. # [12:41] <Marcos> mjs, what studies do you have to validate that?
  193. # [12:42] <mjs> the Wikipedia article on Usability Testing has some links to research: http://en.wikipedia.org/wiki/Usability_testing
  194. # [12:42] <pimpbot> Title: Usability testing - Wikipedia, the free encyclopedia (at en.wikipedia.org)
  195. # [12:43] <mjs> it cites the original Jakob Nielsen paper that argues testing five people is enough, and some more recent research that challenges that claim
  196. # [12:44] <hsivonen> Marcos: are you suggestin that the problems found in a study of 7 people should not be treated as eligible for fixing?
  197. # [12:45] <jgraham> Philip: Does using Bayes theroem with an appropriate choice of prior help?
  198. # [12:45] <Marcos> hsivonen: all I'm saying is that the result should be seen in relation to the population sampled. And not generally applied to the population as a whole.
  199. # [12:46] <jgraham> (I'm not sure if you have the right information for that though...)
  200. # [12:46] <Philip> jgraham: No, because the prior is one of the things we don't know
  201. # [12:46] <hsivonen> Marcos: isn't the relevant question whether the findings should be treated as actionable in spec writing?
  202. # [12:46] <Philip> jgraham: (or two of the things, I guess)
  203. # [12:47] <Marcos> hsivonen: yes.
  204. # [12:47] <hsivonen> Marcos: are you postulating that fixing the problems identified with the 7 people would cause more harm than good if acted on?
  205. # [12:47] <jgraham> Philip: Not knowing the prior is quite normal when using Bayes theroem
  206. # [12:48] <Marcos> hsivonen: potentially, yes.
  207. # [12:48] <jgraham> (I'm more troubled about not knowing p(3/3 failed) which acts as the normalising constant
  208. # [12:48] <hsivonen> Marcos: shouldn't Occam's Razor or a similar device address that concern?
  209. # [12:48] <jgraham> )
  210. # [12:48] <anne> Marcos, so most spec writing causes harm then, since generally it's based on the opinions of a single person...
  211. # [12:48] <mjs> most of the research challenging the classic five-is-enough rule of thumb suggests that you will continue to find more problems as you test more users, beyond what older mathematical models predict, none of it seems to suggest you will find "false positives"
  212. # [12:49] <hsivonen> mjs: that was my observation, too
  213. # [12:49] <Hixie> mjs: indeed
  214. # [12:49] <Marcos> mjs: agree, but it could happen. It can't be discounted. Specially in such a small sample size
  215. # [12:49] <Hixie> mjs: also of relevance here, we were specifically testing some specific ideas, not looking for problems in general (though we did find some)
  216. # [12:50] <mjs> now, it's possible that if your fix to a problem doesn't get enough testing, that it actually has hidden serious problems
  217. # [12:50] <hsivonen> Marcos: there could also be a celestial teapot :-)
  218. # [12:50] <Marcos> Anne, I have never seen a spec based on the opinions of a single person
  219. # [12:50] <mjs> it's suggested by the research that testing converges more rapidly when testing something with relatively simple interaction and few paths through the problem
  220. # [12:50] <hsivonen> Marcos: "it could happen" isn't a very convincing argument
  221. # [12:50] <Marcos> hsivonen: sure. We cannot discount that either
  222. # [12:50] <Hixie> marcos: most of changes in html5 are based on feedback from individuals
  223. # [12:51] <Marcos> Hixie, but how many emails have you received as feedback?
  224. # [12:51] <mjs> anyway - it seems like a spec written to avoid problems that were actually discovered may have its own problems, but it seems like, a priori, it should be less likely to have as many serious problems
  225. # [12:51] <Hixie> Marcos: on each individual feature? usually none.
  226. # [12:51] <jgraham> Marcos: The sample of opinions that most specs are based on are highly biased to the type of people that want to get into spec writing
  227. # [12:51] <mjs> to suggest that a change makes things worse would require some kind of evidence to rebut that assumption
  228. # [12:51] <Marcos> Hixie, you are to a large degree harnessing the collective intelligence when interpreting the emails.
  229. # [12:52] <Hixie> Marcos: not really, since on most features, very few people post, if any.
  230. # [12:52] <Hixie> Marcos: but if it makes you feel better, consider the participants to just be 7 people who send an e-mail each.
  231. # [12:52] <mjs> (that can even be a pure a priori argument identifying a potential new problem)
  232. # [12:53] <mjs> one usability testing subject is more valuable than one email's worth of self-reported experience
  233. # [12:53] <mjs> it's well known that self-reported experiences of self-selected users give a misleading picture, in general
  234. # [12:54] <anne> Marcos, for many features of XMLHttpRequest I've either received no feedback or feedback from just one person
  235. # [12:54] <Marcos> mjs, why? that assumes that usability studies have more weight than emails
  236. # [12:54] <Marcos> Anne, citing individual cases is unhelpful.
  237. # [12:54] <jgraham> Marcos: Everyone is very bad at giving an accurate report of their own experience
  238. # [12:54] <mjs> Marcos: a well-reasoned argument may (in some cases) have more weight than a usability test
  239. # [12:54] <hsivonen> Marcos: you get better data by observing other people than by introspection
  240. # [12:55] <mjs> Marcos: but emails that say "I found this easy/hard" are of very little value
  241. # [12:55] <mjs> or even emails that say "I found step X hard and it should be changed to Y"
  242. # [12:55] <mjs> at least, that's my experience with software user interface
  243. # [12:56] <anne> Marcos, ok, for all specs I write for most features I've either received no feedback or feedback from one person :)
  244. # [12:56] <mjs> problem reports from trained programmers or testers are more useful, because they tend to identify concrete bugs
  245. # [12:56] <mjs> although ones that claim something would be easier "for my grandmother" tend to be dubious
  246. # [12:57] <Marcos> You don't gather data from crash reports also?
  247. # [12:57] <mjs> (again though, most of what I say, I only have experience and research in the area of mainstream software user interface)
  248. # [12:57] <mjs> we do, though crash reports are not self-reported experiences
  249. # [12:57] <hsivonen> I think actually observing one's grandparent fail at a computer task is a valid way of discoving usability bugs
  250. # [12:57] <mjs> we analyze them statistically
  251. # [12:57] <hsivonen> I discovered bad design in Ubuntu's update notification that way
  252. # [12:57] <mjs> hsivonen: it would, but most people use a hypothetical model of their mother/grandmother to make claims about what would be hard or easy
  253. # [12:58] <hsivonen> mjs: sure
  254. # [12:58] <Dashiva> Actually observing grandma is different
  255. # [12:59] <mjs> Marcos: we do put more value on seeing many instances of a crash via automated crash reports, than on one person's claim that a crash does (or would) happen a lot
  256. # [13:03] <Marcos> Ok, anyway. I bitched enough and burned sufficient amounts of my credibility capital. I understand the purpose of the "study" better now. Thanks all :D
  257. # [13:18] <hsivonen> hmm. http://lists.xml.org/archives/xml-dev/200202/msg00278.html would require parsers to come with a copy of the Unicode DB or hook into a platform API for accessing a platform copy
  258. # [13:18] <pimpbot> Title: xml-dev - Re: [xml-dev] A heavier-weight proposal for character entitydefinition (at lists.xml.org)
  259. # [13:19] <hsivonen> seems a bit excessive for XML use in embedded systems
  260. # [13:31] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  261. # [13:33] <mjs> that does not seem like a great proposal
  262. # [13:35] <anne> just enlarging the default entity set to all the mathml ones seems good enough
  263. # [13:36] * Quits: Marcos (Marcos@ (Ping timeout)
  264. # [13:37] <mjs> you can already enter any character by literally entering it, or by using an NCR
  265. # [13:37] <mjs> it seems excessive to add a third way to input all other characters (in cases where this is not already available)
  266. # [13:37] <pimpbot> planet: toDataURL, Canvas, and SVG <http://feedproxy.google.com/~r/ajaxian/~3/B-vpAVOaz3Q/todataurl-canvas-and-svg>
  267. # [13:39] * Joins: Marcos (Marcos@
  268. # [13:43] <pimpbot> bugmail: [Bug 7807] New: term "new master" can be ambiguous <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0055.html> ** [Bug 7804] In Firefox and Safari .text returns the value of the child text nodes -- not textContent <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0054.html> ** [Bug 7800] title attribute: add new attr for machine-readable strings <http://lists.w3.org/Archives/Public/public-html-bugzi
  269. # [13:44] * Quits: Marcos (Marcos@ (Quit: Marcos)
  270. # [13:51] <Philip> "I believe that any kind of change that aligns the text/html and the application/xml syntax more closely would be a win." - let's remove Namespaces from XML, then :-)
  271. # [13:53] * Joins: Marcos (Marcos@
  272. # [13:57] <Julian> Would it be possible to do so without breaking a significant amout of XHTML content? Just checking.
  273. # [13:58] <anne> most XHTML content can prolly be parsed as HTML5 just fine
  274. # [14:00] <Julian> on the other hand, how much HTML content would *really* break (which != "parsed differently") if xmlns* wouldn#t be ignored in some cases?
  275. # [14:00] <jgraham> Julian: It is totally unclear to me that the colons-in-tag-names space is not horribly overconstrained
  276. # [14:01] <Julian> James: overconstrained?
  277. # [14:01] <jgraham> I'm not sure that much can be changed without people having to take an unacceptable compatibility risk
  278. # [14:01] <jgraham> I'm not claiming that *nothing* could be changed
  279. # [14:02] <Julian> I'd like to understand what that risk really is.
  280. # [14:02] <Julian> For instance, if HTML allowed:
  281. # [14:02] <Julian> <html xmlns:foo="bar">....<foo:x>test</foo:x></html>
  282. # [14:03] <Julian> and the namespaceURI foor foo:x would really be "bar" -- what would break?
  283. # [14:03] <Julian> (and yes, I know that "bar" is not a URI)
  284. # [14:03] * gsnedders wonders if "bar" should be treated as a relative URI or should it be resolved
  285. # [14:03] <anne> Julian, live.com and such I believe
  286. # [14:04] <anne> Julian, and probably sites that have leftovers from MS Office products in their markup
  287. # [14:04] <Julian> Please elaborate.
  288. # [14:05] <Julian> live.com redirects to bing.com, which doesn't use xmlns:x=y
  289. # [14:05] <Julian> only a default ns declaration
  290. # [14:05] <anne> might have been their previous live properties such as mail etc. been a while
  291. # [14:05] <jgraham> It is not impossible that *only* changing namespaceURI and not localName or anything would not break a lot
  292. # [14:06] <jgraham> But it is far far from obvious
  293. # [14:06] <anne> I'm not really interested in participating in this inquiry though; so I'll bow out now and go do something else
  294. # [14:06] <jgraham> (and hard to prove since it requires looking at Javascript)
  295. # [14:06] <Julian> Actually, I would want namespaceURI and localName both be changed
  296. # [14:06] <jgraham> Julian: Oh well that seems much more likely to break stuff
  297. # [14:07] <Julian> James, such as?
  298. # [14:08] <jgraham> Julian: Sites with things like o:p that expect localName to be "o:p"
  299. # [14:09] <jgraham> and in particular expect o:p elements not to show up when DOM 1 methods are used to identify p elements
  300. # [14:09] <jgraham> (and similar considerations with CSS, depending on what exactly you would expect to happen there)
  301. # [14:10] <Julian> James, do you have evidence of the existence of sites like these?
  302. # [14:10] <jgraham> (and also in cases like <html><foo:bar></html> where foo: is never declared
  303. # [14:10] <jgraham> )
  304. # [14:10] <Julian> I don't have problems with not changing the behaviour for broken code like that.
  305. # [14:10] <jgraham> Julian: There is an Opera bug from last time we tried to enable this and got all sorts of compat problems
  306. # [14:11] <jgraham> I will try to look in more detail sometime
  307. # [14:11] <jgraham> (but not now)
  308. # [14:11] <Julian> It would be great to have this information public.
  309. # [14:11] <Julian> Do you recall which opera version had that enabled?
  310. # [14:11] <jgraham> Julian: I think it was 7.x Myabge also 8 Not sure
  311. # [14:14] <jgraham> (FWIW if I wanted distributed extensibility in HTML, I think I would be advocating <com.apple.canvas> style distributed extensibility since that seems to cover the usecases put forward and avoids poking at the one oiece of syntax space that seems to have serious compat risk)
  312. # [14:15] <mjs> Julian: I'm not sure *any* change to parsing elements or attributes with colons in the name would break stuff
  313. # [14:15] <mjs> Julian: I strongly suspect the following changes would:
  314. # [14:15] <mjs> - applying namespace processing to attributes (because IE doesn't do that)
  315. # [14:16] <mjs> - applying namespace processing to elements where the localName matches a built-in HTML element name (because apparently IE doesn't do that)
  316. # [14:16] <mjs> - giving effect to xmlns declarations that appear in places other than the root element (because IE doesn't do that)
  317. # [14:17] <mjs> and we do know there is content with junk xmlns attributes in the middle
  318. # [14:17] <mjs> Julian: I also suspect that respecting xmlns in HTML at all would cause breakage on some sites if you do it without implementing enough of IE's proprietary extensions
  319. # [14:18] <Julian> Maciej, for these sites to break they would *also* need to run script that does something with these nodes. I'd like to see evidence of that.
  320. # [14:19] <mjs> no, they don't have to run script
  321. # [14:19] <mjs> they could apply CSS style rules
  322. # [14:19] <Julian> CSS?
  323. # [14:19] <Julian> Yes, I understand the CSS issue. Was jsut conforming
  324. # [14:19] <mjs> or they could simply depend on some elements being treated like a normal html element for layout/behavior purposes
  325. # [14:20] <Julian> I agree that all of this *could* be true.
  326. # [14:20] <Julian> But I'd like to see numbers, or at least real-world examples.
  327. # [14:20] <mjs> or they could have dual code paths for IE and other browsers, and switching of the dual code path depends on aspects of IE's namespace support
  328. # [14:20] <mjs> Philip posted some links to examples (including links to research last time this was discussed)
  329. # [14:21] <Julian> that would be bad, but could be handled by introducing a new API that wasn#t there before.
  330. # [14:21] <Julian> pointer?
  331. # [14:21] <mjs> I would assume a priori that any case where existing browsers do the same thing, and Microsoft now proposes something different, the burden of proof is on advocates of the proposal to show that the compatibility properties are reasonable
  332. # [14:22] <mjs> because we know there's significant content using namespaces in cargo cult copy/paste ways
  333. # [14:22] <Julian> How do you prove that something does not exist, except by checking every single page out there? And even then you'll miss intranets.
  334. # [14:23] <mjs> you can't prove a negative, but you can study a statistical sample
  335. # [14:23] <mjs> that would be good enough for me
  336. # [14:23] <Julian> I do not disagree with that. I'd *still* see numbers and examples though.
  337. # [14:24] <mjs> here's some data linked by Philip Taylor: http://lists.w3.org/Archives/Public/public-html/2009Oct/0076.html
  338. # [14:24] <pimpbot> Title: Re: ISSUE-41/ACTION-97 decentralized-extensibility from Philip Taylor on 2009-10-03 (public-html@w3.org from October 2009) (at lists.w3.org)
  339. # [14:24] <mjs> here he included links to some past examples: http://lists.w3.org/Archives/Public/public-html/2009Oct/0040.html
  340. # [14:24] <pimpbot> Title: Re: ISSUE-41/ACTION-97 decentralized-extensibility from Philip Taylor on 2009-10-01 (public-html@w3.org from October 2009) (at lists.w3.org)
  341. # [14:25] <hsivonen> Julian: part of the problem with getting evidence is that the evidence gathering is risky business that can potentially disrupt the release cycle of a browser
  342. # [14:26] <hsivonen> Julian: I'm curious, too, but not curious enough to perform some experiments.
  343. # [14:27] <MikeSmith> Julian: It could be argued that the burden of proof on demonstrating that the degree to which the proposed changes will or will not break existing should be on those advocating for the proposal.
  344. # [14:28] <anne> I'd like that
  345. # [14:28] <anne> so we don't have to go investigate if things are possible whenever someone comes up with an idea
  346. # [14:30] * Joins: plh (plh@
  347. # [14:35] <MikeSmith> environmental impact report
  348. # [14:37] <pimpbot> planet: Future of Web Apps London: HTML5 <http://www.brucelawson.co.uk/2009/future-of-web-apps-london-html5/>
  349. # [14:48] <Julian> James, I just checked: the Opera behaviour changed between 8.54 and 9.00.
  350. # [14:49] <jgraham> Julian: Thanks
  351. # [14:50] <Julian> so it was the behaviour until ~2.5 years ago
  352. # [14:51] <Julian> now it would be interesting to find out what problems were reported
  353. # [14:52] * Joins: Marcos_ (Marcos@
  354. # [14:53] * Quits: Marcos (Marcos@ (No route to host)
  355. # [14:53] * Marcos_ is now known as Marcos
  356. # [14:57] * Quits: Marcos (Marcos@ (Ping timeout)
  357. # [15:00] <Philip> Julian: Updated http://philip.html5.org/misc/xmlns-dom.html as suggested
  358. # [15:01] <anne> Julian, as has been said before by e.g. Simon and I most problems were with xmlns and xmlns:* on known HTML elements having weird values causing havoc
  359. # [15:01] <Julian> Philip: thanks
  360. # [15:03] <Julian> Anne, clarifying; that will only affect namspaceURI and localName, right?
  361. # [15:03] <anne> it affects behavior of the elements in question
  362. # [15:03] <anne> e.g. <b> is no longer bold, <head> is no longer hidden, etc.
  363. # [15:04] <Julian> Anne, maybe these weird values could be excluded explicitly: hard to say without seeing the data.
  364. # [15:04] <anne> I don't know
  365. # [15:04] <anne> it is extremely hard to say anything about this since the data set is near infinite and studying it is hard without having an implementation
  366. # [15:04] <Julian> so, just because of CSS not matching, or because of additional differences in parsing?
  367. # [15:05] <Julian> well, we can start Opera 8.x
  368. # [15:05] <anne> CSS wouldn't match
  369. # [15:05] <anne> in other cases people use different paths for IE and non-IE browsers
  370. # [15:05] <Julian> ...based on the presence of what...?
  371. # [15:05] <anne> and expect getElementsByTagName("foo") or some such to work in IE where in other browsers bar:foo is expected to work (don't remember the details)
  372. # [15:08] <Julian> Anne, but HTML5 ias asking MS to change their imp of tagName, thus getElementsByTagName("foo")
  373. # [15:09] <Julian> or am I missing something here?
  374. # [15:09] <Julian> If pages use that for IE they are going to break if it changes, right?
  375. # [15:10] <anne> it depends on whether they implement all the other relevant standards correctly too
  376. # [15:10] * Joins: Marcos (Marcos@
  377. # [15:11] <Julian> ...and at the same time...
  378. # [15:11] <anne> yeah, compat is hard
  379. # [15:11] <Julian> playing the devil's advocate: sounds like it's ok to ask IE to break content, then
  380. # [15:12] <anne> I don't think the request is made of just IE
  381. # [15:12] <anne> it varies per section
  382. # [15:13] <Julian> I was just referring to this part
  383. # [15:14] <anne> I guess the answer is yes then as long as we do not ratify the proprietary extension
  384. # [15:14] <Julian> so I hear that the WhatWG UAs can't change their behaviour for localName/namespaceURI because it will break pages, but IE is supposed to change the behaviour for nodeName, although that will break pages as well
  385. # [15:14] <hsivonen> Julian: is anyone asking IE to break content that works interoperably with multiple browser engines?
  386. # [15:15] <anne> IE is supposed to be standards compliant just like other browsers
  387. # [15:15] <anne> If you implement a ton of proprietary extensions and nobody else agrees with them they won't end in the standard and you'll have to break content if you want to comply with the standard in the end. Seems logical to me.
  388. # [15:15] <hsivonen> Julian: I don't see why a future IE would break pages if it implemented the spec and didn't exhibit cues of IEness of old for scripts to trip on
  389. # [15:16] <anne> hsivonen, Julian has a fair point that making all the necessary changes at once is quite a lot of work
  390. # [15:16] <hsivonen> one should assume that a new browser whose UA string is of the similar flavor as Chrome's would be about as Web compatible as Chrome
  391. # [15:16] <anne> and the IE Team has a history of approaching issues like this somewhat badly
  392. # [15:17] <hsivonen> assuming it implements specs
  393. # [15:17] <anne> e.g. fixing CSS hacks without fixing the underlying issues
  394. # [15:17] <hsivonen> anne: getting from current IE to compliance would be hard
  395. # [15:17] <hsivonen> anne: especially if the substring "MSIE" is retained in the UA string
  396. # [15:18] <hsivonen> anne: (getting from current IE incrementally that is)
  397. # [15:18] <hsivonen> since the pattern of authors writing one code path for IE and another for everything else is so prevalent
  398. # [15:18] * Philip would give like to avoid exacerbating the non-interoperability and content-breaking around xmlns, by not encouraging its use as part of the HTML5 language
  399. # [15:18] <anne> yeah; anyway, I'm not sure we should be in the business of designing a way out for them
  400. # [15:19] <hsivonen> so a future IE would need to trigger the everything else path and then work with everything that the everything else path requires
  401. # [15:21] <Philip> And break content that currently works in IE, where the 'everything else' path does not display the content?
  402. # [15:22] <hsivonen> Philip: is it *Web* content today if there's no working "everything else" path?
  403. # [15:23] <Philip> It's content, on the web, and lots of people may use it
  404. # [15:27] <MikeSmith> What's the value proposition for the value of decentralized extensibility for actual end users of the Web? Has anybody articulated that yet?
  405. # [15:28] <MikeSmith> I mean, I can imagine there being some benefits for authors and content providers.
  406. # [15:29] <Julian> end users do not care about this at all
  407. # [15:29] <MikeSmith> OK
  408. # [15:29] <MikeSmith> well, that ought to help us prioritize it better, then
  409. # [15:30] <Julian> so why do we discuss microdata? After call, this can also be achieved by putting things into comments. Or invalid attributes.
  410. # [15:30] * Joins: taf2 (taf2@
  411. # [15:30] <MikeSmith> Julian: all true
  412. # [15:31] <MikeSmith> But I'm not saying we should not discuss it.
  413. # [15:31] <Philip> I hope I'll never have to be the one to teach people why <foo xmlns="bar"><baz/></foo> and <n:foo xmlns:n="bar"><n:baz/></foo> are completely different in text/html, despite what XML Namespaces teaches them
  414. # [15:31] <Philip> or why <foo xmlns:n="bar"><n:baz/></foo> and <div xmlns:n="bar"><n:baz/></div> are completely different
  415. # [15:32] <Julian> why
  416. # [15:33] <Julian> please ignore that
  417. # [15:33] <MikeSmith> but looking at it from a product-development perspective, where the job of a product manager is to determine what market value or return on investment a particular change to a product is going to have, the priority is typically on the features that have the most market value or return on investment
  418. # [15:33] <Philip> (It just seems pretty confusing to be only half-consistent with XML Namespace (and compatibility means we can't be wholly consistent))
  419. # [15:33] <Philip> s//s/
  420. # [15:33] <MikeSmith> Julian: and also considering that compared to the risks
  421. # [15:35] <Julian> Mike, there's a risk we do not achieve interop. As far as I can tell, MSIE can't simply follow the spec. But I guess MS needs to speak for themselves.
  422. # [15:35] <MikeSmith> Julian: e.g, the risk of handing large vendors an easier means to unilaterally introduce de facto extensions to the language that all other vendors are going to need to end up supporting (without review of those extensions ever needing to be done by any standards development org)
  423. # [15:36] <Julian> Right now I think there's a tendency to sacrifice consistency with XHTML because of an unknown number of pages being broken; potentially few, mainly base don an aversion against namespaces
  424. # [15:37] <Julian> Mike, large vendors do that with and without namespaces (canvas)
  425. # [15:37] <MikeSmith> Julian: yeah, that's one case, I'll admit
  426. # [15:38] <MikeSmith> none of us are completely thrilled with the way canvas came about
  427. # [15:38] <anne> including Apple
  428. # [15:38] <MikeSmith> it would be a much better spec now if it had evolved differently
  429. # [15:38] <Philip> MikeSmith: Why would any new syntax make it any easier for someone to unilaterally introduce de factor extensions?
  430. # [15:38] <Philip> It seems like the current approach (make a name, use it) is already pretty simple
  431. # [15:39] <Philip> s/factor/facto/
  432. # [15:40] <Philip> and such extensions can only be discouraged through social pressure (tell people to discuss things in standards groups first), not through making the syntax for extensions a little bit harder
  433. # [15:40] <anne> Julian, I think the tendency is there because the compat argument is not being taken seriously
  434. # [15:40] <anne> and I don't think it's a sacrifice because this was never consistent to start with
  435. # [15:42] <Julian> Anne, of course compatibility needs to be taken seriously; but doing so requires more than hand waving; this is why I'm interested to find out what pages Opera 8.* had problems with.
  436. # [15:42] <MikeSmith> Philip: if a vendor make mints new elements and attributes that have some associated behavior in their products, it's imaginable that users of the content that contains those markup features end up wanting that content to work the same way in other UAs as well
  437. # [15:42] <MikeSmith> or that vendors of other UAs end needing to support that content to prevent it from "breaking" in their products
  438. # [15:43] * Quits: gavin (gavin@ (Ping timeout)
  439. # [15:43] <anne> Julian, are you sure it was Opera 8?
  440. # [15:43] <Julian> Mike, yes. This happens. No matter what the syntax is.
  441. # [15:43] <Julian> Anne, re sacrifice: it's a violation of the DOM consistency principle, isn't it?
  442. # [15:43] * Joins: gavin (gavin@
  443. # [15:44] <Julian> Anne, yes. I tested with 8.54.
  444. # [15:44] <MikeSmith> Julian: right. my point is about how prudent it would be to introduce an architectural change that makes it easier for it to happen
  445. # [15:44] <Philip> anne: I think https://bugs.opera.com/browse/DSK-117765 is relevant
  446. # [15:44] <pimpbot> Title: Login Required - Opera Bug Tracking System (at bugs.opera.com)
  447. # [15:45] <Julian> All I' trying to find out is the amount of breakage. If Opera up to (excl) 9 got away with it, it may not be that big of an issue. You have the data.
  448. # [15:45] <Philip> (just in case you're not aware of that already)
  449. # [15:45] <Julian> Mike, how would it be easier?
  450. # [15:46] <anne> Philip, I was looking at that
  451. # [15:46] <Philip> MikeSmith: I don't see why that's relevant to "an easier means", since they can create new elements and attributes and behaviours already (and often do) without namespaces
  452. # [15:47] * jgraham notes that IE alone amongst browser vendors, is willing to break compat by introducing per0version modes
  453. # [15:47] <jgraham> So it may not be so bad to have a larger breaking change for IE on the assumption that they will not implement it in their legacy mode
  454. # [15:47] <anne> seems it was in 7.3 and up until 8.5 or 9
  455. # [15:48] <Julian> 9.0 changed it
  456. # [15:48] <hsivonen> jgraham: Chrome Frame is proof by implementation that a mode that has the traits of the "everything else" path can work in IE
  457. # [15:48] * Quits: myakura (myakura@ (Quit: Leaving...)
  458. # [15:48] <MikeSmith> Julian: it would facilitate the minting of new elements and attributes that would be seen simply as vendor-specific but that do to market realities would end up needing to be supported by other vendors, without those other vendors ever having a chance to be involved in the design of those features
  459. # [15:49] <MikeSmith> Philip: yeah, they can do that, but there is a strong social pressure now against them doing so
  460. # [15:49] <MikeSmith> this would remove some of that social pressure and give more freedom innovate
  461. # [15:49] <MikeSmith> (scare quotes implied)
  462. # [15:50] <MikeSmith> *freedom to innovate
  463. # [15:50] <Philip> hsivonen: That doesn't seem a convincing proof, because it has about zero market share so it doesn't show a successful browser can do that, and also because it's opt-in so it only uses the "everything else" path on pages that are very likely to have explicitly tested that path in Chrome Frame
  464. # [15:50] <hsivonen> Philip: it indeed doesn't show that the everything else path can be the default if the UA string contains "MSIE"
  465. # [15:51] <jgraham> MikeSmith: In your opinion would <com.apple.canvas> have been better or worse (say using it produced a "proprietry extension" warning, but not an error, in the validator)
  466. # [15:51] <MikeSmith> better
  467. # [15:51] <MikeSmith> (for what my opinion is worth)
  468. # [15:51] <MikeSmith> or com_apple_canvas
  469. # [15:51] <Philip> hsivonen: I'm not sure it shows anything other than that it is possible to create a page which works in Chrome
  470. # [15:52] <MikeSmith> jgraham: despite its ugliness
  471. # [15:52] <Philip> which doesn't seem a very novel thing to know
  472. # [15:52] <hsivonen> I wonder if com_apple_canvas would have hindered canvas enough for SVG to have more mindshare than canvas today
  473. # [15:52] <jgraham> MikeSmith: I think ugliness may be a virtue in this case
  474. # [15:52] <MikeSmith> jgraham: yep
  475. # [15:52] <MikeSmith> amen
  476. # [15:52] <hsivonen> Philip: could be
  477. # [15:52] <MikeSmith> I was just typing that
  478. # [15:53] <hsivonen> Philip: note that I don't think Chrome Frame is a particularly good thing
  479. # [15:53] <hsivonen> Philip: but it does make some stuff about engine mode less theoretical
  480. # [15:53] <MikeSmith> jgraham: one way of looking at it is, the provenance should be obvious and the name as ugly as possible
  481. # [15:54] <MikeSmith> jgraham: but again, as usual, wthdik
  482. # [15:56] <hsivonen> MikeSmith: there's a way to work around the provenance issue by doing what Google did with the Rich Snippets vocabularies
  483. # [15:56] <MikeSmith> hsivonen: what was that?
  484. # [15:57] <hsivonen> MikeSmith: instead of having google.com in the names, they had data-vocabulary.org
  485. # [15:57] <MikeSmith> ah
  486. # [15:57] <Philip> Maybe we should require proprietary extensions to be written in AlTeRnAtInGcAsE, so the ugliness discourages their use
  487. # [15:57] <MikeSmith> heh
  488. # [15:58] <hsivonen> that way, you don't look like a big dot com minting proprietary stuff but you look like a benign dot org.
  489. # [15:59] <MikeSmith> sounds like the way political-action committees in the US name themselves to appear grass-roots
  490. # [16:00] <Philip> (And then you document the namespace URI in three different ways over the course of a couple of days)
  491. # [16:00] <Philip> (and then you parse documents by ignoring the namespace entirely and just matching the localName)
  492. # [16:01] <Philip> s/different ways/different spellings/
  493. # [16:01] <MikeSmith> hsivonen: e.g., something like "People for a Freedom and a Better Tomorrow" (hypothetically)
  494. # [16:01] <Dashiva> Only a freedom? Not freedoms?
  495. # [16:02] <MikeSmith> Dashiva: definitely not "freedoms" -- just "freedom", as in "The enemies of freedom want us to give up the war against terrorism". etc.
  496. # [16:03] <mjs> canvas made us reluctant to extend the Web like that again without going to standards bodies early
  497. # [16:04] <mjs> <com_apple_canvas> would have been worse than <canvas>
  498. # [16:04] <mjs> because if the eventual standard version was named <canvas>, there would be a period when content had to use both, but there's almost no way to make that work right
  499. # [16:05] <mjs> what would have been better is for Apple to take our innovation to a standards body sooner, before there were compatibility issues
  500. # [16:05] <Philip> How about: <div proprietary-semantics="com.apple.canvas">
  501. # [16:05] <MikeSmith> mjs: your bad
  502. # [16:05] <MikeSmith> mjs: please don't do it again
  503. # [16:05] <Philip> then you could write <div proprietary-semantics="com.apple.canvas org.mozilla.canvas">
  504. # [16:05] <Philip> while everyone has non-standard versions, like in CSS
  505. # [16:06] <mjs> almost all recent stuff we've put into WebKit we either took to standards first, or as soon as possible
  506. # [16:06] <Dashiva> <distributed-extension semantic="com.apple.canvas">
  507. # [16:06] <Philip> and then you could write <canvas proprietary-semantics="com.apple.canvas org.mozilla.canvas"> during transition to the standard
  508. # [16:06] <mjs> with CSS, it's a bit easier to make extensions without constraining future standards in the area
  509. # [16:06] <Philip> and then the standard lets you just write <canvas>
  510. # [16:06] <mjs> since you can specify multiple vendor-specific properties in a way that just doesn't work with elements
  511. # [16:06] <mjs> although a vendor prefix system for *attributes* would work fine, IMO
  512. # [16:07] <Philip> (You also get sensible fallback behaviour in non-supporting UAs when you use <div proprietary-semantics> because you can choose an appropriate element)
  513. # [16:07] <mjs> one thing I am concerned about is that Google is much less hesitant to ship a completely nonstandard feature as a built-in part of the browser
  514. # [16:07] <Philip> Dashiva: That loses the fallback behaviour
  515. # [16:07] <MikeSmith> about the current proposal, would be be too much to ask the advocates of the proposal to articulate what the benefit of it would be for the mass of end users of the public Web? (even a statement of the indirect benefit to the public Web)
  516. # [16:08] <mjs> (Gears, Native Client, O3D, other smaller examples that they sometimes propose to put in WebKit)
  517. # [16:08] <Philip> Google seems to have a strange relationship with standards
  518. # [16:08] <mjs> MikeSmith: I think it's valid for a feature to only have benefit for, say, authors and data mining content consumers
  519. # [16:09] <MikeSmith> mjs: sure it is, but the costs and risks of it need to be evaluated relative to other features that UA vendor could be spending their time on implementing
  520. # [16:09] <MikeSmith> like, say, Web Forms 2 support
  521. # [16:10] * Quits: gavin (gavin@ (Ping timeout)
  522. # [16:10] <MikeSmith> or un-fubarred support for drag and drop
  523. # [16:11] * Joins: gavin (gavin@
  524. # [16:11] * Philip wonders how commonly normal users use drag-and-drop
  525. # [16:11] <Philip> (I pretty much never use it for anything ever)
  526. # [16:11] * Joins: tlr_ (tlr@
  527. # [16:11] <MikeSmith> Philip: every time they drag and drop something in a Web application
  528. # [16:11] <Philip> (so I'm always surprised when I find a combination of applications where it actually does something pretty handy)
  529. # [16:11] <hsivonen> Philip: do Flickr Organizr users count as "normal"?
  530. # [16:12] <MikeSmith> Philip: or actually, every time they drag and drop something in a non-Web application
  531. # [16:12] <Philip> MikeSmith: The only time I ever remember dragging-and-dropping something in a web application is when I accidentally drag Gmail labels around a bit and then hope it didn't break anything
  532. # [16:12] <Philip> hsivonen: Probably
  533. # [16:13] * Quits: tlr (tlr@ (Ping timeout)
  534. # [16:13] * tlr_ is now known as tlr
  535. # [16:13] <MikeSmith> Philip: so that seems to argue for vendors to make it work reliably do that users don't have to worry about it breaking
  536. # [16:14] <MikeSmith> Philip: you don't avoid dragging stuff around on your OS desktop for fear of it breaking
  537. # [16:14] <MikeSmith> (not unless you use a Linux desktop, at least)
  538. # [16:15] <Philip> MikeSmith: The reliability isn't the problem - the problem is that the semantics of click-and-forget-to-release-mouse-button-and-then-move-a-bit-and-release (i.e. drag-and-drop) is not the same as click-and-release-and-move-a-bit
  539. # [16:16] <mjs> MikeSmith: well, Microsoft's proposal articulated some potential benefits to authors and developers of nonstandard extensions
  540. # [16:16] <mjs> MikeSmith: I would assume that if they saw an end-user benefit, they would cite that
  541. # [16:16] <MikeSmith> Philip: well, clearly we should then just give up on trying to get drag-an-drop working in Web applications and just focus on decentralized extensibility instead
  542. # [16:16] <Philip> ("forget-to-release-mouse-button" is particularly easy on touchpads)
  543. # [16:16] <hsivonen> mjs: Microsoft's proposal did, but it's not clear to me if Sam's goals are the same as Microsoft's
  544. # [16:17] <Philip> MikeSmith: I wasn't saying it wasn't useful in general, I was just wondering how useful it was for normal people, because I have no idea and all I know is that it's never been excessively useful for me personally :-)
  545. # [16:17] <MikeSmith> mjs: not having clear benefits for end users is a serious reason to be suspicious of any feature
  546. # [16:17] <mjs> MikeSmith: it might be worth asking about, but maybe not in a way that implies their proposal is invalid if it fails to state an end-user benefit
  547. # [16:18] <Philip> (and I never dragged-and-dropped much when I was using Windows, before switching to a Linux desktop :-p )
  548. # [16:18] <mjs> hsivonen: I'll be much more interested in what Sam's goals are when/if he states a technical position
  549. # [16:18] <MikeSmith> mjs: I'm not saying it makes it invalid. just that it may make it less of priority than the other features that would be of clear benefit to end users
  550. # [16:18] <MikeSmith> mjs: like, say, datagrid
  551. # [16:19] <mjs> MikeSmith: that would be how I'd prioritize things, sure
  552. # [16:20] <MikeSmith> mjs: I would hope it'd be the way that any UA vendor would prioritize things
  553. # [16:20] <hsivonen> mjs: did Sam ask MS to submit a proposal? From where I'm observing, Sam mentioned "distributed extensibility" long before Microsoft.
  554. # [16:20] <MikeSmith> mjs: but maybe that's just me
  555. # [16:20] <mjs> hsivonen: he did way more than ask
  556. # [16:21] <Philip> http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility helpfully stated "this feature’s use case is to enable features without use cases"
  557. # [16:21] <pimpbot> Title: Sam Ruby: HTML5 and Distributed Extensibility (at intertwingly.net)
  558. # [16:21] <hsivonen> mjs: then Sam's goals seem relevant to understanding the whole thing
  559. # [16:21] <mjs> hsivonen: he's been, er, very strongly encouraging them about it since back when it was still Chris Wilson's action item
  560. # [16:23] <mjs> hsivonen: if he's unwilling to give a rationale, but also unwilling to take a technical position against the spec, or in favor of a different specific proposal, then I am ok with that
  561. # [16:23] <mjs> hsivonen: if he takes a technical position, then yes, he'd better justify it
  562. # [16:24] <mjs> I have invited him quite explicitly to take a technical position on the narrow technical issue that he wanted to focus on
  563. # [16:24] <mjs> if he wants to start with a problem to be solved and then move on to the solution space, that's fine with me too
  564. # [16:25] * Quits: gavin (gavin@ (Ping timeout)
  565. # [16:25] * Joins: gavin (gavin@
  566. # [16:26] <Julian> as far as I know, the level of HTML "namespace" support has allowed MathPlayer to do what it does in IE. That sounds like a solid use case to me.
  567. # [16:27] <hsivonen> Julian: It is a use case, yes. Whether it's a good one depends on whether it makes the MathPlayer-using content locked into IE or whether the content works natively in other browsers that implement MathML natively to spec
  568. # [16:28] <hsivonen> Julian: initially, IIRC, MathPlayer-targeted content didn't work in Mozilla
  569. # [16:28] <hsivonen> Julian: because initially IE+MathPlayer used text/html
  570. # [16:28] <hsivonen> Julian: and Mozilla had per-spec MathML support only on the XML side
  571. # [16:29] <MikeSmith> I wonder what the results would be if we did a study with 7 end users (or even 7 professional Web developers) and asked them how high "decentralized extensibility" was on their list of priorities. And I wonder how different the response would be if we asked 70, or 700, or 7000
  572. # [16:29] <hsivonen> long before HTML5 parsing adding MathML-in-text/html support to the standards world
  573. # [16:29] <Julian> yes, that's a problem. Maybe we should ask MS to finally support XHTML in exchange for considering their ns proposal
  574. # [16:30] <Julian> Henri, I know that.
  575. # [16:30] <MikeSmith> Julian: MS won't support XHTML as long as supporting XHTML means support catch-fire-and-fail error handling in Web content
  576. # [16:30] <Philip> MikeSmith: I suggest asking them how high "widget frobnification" is on their list of priorities
  577. # [16:30] <Julian> Sounds like a case where distributed extensibility worked out very well.
  578. # [16:31] <Philip> MikeSmith: Has MS stated that?
  579. # [16:31] <MikeSmith> Philip: I expect that would rank higher, if not just for the fact that it sounds slightly pornographic
  580. # [16:31] <Philip> (They seem happy to implement draconian error handling in every other part of the browser and OS that uses XML)
  581. # [16:31] <Philip> (as far as I'm aware)
  582. # [16:31] <hsivonen> whether IE's extensibility looks nice depends on whether it is used for backporting new standards features to old IE or whether it's used for launching new features that lock content into IE
  583. # [16:31] <MikeSmith> Philip: it's easy enough to infer it, even for somebody as simple-minded as me
  584. # [16:32] <Philip> MikeSmith: Ah, right, so you mean you're just making it up? :-)
  585. # [16:32] <hsivonen> there's also a different kind of client extensibility
  586. # [16:32] <MikeSmith> Philip: yeah, along with most everything else I say
  587. # [16:33] <MikeSmith> Philip: I don't bother with "data" -- because as we have all learned "data" is suspect
  588. # [16:33] <hsivonen> for example, using Cooliris in Firefox to view Flickr photosets in Firefox doesn't lock a phone or Linux user out of being able to view the photos
  589. # [16:33] * Philip generally assumes it's more an issue of cost (rewiring all IE's HTML DOM to support Namespaces) vs benefits (nobody uses XHTML), rather than philosophical objections to XHTML itself
  590. # [16:33] <MikeSmith> we should all just rely on expert opinions (me being the main expert to consult)
  591. # [16:34] <Philip> MikeSmith: Maybe you can be the expert in experts, so you can recommend experts to consult for various features
  592. # [16:35] <Julian> Mike, unless I'm missing something they are doing draconian error handling for Atom.
  593. # [16:35] <Philip> That saves you having to do the actual consulting work yourself
  594. # [16:36] <hsivonen> Philip: it seems that MS's "decentralized extensibility" proposal would require rewiring, too
  595. # [16:36] <Philip> hsivonen: It would, as would HTML5 support
  596. # [16:36] <Philip> Once they've done that it seems like it should be relatively trivial to support XHTML
  597. # [16:37] <Philip> though only because I have no idea of the implementation complexities involved
  598. # [16:38] * hsivonen thinks the QA burden of supporting XHTML is non-trivial
  599. # [16:38] <Philip> The PR benefit is non-trivial too
  600. # [16:39] <Philip> given that it's a common complain against IE's standards compliance, for highly technical authors
  601. # [16:39] <Philip> *complaint
  602. # [16:43] <MikeSmith> Julian: I'm trying to decide whether "native Atom support my browser" would rank higher or lower to end users than "decentralized extensibility" would. Or where it would rank relative to "Allow me to do my banking using my browser" or "Allow me to book airline tickets using my browser"
  603. # [16:44] <Julian> Again, end users do not care about how something works.
  604. # [16:45] <MikeSmith> right. they care instead about if/how something breaks
  605. # [16:45] <Julian> Yes. But just because *something* breaks doesn't mean it#s the wrong thing to do. The question really is "how much" breaks?
  606. # [16:47] <MikeSmith> Julian: see my earlier statement about where the burden of proof for that should be
  607. # [16:51] <MikeSmith> ..which statement is a hypothetical one that postulates an opinion that somebody other than me might reasonably be expected to have (since I personally need to pretend to be^W^W^W remain completely unbiased)
  608. # [16:53] * Quits: gavin (gavin@ (Ping timeout)
  609. # [16:54] * Joins: gavin (gavin@
  610. # [17:01] * Quits: shepazu (schepers@ (Ping timeout)
  611. # [17:03] * Quits: Marcos (Marcos@ (Quit: Marcos)
  612. # [17:04] * Joins: Marcos (Marcos@
  613. # [17:05] * Quits: Marcos (Marcos@ (Quit: Marcos)
  614. # [17:05] * Joins: Marcos (Marcos@
  615. # [17:06] * Quits: Marcos (Marcos@ (Quit: Marcos)
  616. # [17:06] * Joins: Marcos (Marcos@
  617. # [17:46] <pimpbot> bugmail: [Bug 7810] New: Maybe it's just me, but this paragraph is unclear to me. It is too difficult to understand. What is transparent content? <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0057.html> ** [Bug 7809] New: The character ranges in this section should follow the conventions of other ranges. I.e. "to" instead of ".." and the name of the character directly after the Unicode code point. <http://lists.w3.org/Archives/P
  618. # [18:00] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  619. # [18:00] * Quits: hsivonen (hsivonen@ (Ping timeout)
  620. # [18:09] * Joins: hsivonen (hsivonen@
  621. # [18:38] * Joins: shepazu (schepers@
  622. # [19:06] * Joins: sryo (sryo@
  623. # [19:07] * Quits: sryo (sryo@ (Quit: Leaving.)
  624. # [19:40] * Joins: sbublava (sbublava@
  625. # [20:02] * gsnedders is now known as gsnedders|work
  626. # [20:13] * Quits: mjs (mjs@ (Quit: mjs)
  627. # [20:28] * Joins: gsnedders (gsnedders@
  628. # [20:45] * Quits: gsnedders (gsnedders@ (Quit: Adios intarwebs.)
  629. # [21:18] * Joins: J_Voracek (irchon@
  630. # [21:18] * Quits: J_Voracek (irchon@ (Client exited)
  631. # [21:18] * Quits: tlr (tlr@ (Quit: tlr)
  632. # [21:22] * Joins: mjs (mjs@
  633. # [21:57] * Quits: sbublava (sbublava@ (Quit: sbublava)
  634. # [22:00] * Joins: tlr (tlr@
  635. # [22:01] * Quits: tlr (tlr@ (Client exited)
  636. # [22:03] * Quits: ChrisWilson (cwilso@ (Ping timeout)
  637. # [22:09] * Joins: ChrisWilson (cwilso@
  638. # [22:49] * Quits: ROBOd (robod@ (Quit: http://www.robodesign.ro )
  639. # [23:16] * Joins: sephr (elijah@
  640. # [23:17] * Joins: heycam (cam@
  641. # [23:17] <sephr> what codec do I put in a <source type> for MP3? I have <source>s for OGG vorbis that are audio/ogg;codecs=vorbis but I don't know what audio/mpeg;codecs= should be
  642. # [23:19] <sephr> the only relevant google result is someone asking the same question on IRC
  643. # [23:31] * Joins: mjs_ (mjs@
  644. # [23:33] * Quits: mjs (mjs@ (Ping timeout)
  645. # [23:33] * mjs_ is now known as mjs
  646. # [23:45] * Quits: tH (Rob@ (Quit: ChatZilla 0.9.85-rdmsoft [XULRunner])
  647. # [23:47] * Quits: sephr (elijah@ (Quit: Ex-Chat)
  648. # [23:55] * Quits: plh (plh@ (Quit: always accept cookies)
  649. # Session Close: Tue Oct 06 00:00:00 2009

The end :)