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

Options:

# Session Start: Mon Oct 05 00:00:00 2009
# Session Ident: #html-wg
# [00:06] * Joins: gsnedders (gsnedders@83.252.227.76)
# [00:09] * Quits: gsnedders (gsnedders@83.252.227.76) (Quit: gsnedders)
# [00:30] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
# [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>
# [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>
# [01:18] * Joins: mjs (mjs@69.181.42.237)
# [01:33] * Joins: tH (Rob@82.4.89.172)
# [01:34] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [01:39] * Joins: mjs_ (mjs@69.181.42.237)
# [01:39] * Quits: mjs (mjs@69.181.42.237) (Connection reset by peer)
# [01:39] * mjs_ is now known as mjs
# [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>
# [01:41] * Quits: karl (karlcow@128.30.54.58) (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.)
# [01:42] * Joins: Hixie (ianh@129.241.93.37)
# [02:17] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
# [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>
# [03:01] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [03:07] * Joins: gavin (gavin@99.226.207.11)
# [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>
# [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
# [03:47] <mjs> Hixie: I'm waiting until I understand Sam's point enough to not accidentally file dueling bugs
# [03:47] <Hixie> sure
# [04:13] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
# [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
# [04:32] * trackbot attempting to add a note to ISSUE-83.
# [04:32] <trackbot> ISSUE-83 Use of the dt and dd elements in figure and details content models notes added
# [04:32] <pimpbot> Title: [whatwg] The new content model for breaks rendering in MSIE5-7 (at lists.whatwg.org)
# [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>
# [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>
# [05:41] <pimpbot> changes: hixie: Disallow ` in unquoted attribute values. (whatwg r4076) <http://lists.w3.org/Archives/Public/public-html-diffs/2009Oct/0010.html>
# [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>
# [06:41] * Joins: shepazu (schepers@128.30.52.169)
# [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>
# [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>
# [07:15] * Quits: syp (syp@128.178.82.67) (Ping timeout)
# [07:15] * Joins: syp (syp@128.178.82.67)
# [07:15] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [07:39] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
# [07:41] <MikeSmith> issue-73?
# [07:41] * trackbot getting information on ISSUE-73
# [07:41] <trackbot> ISSUE-73 -- Overlap of "predefined vocabularies" with other specifications -- OPEN
# [07:41] <trackbot> http://www.w3.org/html/wg/tracker/issues/73
# [07:41] <pimpbot> Title: ISSUE-73 - HTML Weekly Tracker (at www.w3.org)
# [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.
# [07:44] * trackbot attempting to add a note to ISSUE-73.
# [07:44] <trackbot> ISSUE-73 Overlap of "predefined vocabularies" with other specifications notes added
# [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)
# [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>
# [08:29] * Quits: Zeros (_icond@96.255.47.51) (Quit: Leaving)
# [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>
# [09:12] <pimpbot> bugmail: [Bug 7657] Redefining dt and dd <http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Oct/0044.html>
# [09:17] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [09:23] * Joins: gavin (gavin@99.226.207.11)
# [09:36] <pimpbot> planet: HTML5 Ajax to a different domain? <http://stackoverflow.com/questions/1500275/html5-ajax-to-a-different-domain>
# [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
# [09:44] * Joins: tlr (tlr@128.30.52.169)
# [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>
# [10:26] * Joins: annevk (opera@84.215.133.38)
# [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>
# [10:45] * Joins: ROBOd (robod@89.122.216.38)
# [10:58] * Joins: gsnedders (gsnedders@88.131.66.80)
# [11:16] * Joins: Julian (chatzilla@217.91.35.233)
# [11:29] * Joins: Marcos (Marcos@213.236.208.22)
# [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.)
# [11:31] <Marcos> Also, change study to "preliminary study"
# [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?
# [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
# [11:32] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [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)
# [11:32] <Marcos> That should be at the top
# [11:33] <Marcos> Your framing of the article is deceptive
# [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
# [11:33] <Hixie> the study wasn't "preliminary", as far as i know it's the only study anyone has planned
# [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
# [11:34] <Hixie> so basically, i disagree with all your requests, and don't think that the article was "deceptive" at all
# [11:34] <Hixie> it's just describing what we did, matter-of-factly
# [11:35] <Hixie> what do you think the post tries to be deceptive about?
# [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.
# [11:38] <Hixie> the whole point of usability studies is to make such generalisations
# [11:38] <Hixie> as the papers you posted mentioned, problems found by one person often affect many other people
# [11:38] <Marcos> Hence me labelling it as a pseudo science
# [11:39] <Hixie> problems found by three people almost always affect almost everyone
# [11:39] <Hixie> i don't think it's science at all
# [11:39] <Hixie> it's just language design
# [11:40] <Marcos> Hang, so you promise me you will never use this data to support your position about the usability of microdata?
# [11:40] <Hixie> quite the opposite, that would be quite the waste of money
# [11:40] <Hixie> it'd be stupid to find out that people get confused by the term 'about' and then to ignore that!
# [11:41] <Marcos> But you didn't find that! You found that 7 people got confused.
# [11:41] <Marcos> Maybe even less
# [11:41] <Hixie> dude, i generally base changes in the spec on what _one_ person says is confusing
# [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
# [11:42] <Hixie> of course i'm not going to ignore it
# [11:42] <Hixie> i will take it as input just like i take everything else as input
# [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.
# [11:43] <Hixie> o_O
# [11:43] <Marcos> Also, I'm not asking you to ignore it. All data is useful. Just to put it into perspective.
# [11:43] * jgraham does see how those two things are related really
# [11:43] <Hixie> are you saying itemprop=about is clearer than itemid=""?
# [11:44] <Hixie> i really don't understand what you're objecting to here
# [11:44] <Hixie> how else are we supposed to find out if microdata is well-designed?
# [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
# [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
# [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
# [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.
# [11:46] <jgraham> (I guess one can look at which existing features authors tend to get wrong and try to avoid those design patterns)
# [11:47] <jgraham> Marcos: Do you have any specific conclusions that you think are wrong?
# [11:47] * jgraham doesn't really understand the issue here
# [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)
# [11:50] * Quits: annevk (opera@84.215.133.38) (Quit: annevk)
# [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).
# [11:52] <Marcos> for instance s/people/participants in the study
# [11:53] <Hixie> the whole point of usability studies is that they are representative of people
# [11:54] <Hixie> if 3 people out of 3 find something confusing, conclusing that that thing is not confusing is... not the best conclusion
# [11:54] <Marcos> Hixie, that assumption is fundamentally flawed.
# [11:54] <Hixie> no, it's really not
# [11:55] <Hixie> even the papers you cited support that assumption
# [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)
# [11:55] <Hixie> but we weren't doing that -- we were testing for specific issues
# [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
# [11:56] <jgraham> Say a feature is OK if 10% of people find it confusing
# [11:57] * Philip notes that confusingness is not a boolean property
# [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?
# [11:57] <Hixie> Marcos: please, do!
# [11:57] <Hixie> Marcos: the more the better!
# [11:57] <jgraham> Philip: Imagine a threshold of confusingness set by the ability to perform some task :)
# [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
# [11:59] <jgraham> Philip: I'm not sure that's relevant if you set the right criteria
# [12:00] <jgraham> e.g. if your criteria are <10% of the population myst be able to do task x
# [12:00] <jgraham> *must
# [12:00] * Joins: myakura (myakura@118.6.236.217)
# [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?
# [12:02] <Hixie> that's actually even better than i expected
# [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
# [12:03] <Hixie> (having not previously thought about it)
# [12:03] <jgraham> Hixie: That sounds right to me but I was never very good at stats
# [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
# [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
# [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
# [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
# [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.
# [12:09] <Hixie> (assuming you decided that 10% failing is the acceptable limit)
# [12:20] <Philip> Hmm, I see what you mean now
# [12:20] <Philip> but I can't convince myself it's correct
# [12:21] <mjs> it's a well-known result in usability testing that past 6-10 participants, further testing gives diminishing returns
# [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
# [12:21] <mjs> I don't know if that's ever been corroborated for usability of markup languages as opposed to user interfaces
# [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
# [12:23] <jgraham> mjs: Do you knhow of any instances of anyone actually doing usability testing of markup languages before?
# [12:23] <mjs> jgraham: no
# [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
# [12:24] <Hixie> i actually had been hoping to do it ever since coming to google
# [12:24] <Hixie> but it's very hard to test markup, since generally you want implementations
# [12:24] <Hixie> with microdata we got away with just testing things without an implementation
# [12:24] <mjs> (though for features inherited from HTML4, surveying Web content is a sort of after-the-fact usability testing)
# [12:25] <Hixie> yeah
# [12:25] <mjs> for things that need implementations, it would probably be too high a cost to make throwaway implementations just for testing
# [12:26] <mjs> (well, other than things that can be simulated well enough with CSS or script)
# [12:26] <Hixie> indeed
# [12:26] <Hixie> there are few things for which that isn't hte case though
# [12:26] <Hixie> microdata is the first i've come across
# [12:29] <hsivonen> Marcos: why is the age and sex of the participants relevant?
# [12:30] <Marcos> hsivonen: the participants were 3 years old, and didn't speak english. They found "about" confusing
# [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
# [12:31] <Hixie> Marcos: as i mention in the blog post, all the participants were web developers familiar with HTML.
# [12:31] <Philip> Aren't most 3 year olds familiar with HTML nowadays?
# [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!)
# [12:32] <Marcos> What does familiar mean? What does web developer mean?
# [12:32] <Marcos> does it mean that they worked professionally?
# [12:32] <Marcos> If so, for how many years?
# [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)
# [12:34] <Hixie> the length of time had no correlation to their competence
# [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
# [12:34] <hsivonen> Marcos: unless Hixie was randomizing his pronoun gender for NDA reasons
# [12:34] <mjs> that or Hixie is switching pronouns to be gender-neutral
# [12:35] <Hixie> several were software engineers, several were professional web developers at silicon valley companies, either currently or recently
# [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
# [12:35] <Hixie> we have recruiters and screeners to pick a good sample of people
# [12:36] <Hixie> you can look at the raw result files i uploaded to get an idea of how competent each participant was
# [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
# [12:36] <mjs> I don't know if this result generalizes to usability testing a markup language though
# [12:36] <Hixie> yeah we explicitly excluded anyone who claimed to know much about html5
# [12:36] <Hixie> just in case
# [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
# [12:36] <hsivonen> s/change/chance/
# [12:37] * Joins: anne (annevk@213.236.208.22)
# [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
# [12:37] <hsivonen> Marcos: not necessarily an exhaustive set of fixable items, though
# [12:38] <hsivonen> Marcos: is there any method (short of testing the entire population) that you'd be happy with?
# [12:40] * hsivonen hasn't actually read the blog post yet
# [12:41] <Marcos> mjs, what studies do you have to validate that?
# [12:42] <mjs> the Wikipedia article on Usability Testing has some links to research: http://en.wikipedia.org/wiki/Usability_testing
# [12:42] <pimpbot> Title: Usability testing - Wikipedia, the free encyclopedia (at en.wikipedia.org)
# [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
# [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?
# [12:45] <jgraham> Philip: Does using Bayes theroem with an appropriate choice of prior help?
# [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.
# [12:46] <jgraham> (I'm not sure if you have the right information for that though...)
# [12:46] <Philip> jgraham: No, because the prior is one of the things we don't know
# [12:46] <hsivonen> Marcos: isn't the relevant question whether the findings should be treated as actionable in spec writing?
# [12:46] <Philip> jgraham: (or two of the things, I guess)
# [12:47] <Marcos> hsivonen: yes.
# [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?
# [12:47] <jgraham> Philip: Not knowing the prior is quite normal when using Bayes theroem
# [12:48] <Marcos> hsivonen: potentially, yes.
# [12:48] <jgraham> (I'm more troubled about not knowing p(3/3 failed) which acts as the normalising constant
# [12:48] <hsivonen> Marcos: shouldn't Occam's Razor or a similar device address that concern?
# [12:48] <jgraham> )
# [12:48] <anne> Marcos, so most spec writing causes harm then, since generally it's based on the opinions of a single person...
# [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"
# [12:49] <hsivonen> mjs: that was my observation, too
# [12:49] <Hixie> mjs: indeed
# [12:49] <Marcos> mjs: agree, but it could happen. It can't be discounted. Specially in such a small sample size
# [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)
# [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
# [12:50] <hsivonen> Marcos: there could also be a celestial teapot :-)
# [12:50] <Marcos> Anne, I have never seen a spec based on the opinions of a single person
# [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
# [12:50] <hsivonen> Marcos: "it could happen" isn't a very convincing argument
# [12:50] <Marcos> hsivonen: sure. We cannot discount that either
# [12:50] <Hixie> marcos: most of changes in html5 are based on feedback from individuals
# [12:51] <Marcos> Hixie, but how many emails have you received as feedback?
# [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
# [12:51] <Hixie> Marcos: on each individual feature? usually none.
# [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
# [12:51] <mjs> to suggest that a change makes things worse would require some kind of evidence to rebut that assumption
# [12:51] <Marcos> Hixie, you are to a large degree harnessing the collective intelligence when interpreting the emails.
# [12:52] <Hixie> Marcos: not really, since on most features, very few people post, if any.
# [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.
# [12:52] <mjs> (that can even be a pure a priori argument identifying a potential new problem)
# [12:53] <mjs> one usability testing subject is more valuable than one email's worth of self-reported experience
# [12:53] <mjs> it's well known that self-reported experiences of self-selected users give a misleading picture, in general
# [12:54] <anne> Marcos, for many features of XMLHttpRequest I've either received no feedback or feedback from just one person
# [12:54] <Marcos> mjs, why? that assumes that usability studies have more weight than emails
# [12:54] <Marcos> Anne, citing individual cases is unhelpful.
# [12:54] <jgraham> Marcos: Everyone is very bad at giving an accurate report of their own experience
# [12:54] <mjs> Marcos: a well-reasoned argument may (in some cases) have more weight than a usability test
# [12:54] <hsivonen> Marcos: you get better data by observing other people than by introspection
# [12:55] <mjs> Marcos: but emails that say "I found this easy/hard" are of very little value
# [12:55] <mjs> or even emails that say "I found step X hard and it should be changed to Y"
# [12:55] <mjs> at least, that's my experience with software user interface
# [12:56] <anne> Marcos, ok, for all specs I write for most features I've either received no feedback or feedback from one person :)
# [12:56] <mjs> problem reports from trained programmers or testers are more useful, because they tend to identify concrete bugs
# [12:56] <mjs> although ones that claim something would be easier "for my grandmother" tend to be dubious
# [12:57] <Marcos> You don't gather data from crash reports also?
# [12:57] <mjs> (again though, most of what I say, I only have experience and research in the area of mainstream software user interface)
# [12:57] <mjs> we do, though crash reports are not self-reported experiences
# [12:57] <hsivonen> I think actually observing one's grandparent fail at a computer task is a valid way of discoving usability bugs
# [12:57] <mjs> we analyze them statistically
# [12:57] <hsivonen> I discovered bad design in Ubuntu's update notification that way
# [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
# [12:58] <hsivonen> mjs: sure
# [12:58] <Dashiva> Actually observing grandma is different
# [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
# [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
# [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
# [13:18] <pimpbot> Title: xml-dev - Re: [xml-dev] A heavier-weight proposal for character entitydefinition (at lists.xml.org)
# [13:19] <hsivonen> seems a bit excessive for XML use in embedded systems
# [13:31] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
# [13:33] <mjs> that does not seem like a great proposal
# [13:35] <anne> just enlarging the default entity set to all the mathml ones seems good enough
# [13:36] * Quits: Marcos (Marcos@213.236.208.22) (Ping timeout)
# [13:37] <mjs> you can already enter any character by literally entering it, or by using an NCR
# [13:37] <mjs> it seems excessive to add a third way to input all other characters (in cases where this is not already available)
# [13:37] <pimpbot> planet: toDataURL, Canvas, and SVG <http://feedproxy.google.com/~r/ajaxian/~3/B-vpAVOaz3Q/todataurl-canvas-and-svg>
# [13:39] * Joins: Marcos (Marcos@213.236.208.247)
# [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
# [13:44] * Quits: Marcos (Marcos@213.236.208.247) (Quit: Marcos)
# [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 :-)
# [13:53] * Joins: Marcos (Marcos@213.236.208.247)
# [13:57] <Julian> Would it be possible to do so without breaking a significant amout of XHTML content? Just checking.
# [13:58] <anne> most XHTML content can prolly be parsed as HTML5 just fine
# [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?
# [14:00] <jgraham> Julian: It is totally unclear to me that the colons-in-tag-names space is not horribly overconstrained
# [14:01] <Julian> James: overconstrained?
# [14:01] <jgraham> I'm not sure that much can be changed without people having to take an unacceptable compatibility risk
# [14:01] <jgraham> I'm not claiming that *nothing* could be changed
# [14:02] <Julian> I'd like to understand what that risk really is.
# [14:02] <Julian> For instance, if HTML allowed:
# [14:02] <Julian> <html xmlns:foo="bar">....<foo:x>test</foo:x></html>
# [14:03] <Julian> and the namespaceURI foor foo:x would really be "bar" -- what would break?
# [14:03] <Julian> (and yes, I know that "bar" is not a URI)
# [14:03] * gsnedders wonders if "bar" should be treated as a relative URI or should it be resolved
# [14:03] <anne> Julian, live.com and such I believe
# [14:04] <anne> Julian, and probably sites that have leftovers from MS Office products in their markup
# [14:04] <Julian> Please elaborate.
# [14:05] <Julian> live.com redirects to bing.com, which doesn't use xmlns:x=y
# [14:05] <Julian> only a default ns declaration
# [14:05] <anne> might have been their previous live properties such as mail etc. been a while
# [14:05] <jgraham> It is not impossible that *only* changing namespaceURI and not localName or anything would not break a lot
# [14:06] <jgraham> But it is far far from obvious
# [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
# [14:06] <jgraham> (and hard to prove since it requires looking at Javascript)
# [14:06] <Julian> Actually, I would want namespaceURI and localName both be changed
# [14:06] <jgraham> Julian: Oh well that seems much more likely to break stuff
# [14:07] <Julian> James, such as?
# [14:08] <jgraham> Julian: Sites with things like o:p that expect localName to be "o:p"
# [14:09] <jgraham> and in particular expect o:p elements not to show up when DOM 1 methods are used to identify p elements
# [14:09] <jgraham> (and similar considerations with CSS, depending on what exactly you would expect to happen there)
# [14:10] <Julian> James, do you have evidence of the existence of sites like these?
# [14:10] <jgraham> (and also in cases like <html><foo:bar></html> where foo: is never declared
# [14:10] <jgraham> )
# [14:10] <Julian> I don't have problems with not changing the behaviour for broken code like that.
# [14:10] <jgraham> Julian: There is an Opera bug from last time we tried to enable this and got all sorts of compat problems
# [14:11] <jgraham> I will try to look in more detail sometime
# [14:11] <jgraham> (but not now)
# [14:11] <Julian> It would be great to have this information public.
# [14:11] <Julian> Do you recall which opera version had that enabled?
# [14:11] <jgraham> Julian: I think it was 7.x Myabge also 8 Not sure
# [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)
# [14:15] <mjs> Julian: I'm not sure *any* change to parsing elements or attributes with colons in the name would break stuff
# [14:15] <mjs> Julian: I strongly suspect the following changes would:
# [14:15] <mjs> - applying namespace processing to attributes (because IE doesn't do that)
# [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)
# [14:16] <mjs> - giving effect to xmlns declarations that appear in places other than the root element (because IE doesn't do that)
# [14:17] <mjs> and we do know there is content with junk xmlns attributes in the middle
# [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
# [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.
# [14:19] <mjs> no, they don't have to run script
# [14:19] <mjs> they could apply CSS style rules
# [14:19] <Julian> CSS?
# [14:19] <Julian> Yes, I understand the CSS issue. Was jsut conforming
# [14:19] <mjs> or they could simply depend on some elements being treated like a normal html element for layout/behavior purposes
# [14:20] <Julian> I agree that all of this *could* be true.
# [14:20] <Julian> But I'd like to see numbers, or at least real-world examples.
# [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
# [14:20] <mjs> Philip posted some links to examples (including links to research last time this was discussed)
# [14:21] <Julian> that would be bad, but could be handled by introducing a new API that wasn#t there before.
# [14:21] <Julian> pointer?
# [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
# [14:22] <mjs> because we know there's significant content using namespaces in cargo cult copy/paste ways
# [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.
# [14:23] <mjs> you can't prove a negative, but you can study a statistical sample
# [14:23] <mjs> that would be good enough for me
# [14:23] <Julian> I do not disagree with that. I'd *still* see numbers and examples though.
# [14:24] <mjs> here's some data linked by Philip Taylor: http://lists.w3.org/Archives/Public/public-html/2009Oct/0076.html
# [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)
# [14:24] <mjs> here he included links to some past examples: http://lists.w3.org/Archives/Public/public-html/2009Oct/0040.html
# [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)
# [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
# [14:26] <hsivonen> Julian: I'm curious, too, but not curious enough to perform some experiments.
# [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.
# [14:28] <anne> I'd like that
# [14:28] <anne> so we don't have to go investigate if things are possible whenever someone comes up with an idea
# [14:30] * Joins: plh (plh@128.30.52.28)
# [14:35] <MikeSmith> environmental impact report
# [14:37] <pimpbot> planet: Future of Web Apps London: HTML5 <http://www.brucelawson.co.uk/2009/future-of-web-apps-london-html5/>
# [14:48] <Julian> James, I just checked: the Opera behaviour changed between 8.54 and 9.00.
# [14:49] <jgraham> Julian: Thanks
# [14:50] <Julian> so it was the behaviour until ~2.5 years ago
# [14:51] <Julian> now it would be interesting to find out what problems were reported
# [14:52] * Joins: Marcos_ (Marcos@213.236.208.247)
# [14:53] * Quits: Marcos (Marcos@213.236.208.247) (No route to host)
# [14:53] * Marcos_ is now known as Marcos
# [14:57] * Quits: Marcos (Marcos@213.236.208.247) (Ping timeout)
# [15:00] <Philip> Julian: Updated http://philip.html5.org/misc/xmlns-dom.html as suggested
# [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
# [15:01] <Julian> Philip: thanks
# [15:03] <Julian> Anne, clarifying; that will only affect namspaceURI and localName, right?
# [15:03] <anne> it affects behavior of the elements in question
# [15:03] <anne> e.g. <b> is no longer bold, <head> is no longer hidden, etc.
# [15:04] <Julian> Anne, maybe these weird values could be excluded explicitly: hard to say without seeing the data.
# [15:04] <anne> I don't know
# [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
# [15:04] <Julian> so, just because of CSS not matching, or because of additional differences in parsing?
# [15:05] <Julian> well, we can start Opera 8.x
# [15:05] <anne> CSS wouldn't match
# [15:05] <anne> in other cases people use different paths for IE and non-IE browsers
# [15:05] <Julian> ...based on the presence of what...?
# [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)
# [15:08] <Julian> Anne, but HTML5 ias asking MS to change their imp of tagName, thus getElementsByTagName("foo")
# [15:09] <Julian> or am I missing something here?
# [15:09] <Julian> If pages use that for IE they are going to break if it changes, right?
# [15:10] <anne> it depends on whether they implement all the other relevant standards correctly too
# [15:10] * Joins: Marcos (Marcos@213.236.208.22)
# [15:11] <Julian> ...and at the same time...
# [15:11] <anne> yeah, compat is hard
# [15:11] <Julian> playing the devil's advocate: sounds like it's ok to ask IE to break content, then
# [15:12] <anne> I don't think the request is made of just IE
# [15:12] <anne> it varies per section
# [15:13] <Julian> I was just referring to this part
# [15:14] <anne> I guess the answer is yes then as long as we do not ratify the proprietary extension
# [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
# [15:14] <hsivonen> Julian: is anyone asking IE to break content that works interoperably with multiple browser engines?
# [15:15] <anne> IE is supposed to be standards compliant just like other browsers
# [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.
# [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
# [15:16] <anne> hsivonen, Julian has a fair point that making all the necessary changes at once is quite a lot of work
# [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
# [15:16] <anne> and the IE Team has a history of approaching issues like this somewhat badly
# [15:17] <hsivonen> assuming it implements specs
# [15:17] <anne> e.g. fixing CSS hacks without fixing the underlying issues
# [15:17] <hsivonen> anne: getting from current IE to compliance would be hard
# [15:17] <hsivonen> anne: especially if the substring "MSIE" is retained in the UA string
# [15:18] <hsivonen> anne: (getting from current IE incrementally that is)
# [15:18] <hsivonen> since the pattern of authors writing one code path for IE and another for everything else is so prevalent
# [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
# [15:18] <anne> yeah; anyway, I'm not sure we should be in the business of designing a way out for them
# [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
# [15:21] <Philip> And break content that currently works in IE, where the 'everything else' path does not display the content?
# [15:22] <hsivonen> Philip: is it *Web* content today if there's no working "everything else" path?
# [15:23] <Philip> It's content, on the web, and lots of people may use it
# [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?
# [15:28] <MikeSmith> I mean, I can imagine there being some benefits for authors and content providers.
# [15:29] <Julian> end users do not care about this at all
# [15:29] <MikeSmith> OK
# [15:29] <MikeSmith> well, that ought to help us prioritize it better, then
# [15:30] <Julian> so why do we discuss microdata? After call, this can also be achieved by putting things into comments. Or invalid attributes.
# [15:30] * Joins: taf2 (taf2@38.99.201.242)
# [15:30] <MikeSmith> Julian: all true
# [15:31] <MikeSmith> But I'm not saying we should not discuss it.
# [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
# [15:31] <Philip> or why <foo xmlns:n="bar"><n:baz/></foo> and <div xmlns:n="bar"><n:baz/></div> are completely different
# [15:32] <Julian> why
# [15:33] <Julian> please ignore that
# [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
# [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))
# [15:33] <Philip> s//s/
# [15:33] <MikeSmith> Julian: and also considering that compared to the risks
# [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.
# [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)
# [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
# [15:37] <Julian> Mike, large vendors do that with and without namespaces (canvas)
# [15:37] <MikeSmith> Julian: yeah, that's one case, I'll admit
# [15:38] <MikeSmith> none of us are completely thrilled with the way canvas came about
# [15:38] <anne> including Apple
# [15:38] <MikeSmith> it would be a much better spec now if it had evolved differently
# [15:38] <Philip> MikeSmith: Why would any new syntax make it any easier for someone to unilaterally introduce de factor extensions?
# [15:38] <Philip> It seems like the current approach (make a name, use it) is already pretty simple
# [15:39] <Philip> s/factor/facto/
# [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
# [15:40] <anne> Julian, I think the tendency is there because the compat argument is not being taken seriously
# [15:40] <anne> and I don't think it's a sacrifice because this was never consistent to start with
# [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.
# [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
# [15:42] <MikeSmith> or that vendors of other UAs end needing to support that content to prevent it from "breaking" in their products
# [15:43] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [15:43] <anne> Julian, are you sure it was Opera 8?
# [15:43] <Julian> Mike, yes. This happens. No matter what the syntax is.
# [15:43] <Julian> Anne, re sacrifice: it's a violation of the DOM consistency principle, isn't it?
# [15:43] * Joins: gavin (gavin@99.226.207.11)
# [15:44] <Julian> Anne, yes. I tested with 8.54.
# [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
# [15:44] <Philip> anne: I think https://bugs.opera.com/browse/DSK-117765 is relevant
# [15:44] <pimpbot> Title: Login Required - Opera Bug Tracking System (at bugs.opera.com)
# [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.
# [15:45] <Philip> (just in case you're not aware of that already)
# [15:45] <Julian> Mike, how would it be easier?
# [15:46] <anne> Philip, I was looking at that
# [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
# [15:47] * jgraham notes that IE alone amongst browser vendors, is willing to break compat by introducing per0version modes
# [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
# [15:47] <anne> seems it was in 7.3 and up until 8.5 or 9
# [15:48] <Julian> 9.0 changed it
# [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
# [15:48] * Quits: myakura (myakura@118.6.236.217) (Quit: Leaving...)
# [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
# [15:49] <MikeSmith> Philip: yeah, they can do that, but there is a strong social pressure now against them doing so
# [15:49] <MikeSmith> this would remove some of that social pressure and give more freedom innovate
# [15:49] <MikeSmith> (scare quotes implied)
# [15:50] <MikeSmith> *freedom to innovate
# [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
# [15:50] <hsivonen> Philip: it indeed doesn't show that the everything else path can be the default if the UA string contains "MSIE"
# [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)
# [15:51] <MikeSmith> better
# [15:51] <MikeSmith> (for what my opinion is worth)
# [15:51] <MikeSmith> or com_apple_canvas
# [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
# [15:52] <MikeSmith> jgraham: despite its ugliness
# [15:52] <Philip> which doesn't seem a very novel thing to know
# [15:52] <hsivonen> I wonder if com_apple_canvas would have hindered canvas enough for SVG to have more mindshare than canvas today
# [15:52] <jgraham> MikeSmith: I think ugliness may be a virtue in this case
# [15:52] <MikeSmith> jgraham: yep
# [15:52] <MikeSmith> amen
# [15:52] <hsivonen> Philip: could be
# [15:52] <MikeSmith> I was just typing that
# [15:53] <hsivonen> Philip: note that I don't think Chrome Frame is a particularly good thing
# [15:53] <hsivonen> Philip: but it does make some stuff about engine mode less theoretical
# [15:53] <MikeSmith> jgraham: one way of looking at it is, the provenance should be obvious and the name as ugly as possible
# [15:54] <MikeSmith> jgraham: but again, as usual, wthdik
# [15:56] <hsivonen> MikeSmith: there's a way to work around the provenance issue by doing what Google did with the Rich Snippets vocabularies
# [15:56] <MikeSmith> hsivonen: what was that?
# [15:57] <hsivonen> MikeSmith: instead of having google.com in the names, they had data-vocabulary.org
# [15:57] <MikeSmith> ah
# [15:57] <Philip> Maybe we should require proprietary extensions to be written in AlTeRnAtInGcAsE, so the ugliness discourages their use
# [15:57] <MikeSmith> heh
# [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.
# [15:59] <MikeSmith> sounds like the way political-action committees in the US name themselves to appear grass-roots
# [16:00] <Philip> (And then you document the namespace URI in three different ways over the course of a couple of days)
# [16:00] <Philip> (and then you parse documents by ignoring the namespace entirely and just matching the localName)
# [16:01] <Philip> s/different ways/different spellings/
# [16:01] <MikeSmith> hsivonen: e.g., something like "People for a Freedom and a Better Tomorrow" (hypothetically)
# [16:01] <Dashiva> Only a freedom? Not freedoms?
# [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.
# [16:03] <mjs> canvas made us reluctant to extend the Web like that again without going to standards bodies early
# [16:04] <mjs> <com_apple_canvas> would have been worse than <canvas>
# [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
# [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
# [16:05] <Philip> How about: <div proprietary-semantics="com.apple.canvas">
# [16:05] <MikeSmith> mjs: your bad
# [16:05] <MikeSmith> mjs: please don't do it again
# [16:05] <Philip> then you could write <div proprietary-semantics="com.apple.canvas org.mozilla.canvas">
# [16:05] <Philip> while everyone has non-standard versions, like in CSS
# [16:06] <mjs> almost all recent stuff we've put into WebKit we either took to standards first, or as soon as possible
# [16:06] <Dashiva> <distributed-extension semantic="com.apple.canvas">
# [16:06] <Philip> and then you could write <canvas proprietary-semantics="com.apple.canvas org.mozilla.canvas"> during transition to the standard
# [16:06] <mjs> with CSS, it's a bit easier to make extensions without constraining future standards in the area
# [16:06] <Philip> and then the standard lets you just write <canvas>
# [16:06] <mjs> since you can specify multiple vendor-specific properties in a way that just doesn't work with elements
# [16:06] <mjs> although a vendor prefix system for *attributes* would work fine, IMO
# [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)
# [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
# [16:07] <Philip> Dashiva: That loses the fallback behaviour
# [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)
# [16:08] <mjs> (Gears, Native Client, O3D, other smaller examples that they sometimes propose to put in WebKit)
# [16:08] <Philip> Google seems to have a strange relationship with standards
# [16:08] <mjs> MikeSmith: I think it's valid for a feature to only have benefit for, say, authors and data mining content consumers
# [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
# [16:09] <MikeSmith> like, say, Web Forms 2 support
# [16:10] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [16:10] <MikeSmith> or un-fubarred support for drag and drop
# [16:11] * Joins: gavin (gavin@99.226.207.11)
# [16:11] * Philip wonders how commonly normal users use drag-and-drop
# [16:11] <Philip> (I pretty much never use it for anything ever)
# [16:11] * Joins: tlr_ (tlr@128.30.52.169)
# [16:11] <MikeSmith> Philip: every time they drag and drop something in a Web application
# [16:11] <Philip> (so I'm always surprised when I find a combination of applications where it actually does something pretty handy)
# [16:11] <hsivonen> Philip: do Flickr Organizr users count as "normal"?
# [16:12] <MikeSmith> Philip: or actually, every time they drag and drop something in a non-Web application
# [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
# [16:12] <Philip> hsivonen: Probably
# [16:13] * Quits: tlr (tlr@128.30.52.169) (Ping timeout)
# [16:13] * tlr_ is now known as tlr
# [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
# [16:14] <MikeSmith> Philip: you don't avoid dragging stuff around on your OS desktop for fear of it breaking
# [16:14] <MikeSmith> (not unless you use a Linux desktop, at least)
# [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
# [16:16] <mjs> MikeSmith: well, Microsoft's proposal articulated some potential benefits to authors and developers of nonstandard extensions
# [16:16] <mjs> MikeSmith: I would assume that if they saw an end-user benefit, they would cite that
# [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
# [16:16] <Philip> ("forget-to-release-mouse-button" is particularly easy on touchpads)
# [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
# [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 :-)
# [16:17] <MikeSmith> mjs: not having clear benefits for end users is a serious reason to be suspicious of any feature
# [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
# [16:18] <Philip> (and I never dragged-and-dropped much when I was using Windows, before switching to a Linux desktop :-p )
# [16:18] <mjs> hsivonen: I'll be much more interested in what Sam's goals are when/if he states a technical position
# [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
# [16:18] <MikeSmith> mjs: like, say, datagrid
# [16:19] <mjs> MikeSmith: that would be how I'd prioritize things, sure
# [16:20] <MikeSmith> mjs: I would hope it'd be the way that any UA vendor would prioritize things
# [16:20] <hsivonen> mjs: did Sam ask MS to submit a proposal? From where I'm observing, Sam mentioned "distributed extensibility" long before Microsoft.
# [16:20] <MikeSmith> mjs: but maybe that's just me
# [16:20] <mjs> hsivonen: he did way more than ask
# [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"
# [16:21] <pimpbot> Title: Sam Ruby: HTML5 and Distributed Extensibility (at intertwingly.net)
# [16:21] <hsivonen> mjs: then Sam's goals seem relevant to understanding the whole thing
# [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
# [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
# [16:23] <mjs> hsivonen: if he takes a technical position, then yes, he'd better justify it
# [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
# [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
# [16:25] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [16:25] * Joins: gavin (gavin@99.226.207.11)
# [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.
# [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
# [16:28] <hsivonen> Julian: initially, IIRC, MathPlayer-targeted content didn't work in Mozilla
# [16:28] <hsivonen> Julian: because initially IE+MathPlayer used text/html
# [16:28] <hsivonen> Julian: and Mozilla had per-spec MathML support only on the XML side
# [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
# [16:29] <hsivonen> long before HTML5 parsing adding MathML-in-text/html support to the standards world
# [16:29] <Julian> yes, that's a problem. Maybe we should ask MS to finally support XHTML in exchange for considering their ns proposal
# [16:30] <Julian> Henri, I know that.
# [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
# [16:30] <Philip> MikeSmith: I suggest asking them how high "widget frobnification" is on their list of priorities
# [16:30] <Julian> Sounds like a case where distributed extensibility worked out very well.
# [16:31] <Philip> MikeSmith: Has MS stated that?
# [16:31] <MikeSmith> Philip: I expect that would rank higher, if not just for the fact that it sounds slightly pornographic
# [16:31] <Philip> (They seem happy to implement draconian error handling in every other part of the browser and OS that uses XML)
# [16:31] <Philip> (as far as I'm aware)
# [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
# [16:31] <MikeSmith> Philip: it's easy enough to infer it, even for somebody as simple-minded as me
# [16:32] <Philip> MikeSmith: Ah, right, so you mean you're just making it up? :-)
# [16:32] <hsivonen> there's also a different kind of client extensibility
# [16:32] <MikeSmith> Philip: yeah, along with most everything else I say
# [16:33] <MikeSmith> Philip: I don't bother with "data" -- because as we have all learned "data" is suspect
# [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
# [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
# [16:33] <MikeSmith> we should all just rely on expert opinions (me being the main expert to consult)
# [16:34] <Philip> MikeSmith: Maybe you can be the expert in experts, so you can recommend experts to consult for various features
# [16:35] <Julian> Mike, unless I'm missing something they are doing draconian error handling for Atom.
# [16:35] <Philip> That saves you having to do the actual consulting work yourself
# [16:36] <hsivonen> Philip: it seems that MS's "decentralized extensibility" proposal would require rewiring, too
# [16:36] <Philip> hsivonen: It would, as would HTML5 support
# [16:36] <Philip> Once they've done that it seems like it should be relatively trivial to support XHTML
# [16:37] <Philip> though only because I have no idea of the implementation complexities involved
# [16:38] * hsivonen thinks the QA burden of supporting XHTML is non-trivial
# [16:38] <Philip> The PR benefit is non-trivial too
# [16:39] <Philip> given that it's a common complain against IE's standards compliance, for highly technical authors
# [16:39] <Philip> *complaint
# [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"
# [16:44] <Julian> Again, end users do not care about how something works.
# [16:45] <MikeSmith> right. they care instead about if/how something breaks
# [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?
# [16:47] <MikeSmith> Julian: see my earlier statement about where the burden of proof for that should be
# [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)
# [16:53] * Quits: gavin (gavin@99.226.207.11) (Ping timeout)
# [16:54] * Joins: gavin (gavin@99.226.207.11)
# [17:01] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
# [17:03] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
# [17:04] * Joins: Marcos (Marcos@213.236.208.22)
# [17:05] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
# [17:05] * Joins: Marcos (Marcos@213.236.208.22)
# [17:06] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
# [17:06] * Joins: Marcos (Marcos@213.236.208.22)
# [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
# [18:00] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [18:00] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
# [18:09] * Joins: hsivonen (hsivonen@130.233.41.50)
# [18:38] * Joins: shepazu (schepers@128.30.52.169)
# [19:06] * Joins: sryo (sryo@201.252.137.53)
# [19:07] * Quits: sryo (sryo@201.252.137.53) (Quit: Leaving.)
# [19:40] * Joins: sbublava (sbublava@77.117.212.34)
# [20:02] * gsnedders is now known as gsnedders|work
# [20:13] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
# [20:28] * Joins: gsnedders (gsnedders@83.252.227.235)
# [20:45] * Quits: gsnedders (gsnedders@83.252.227.235) (Quit: Adios intarwebs.)
# [21:18] * Joins: J_Voracek (irchon@173.74.232.166)
# [21:18] * Quits: J_Voracek (irchon@173.74.232.166) (Client exited)
# [21:18] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
# [21:22] * Joins: mjs (mjs@17.203.14.169)
# [21:57] * Quits: sbublava (sbublava@77.117.212.34) (Quit: sbublava)
# [22:00] * Joins: tlr (tlr@128.30.52.169)
# [22:01] * Quits: tlr (tlr@128.30.52.169) (Client exited)
# [22:03] * Quits: ChrisWilson (cwilso@131.107.0.101) (Ping timeout)
# [22:09] * Joins: ChrisWilson (cwilso@131.107.0.106)
# [22:49] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
# [23:16] * Joins: sephr (elijah@69.242.26.20)
# [23:17] * Joins: heycam (cam@63.245.220.224)
# [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
# [23:19] <sephr> the only relevant google result is someone asking the same question on IRC
# [23:31] * Joins: mjs_ (mjs@17.246.19.26)
# [23:33] * Quits: mjs (mjs@17.203.14.169) (Ping timeout)
# [23:33] * mjs_ is now known as mjs
# [23:45] * Quits: tH (Rob@82.4.89.172) (Quit: ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.0.1/2008072406])
# [23:47] * Quits: sephr (elijah@69.242.26.20) (Quit: Ex-Chat)
# [23:55] * Quits: plh (plh@128.30.52.28) (Quit: always accept cookies)
# Session Close: Tue Oct 06 00:00:00 2009

The end :)