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

Options:

# Session Start: Sat May 05 00:00:00 2007
# Session Ident: #html-wg
# [00:01] * Quits: zdenko (zdenko@84.255.203.169) (Ping timeout)
# [00:01] * h3h basks in the glory of Gmail (@Dashiva)
# [00:03] <Dashiva> Gmail doesn't prevent clutter in the archives :)
# [00:04] <h3h> yeh, the archives should use a variant of Gmail
# [00:06] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [00:06] * Joins: zdenko (zdenko@84.255.203.169)
# [00:08] * Quits: zdenko_ (zdenko@84.255.203.169) (Ping timeout)
# [00:11] <Zeros> h3h, I don't know, gmail doesn't have a spectacular record of not losing lots of mail
# [00:12] <h3h> I hope you're not talking about the thing a couple months ago that affected 75-100 users
# [00:12] <h3h> I've never lost a single email (that I noticed) with Gmail
# [00:15] <Dashiva> "This system has never had any undiscovered errors that we know of"
# [00:16] <schepers> ...
# [00:16] <schepers> tautologically
# [00:18] * Joins: Hixie (ianh@129.241.93.37)
# [00:30] <h3h> right, the point being that if Gmail lost "lots of mail" that would intersect with "mail I'd notice if it were lost" at some point
# [00:30] <h3h> but there's no evidence to substantiate the sensationalist claim and we all go merrily along with our days
# [00:32] <mjs> woo hoo, an extra bonus FO on the last day
# [00:32] * Philip` has a copy of all his Gmail messages via POP3 anyway
# [00:33] <h3h> FO?
# [00:33] <Philip`> Formal Objection
# [00:33] <h3h> oh right
# [00:34] <hyatt> "I also quite support Dave Hyatt, for similar qualifications, but he appears too uncontroversial in manner to merit much hoopla here; you should make more unconsidered and wildly controversial statements Dave! :-)
# [00:34] <hyatt> "
# [00:34] <hyatt> ummm
# [00:34] <h3h> haha
# [00:34] <mjs> hehe
# [00:34] <hyatt> We should drop this whole HTML thing and rewrite everything in Python.
# [00:34] <hyatt> ummm
# [00:34] <schepers> Dave "Vanilla" Hyatt
# [00:34] * h3h is in
# [00:34] <xover> There you go. Much better.
# [00:34] <hyatt> We should make a new language called XHTMLFormsVGXULx24
# [00:35] <hyatt> and every tag has to start with the letter X.
# [00:35] <h3h> what is Gregory Rosmaita talking about with his objection to "proprietary..."
# [00:35] <Philip`> I think reformulating HTML in terms of JSON would be good
# [00:36] <Philip`> Actually, create a new 'portable profile' of JSON so it's a subset of Python as well as of JavaScript, then you get the best of both worlds
# [00:36] <schepers> clearly, the best approach is to host HTML as a subset of SVG
# [00:37] <hyatt> as long as everything starts with the letter X i'm ok
# [00:37] * hyatt actually thinks it would be cool to allow SVG inside HTML5 :)
# [00:37] <hyatt> without namespacing
# [00:37] <hyatt> just throw the tags in and go
# [00:37] <schepers> hyatt, I agree
# [00:38] <schepers> assuming you'd have all the APIs
# [00:38] <hyatt> yeah
# [00:38] <hyatt> there are some tag conflicts though
# [00:38] <hyatt> like <a>
# [00:38] <schepers> that's possible to address in CDF's CDI
# [00:38] <schepers> well, then we would default to HTML's <a>
# [00:39] <h3h> or just a <svg> ...svg tags </svg>
# [00:39] * schepers wouldn't mind removing the xlink ns dependency in SVG
# [00:40] <Dashiva> You weren't listening. hyatt says prefix x, so it would have to be xSVG
# [00:40] <h3h> sorry
# [00:40] <h3h> <xtremeSVG>
# [00:40] * schepers is now known as xschepers
# [00:40] <xschepers> I'm with hyatt
# [00:41] <h3h> or xyatt
# [00:41] <mjs> I think everything should start with H instead
# [00:41] <h3h> I like that...
# [00:41] * mjs is now known as hjs
# [00:41] <hjs> it's more compatible with the web
# [00:41] * xschepers is now known as hchepers
# [00:41] <hchepers> yeah, musn't break the web
# [00:41] <Philip`> hyatt: You're still no good at being unconsidered and wildly controversial - everyone's agreeing with your ideas :-(
# [00:42] <hyatt> yeah, sigh.
# [00:42] <Dashiva> It's a lose/lose situation
# [00:42] * hchepers is wondering how to pronounce his own name now :'(
# [00:42] <h3h> begin with a sneeze...
# [00:42] <hyatt> i think you should all give me 50 dollars each to edit the html spec
# [00:42] <Dashiva> I imagine it's some sort of Spanish h
# [00:42] <hchepers> ... without choking
# [00:42] <hyatt> is that better?
# [00:42] <hyatt> no wait.
# [00:42] <hyatt> 500 dollars.
# [00:43] <hyatt> a million?
# [00:43] <h3h> sold!
# [00:43] <hyatt> sigh.
# [00:43] * xover writes a check...
# [00:43] <Dashiva> 500 dollars each would be about 200k
# [00:43] <Dashiva> At current wG size
# [00:43] <hchepers> shouldn't that be "hover"?
# [00:43] <xover> I'm the contrarian.
# [00:44] <hchepers> luddite!
# [00:44] <Dashiva> I hope someone is keeping note, so we can have "HTMLWG, the Musical" in ten years
# [00:44] <Dashiva> *notes
# [00:44] <Philip`> We've got the IRC logs
# [00:44] <hchepers> hyatt, do the work for no cost up front, but ask for a commission of 1c for each use of the language
# [00:44] <Dashiva> Are they on stable storage, though?
# [00:45] <xover> Maybe they should be datespaced?
# [00:45] <Philip`> Some of that $400,000,000 can go towards the editors spending a few years reading through the past decade of conversation and summarising into a nice book
# [00:45] <h3h> they should be in XHTML 2.0 to ensure future compatibility
# [00:45] <Dashiva> "If I had edited it", by Dave Hyatt
# [00:46] * Joins: xover_ (xover@193.157.66.5)
# [00:46] <Philip`> Dashiva: They'll be stored safely in Google's cache somewhere, so we could get someone to dredge them out again
# [00:46] * Quits: xover_ (xover@193.157.66.5) (Quit: Leaving)
# [00:46] * hchepers is now known as schepers
# [00:50] * Joins: DanC_lap (connolly@128.30.52.30)
# [00:51] <DanC_lap> so we're up to 4 formal objections now. just 2 arguments, though, and only one of them proposes an alternative
# [00:52] <schepers> shouldn't that be lap_DanC?
# [00:52] <DanC_lap> badump-bump... phshshs
# [00:52] <hjs> heh
# [00:52] * hjs is now known as mjs
# [00:52] <Dashiva> But a FO will not directly impact the work until there's a move towards CR status? I'm a bit unclear on that
# [00:52] <schepers> thank you ladies and gentlemen, don't forget to tip your waitress
# [00:53] <Philip`> Is that like tipping cows?
# [00:53] <DanC_lap> a formal objection means we don't have consensus; it means the chairs have to think hard. it's much nicer to just say "any objections? hearing none, so ordered."
# [00:53] <schepers> yes... I heard you stingy europeans don't even tip your cows
# [00:54] <Dashiva> Yeah, but we don't have to drop everything until they're resolved, just you?
# [00:54] <schepers> (to be fair, your cows are paid a living wage)
# [00:54] <Philip`> (http://en.wikipedia.org/wiki/Cow_tipping - I do like that photo)
# [00:54] <mjs> we have a total of 100 votes
# [00:54] <DanC_lap> if the chairs decide that the question cairres, then indeed, the formal objections are put aside until we request CR
# [00:54] <mjs> with 4 objections citing 2 argumentson the first question
# [00:55] <DanC_lap> it seems unlike terje to formally object without proposing an alternative
# [00:56] <mjs> terje did propose potential remedies for his objection
# [00:56] <mjs> on the mailing list
# [00:56] <Dashiva> They weren't remedies as such, I'd say. More like rejecting the idea of adopting HTML5.
# [00:56] <DanC_lap> really? all I saw was "I hope some alternative is discovered"
# [00:56] <DanC_lap> (paraphrasing)
# [00:57] <DanC_lap> "I cannot currently see what measure would achieve this, but would be
# [00:57] <DanC_lap> happy see such measures identified. "
# [00:57] <DanC_lap> (that's a literal quote)
# [00:57] <hsivonen> I am saddened to see that SGML is dragged into this
# [00:58] <mjs> ok, true, for one of his demands for remedy he did not cite any example of an alternative that would satisfy him
# [00:58] <DanC_lap> in the HTML5 spec, SGML is called "tree construction". I'm not all that invested in the particular acronym.
# [00:59] <schepers> he didn't shut the door either, and seems open to suggestions
# [00:59] <hsivonen> I mean all this time since 1993 (?) SGML has been in the specs somehow while being ignored by browsers. what more reality do we need to show that SGML isn't the real thing for HTML?
# [01:00] <schepers> I think it's a pretty temperate email
# [01:00] <DanC_lap> the time for suggestions was about a month ago. one could argue that I put the question too soon. (some have argued that, in fact).
# [01:00] <mjs> his proposed remedies were: unknown mechanism to prevent threat of resignation by editors from having an effect on the group (nature of remedy unstated); rejection of HTML5 as the baseline and adoption of HTML 4.01 as the baseline instead; a technical solution to flagging HTML5 as non-SGML to SGML parsers; and a loyalty oath from Ian Hickson
# [01:00] <schepers> (signed in blood)
# [01:00] * DanC_lap noodles some more on his "we are the working group" rant.
# [01:01] <mjs> I think 1 is undefined and therefore not concrete, 2 is unacceptable, 4 is in bad taste, and 3 is a separable technical issue which should not otherwise block progress
# [01:01] <schepers> put it to the tune of We Are the World, and you could get it on VH1
# [01:01] <Philip`> (Since at least IE wants some way to identify HTML5, couldn't SGML-based tools easily do some ad-hoc detection of that before passing it to either their SGML parser or their HTML5 parser?)
# [01:01] <DanC_lap> I'm really depressed at the number of "I'd like one <burger /> tag, please" messages. They take many forms... e.g. "we should make the spec friendly to authors" etc. I'd be more sympathetic if such messages came with something like "here's an outline" or "here's a sample chapter."
# [01:02] * DanC_lap goes back to counting the replies to the tasks survey
# [01:02] <hyatt> SGML = irrelevant to HTML imo
# [01:02] <mjs> someone did volunteer to help write an authoring guide based on the spec
# [01:03] <hyatt> HTML has long since left SGML behind
# [01:03] <mjs> I thought that was the most productive thing done by anyone who wanted something more author-friendly
# [01:03] <hsivonen> as far as use cases go, I'd love to see evidence of actual use of SGML tools by anything that touches HTML except four validators
# [01:03] <hsivonen> and why those users couldn't move to HTML5 parsing libraries
# [01:03] <schepers> the group was only recently chartered... I'd be surprised if people had time to react yet (except the WHATWG, which came in ready)
# [01:04] <mjs> I'd like to see evidence of SGML tools that can choose to fall back to HTML5 based on an FPI, but could not do so based on the doctype declaration being <!DOCTYPE html>
# [01:04] <mjs> but that seems like a specific technical point to be discussed which is only marginally related to starting specs
# [01:06] <DanC_lap> the group was chartered 7 March, and the charter discussions go back at least a year (though they only hit the public last November when timbl wrote his "reinventing HTML" blog post)
# [01:06] <DanC_lap> this period where we have to spec to work from is paaaaainful, for me at least. I can't wait to get past it. literally.
# [01:06] <DanC_lap> s/to spec/no spec/
# [01:07] <Philip`> You could always join the WHATWG ;-)
# [01:07] <hsivonen> http://www.intertwingly.net/blog/2007/05/02/Different-Drummer
# [01:07] <hsivonen> Sam's blog post is a good reading item to objectors
# [01:07] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [01:08] <hsivonen> Silverlight and Flash won't stop while we discuss this in a committee
# [01:11] <schepers> you know, the SVG WG felt the same way when trying to move to CR, and yet mjs and Hixie were active in their objections there
# [01:12] <schepers> and SVG is much more comparable to those techs than HTML is
# [01:12] <schepers> not that that's why I've put up objections
# [01:12] * Joins: gavin_ (gavin@74.103.208.221)
# [01:13] <mjs> schepers: I think objecting on a specific technical issue and asking for it to be addressed is quite different from requesting that work not start pending further discussion
# [01:14] <DanC_lap> Sam's blog post sure has a good hook to get me started reading, but... umm... I don't see what point it's trying to make.
# [01:14] <DanC_lap> is he saying "let's all play nice"?
# [01:14] <schepers> nobody said work shouldn't start... some of us said it shouldn't start from the WHATWG work
# [01:14] <DanC_lap> so what should we start from? and who's going to do the starting?
# [01:15] <schepers> I think that's been decided, hasn't it?
# [01:15] <mjs> "don't start from X" is equivalent to "don't start work" unless you propose an alternative starting point and find people willing to do the work to start from there
# [01:16] <schepers> HTML4.01 is the obvious answer
# [01:16] * Joins: sbuluf (wenma@200.49.140.136)
# [01:16] <schepers> but this is not my point
# [01:17] <mjs> HTML 4.01 doesn't seem to have a critical mass of supporters willing to edit and add all the needed changes
# [01:17] <schepers> I actually agree with hsivonen that W3C needs to respond to things based on market need and proprietary threats
# [01:17] <DanC_lap> HTML4.01 is ... well, it's a coherent answer to "what shall we start with?" but I haven't seen anybody say "I'm willing to do editing work, starting from HTML 4.01". and I've seen quite a bit of coherent argument that says the HTMl 4.01 text doesn't serve the needs of implementors well.
# [01:18] <schepers> hey, I didn't raise a formal objection, I'm playing nice here
# [01:18] <schepers> in fact, once my concerns were addressed, I even voted for starting with WHATWG's work
# [01:19] <hsivonen> DanC_lap: I think Sam is being less explicit on purpose but the way I read his juxtaposition of the dysfuctionality of the HTML WG and Silverlight is that failure to get stuff done in the HTML land opens up avenues to proprietary technologies.
# [01:19] <hsivonen> DanC_lap: in addition, the link to the RSS roadmap is an interesting tea leaf. we all know what happened with the RSS roadmap
# [01:19] <mjs> schepers: the main contrast I wanted to draw is that I believe my objections to the SVG specification were intended to improve it and in many cases did significantly lead to improve it to spec
# [01:19] <DanC_lap> ok, schepers. I was reponding to "some of us said it shouldn't start from the WHATWG work"
# [01:20] <hsivonen> DanC_lap: surely we don't want that to happen to HTML
# [01:20] <mjs> er
# [01:20] <mjs> "improvements to the spec"
# [01:20] <DanC_lap> we do? umm... I missed a clue. what happened with the RSS roadmap?
# [01:21] <hsivonen> DanC_lap: Atom happened, because of the unwillingless to evolve and fix RSS
# [01:21] <schepers> DanC_lap: and I was responding to mjs' claim that we were suggesting stopping work
# [01:21] <mjs> schepers: since you haven't raised an objection, I don't think you're suggesting stopping work
# [01:22] <hsivonen> DanC_lap: the way I see it, those who say that after all these years the only thing we should do is clean up HTML 4.01 a bit are arguing for the fate of RSS
# [01:22] <Zeros> I haven't heard anyone say that
# [01:22] <Zeros> It was said that we should start with HTML4, clean it up and then build on it instead of starting with WHATWG's HTML. Who has honestly said to clean up HTML4 and leave it?
# [01:23] <hsivonen> Zeros: well, making an HTML 4.1 first essentially would put HTML5 in the freezer for years, so the net effect would be the same
# [01:23] <Zeros> Silverlight isn't a market threat or related to html either. MS is positioning itself to take on flash.
# [01:23] <mjs> some people did say that they think few additions to HTML 4.01 are warranted
# [01:24] <mjs> Flash and Silverlight are both long-term market threats to interoperability on the web
# [01:24] <hsivonen> of course, Sam can probably give a better explanation of his post
# [01:24] <Zeros> Flash isn't a problem with interoperability, it's the essence of it mjs
# [01:24] <Zeros> Flash works *everywhere*, just like it's supposed to
# [01:24] <Zeros> CSS+HTML+JS is the interoperability failure
# [01:24] <hsivonen> Zeros: except x86_64
# [01:24] <mjs> single implementation is not the same thing as interoperability
# [01:25] <DanC_lap> I'll be OK if we don't add much in the way of features beyond HTML 4.01. For the current project, my goal is just interop on basic stuff like parsing. anything else is gravy.
# [01:25] <schepers> I'm with mjs here: those proprietary formats are a threat to the openness of the Web
# [01:25] <Zeros> hsivonen, And CSS2 probably doesn't work on my commodore 64. I haven't seen that many x86_64 machines around
# [01:25] <mjs> almost all of Apple's currently shipping machines are x86_64
# [01:25] <Zeros> Quicktime doesn't work on Vista, does that mean that Quicktime isn't interoperable?
# [01:25] <hsivonen> Zeros: right.
# [01:26] <mjs> (although generally running in x86 compatibility mode)
# [01:26] <Zeros> mjs, Flash works on intel OS X machines fine
# [01:26] <schepers> Zeros: QT isn't a W3C tech
# [01:26] <hsivonen> Zeros: so an approximation of everywhere is ok
# [01:26] <mjs> Zeros: QuickTime isn't, MPEG-4 in principle could be (though hsivonen would debate whether it is in practice)
# [01:26] <Zeros> schepers, neither is Flash
# [01:26] <schepers> Zeros: not sure what your point is?
# [01:27] <schepers> to me, the issue is open formats vs. proprietary/closed ones
# [01:27] <mjs> do you think web pages being replaced to a large extent by Flash or Silverlight would be good?
# [01:27] <Zeros> of course not
# [01:27] <schepers> mjs: yes, I do
# [01:27] <schepers> no, wait..
# [01:27] <schepers> I'm so confused!!!!
# [01:27] <DanC_lap> flash and silverlight are a 2-edged sword. (1) they relieve the pressure to make HTML all-singing-all-dancing, but (2) they tempt people to use proprietary formats for perfectly ordinary "choose which page you want to look at next" sorts of stuff.
# [01:28] <Zeros> mjs, I think the browser vendors getting their heads together, stop being so arrogant, stopping playing games and implementing the spec to the letter would be the solution
# [01:28] <Zeros> but that won't happen
# [01:28] * Joins: asbjornu (asbjorn@84.48.116.134)
# [01:28] <Zeros> Flash is viable because it works exactly the same everywhere. It's consistent.
# [01:28] <schepers> Zeros: I don't think that's fair. I think that's what they are trying to do
# [01:28] <Zeros> neither CSS or the DOM or the JS apis are consistent
# [01:29] <mjs> well, the vendor of Silverlight hasn't really played ball on making CSS or DOM consistent with other browser vendors
# [01:29] <Zeros> schepers, Not quite. Even yesterday mjs was expressing statements like "we don't agree with the spec so we won't add that feature"
# [01:29] <mjs> but they claim at least that they intend to play ball
# [01:29] <DanC_lap> Zeros: this is engineering. pick 2 of three: (1) browser vendors get together (2) stop being arrogant, (3) implement to the letter. I know which 2 I'll pick. ;-)
# [01:29] <Zeros> That is why HTML is not consistent, because vendors pick and choose
# [01:29] <schepers> mjs: the IE team is not the same as the SilverLight team
# [01:29] <mjs> schepers: that's why I said "vendor" not "developers"
# [01:30] <Zeros> DanC_lap, hah
# [01:30] <Zeros> mjs, Yes, but neither have you
# [01:30] <Zeros> or rather your vendor
# [01:30] <schepers> but they are actually completely different divisions, with different goals
# [01:30] <mjs> Zeros: really? Safari has probably the best conformance to W3C specifications of any browser
# [01:30] <Zeros> mjs, hah. Far from it
# [01:31] <schepers> even opera?
# [01:31] <mjs> Zeros: and matches Firefox and Opera better than IE matches any other browser
# [01:31] <DanC_lap> saying "we don't agree with the _current_draft_spec_that_we're_here_to_discuss_, so we won't implement it" is miles away from "we don't agree with the ratified-by-an-open-process-that-we-ignored spec, so we're not implementing"
# [01:31] <mjs> Opera definitely has conformance bugs that neither Safari nor Firefox have
# [01:31] <mjs> furthermore, Safari has been constantly fixing DOM and CSS bugs
# [01:32] <schepers> DanC_lap has a good point... this is early in the process
# [01:32] <mjs> IE has not fixed a DOM conformance bug in many years
# [01:32] <Philip`> I'm just happy that I managed to write a fairly nontrivial web page using uncommon technologies, and only tested in Opera and Firefox, and then it actually worked very nearly correctly in Safari - interoperability isn't impossible :-)
# [01:32] <Zeros> mjs, yes
# [01:33] <mjs> Zeros: so what more do you expect besides a high degree of conformance and constant improvement? if you call that uncooperative then I'm not sure how to satisfy you
# [01:33] <schepers> mjs: I suggest giving him a pony
# [01:33] <schepers> and me too
# [01:33] <Zeros> mjs, does Safari implement @page yet? how about :lang() or maybe the CSS print properties?
# [01:33] <schepers> I also want a pony
# [01:34] <Zeros> mjs, Opera does. "Safari has probably the best conformance to W3C specifications of any browser" is completely false
# [01:34] <mjs> Zeros: does Opera implement the conforming CSS 2.1 rules for <body> in HTML and XHTML?
# [01:34] <hsivonen> the pony is called prince. it runs as a separate process
# [01:34] <mjs> Zeros: does Opera support multiple backgrounds?
# [01:35] <Zeros> mjs, multiple background is part of CSS3 which hasn't been finalized yet
# [01:35] <mjs> I'm sure we could both come up with laundry lists
# [01:35] <Zeros> Opera supports more HTML5 than Safari does, if you want bring that kind of non-sense in
# [01:35] <Dashiva> How about we say safari has quantity, opera has quality? :)
# [01:35] <Zeros> http://www.webdevout.net/browser-support-css?IE6=on&IE7=on&FX2=on&OP9=on&SF2=on&uas=CUSTOM
# [01:36] <schepers> they are both good browsers, and they are both actively working on improvement and conformance
# [01:36] <Zeros> mjs, lets talk about standards that have been around for years, ones that are finalized
# [01:36] <Zeros> CSS2?
# [01:36] * schepers goes to dinner
# [01:36] <Dashiva> Let's not quarrel over things that matter little
# [01:36] <mjs> CSS2 is clearly never going to be implemented by anyone
# [01:36] <mjs> (as opposed to CSS 2.1)
# [01:36] <Zeros> well 2.1
# [01:36] <mjs> so it's not relevant
# [01:37] <Zeros> mjs, Webkit doesn't support 2.1 either
# [01:37] <mjs> CSS 2.1 is currently a Working Draft, just like the CSS3 Backgrounds Module
# [01:37] <Zeros> Right
# [01:37] <mjs> it's true that we don't have 100% conformance to CSS 2.1, but I don't believe that any implementation does currently
# [01:37] <Zeros> others have better conformance
# [01:37] <Zeros> Either way, that wasn't me point
# [01:38] <Zeros> My point is that HTML+CSS+JS is a failure because of the same reason you just illustrated
# [01:38] <Zeros> "mjs Zeros: does Opera support multiple backgrounds?"
# [01:38] <Zeros> Flash works, they implement the entire spec everytime.
# [01:38] <mjs> Zeros: you said "Yes, but neither have you", implying that Safari has not cooperated with other browsers on better standards compliance
# [01:38] <DanC_lap> by the way, mjs, there's a risk to responding to objections at this point. if the objections (or discussion of them) bring up arguments that weren't made during the discussion before I put the question, that argues for re-opening the discussion rather than carrying the question.
# [01:38] <Zeros> Browsers pick and choose, they jump ahead 2 versions and implement whatever they want
# [01:38] <mjs> Flash doesn't have a spec to implement, or a committee to answer to
# [01:39] <DanC_lap> the most useful thing to say in response to an objection is to point out where, in the archive, somebody can find discussion of their arguments.
# [01:39] <schepers> mjs: that's the danger of proprietary format versus standards... speed to market
# [01:40] <Philip`> Does Flash work that easily when you have to worry about users having old versions? (like only being able to use Flash 7 video, because not enough people have 8)
# [01:40] <Zeros> mjs, The principal is there. Until browser vendors linearly implement features in a consistent way Flash is very viable solution
# [01:40] <h3h> DanC_lap: what would the proper forum be for discussion or invalidation of a formal objection?
# [01:40] <mjs> DanC_lap: I find it surprising that addressing an objection on the substance calls for more delay than ignoring it
# [01:40] <Zeros> When one vendor jumps ahead an entire revision and implements random feature X, and another implements Y and there's no consistency...
# [01:41] <Dashiva> Go CSS3 modularization... yay...
# [01:41] <Zeros> It's the same reason PDF is so much better for printing
# [01:41] <mjs> DanC_lap: how can the chairs decide if an FO has enough merit to make the question fail to carry without discussion?
# [01:41] <Zeros> No one consistently implemented CSS print properties
# [01:41] <mjs> DanC_lap: should I give my counter-argument to the chairs privately instead?
# [01:42] <mjs> Zeros: CSS3 print properties are cool and all but have marginal relation to why Flash is successful, since many browsers can't print plugin content at all, let alone alter its layout it while doing so
# [01:42] <DanC_lap> maybe I've learned from the wrong tutors, but my understanding is that the chair is supposed to see that all relevant arguments are discussed before the question is put; once the question is put, the discussion is supposed to be done. If new points come up that would cause people to reconsider, the discussion is supposed to get reopened.
# [01:42] <Zeros> mjs, reread my statements
# [01:42] <schepers> Zeros: I think your point is that we need a commitment to consistency of implementation across browsers, and I think maciej agrees with that
# [01:42] <Philip`> (Would it be within the HTML WG's scope to produce and maintain something like the Web Devout browser support tables, so authors can see which features they can safely rely on?)
# [01:42] <mjs> DanC_lap: it seems like people who intentionally wait til the last minute to bring up their objections could then delay decision indefinitely
# [01:43] <Zeros> mjs, that was in relation to PDF which browser can print fine
# [01:43] <DanC_lap> there is no way to "invalidate" a formal objection. it is every WG members right to object, should they choose to do so.
# [01:43] <h3h> DanC_lap: sorry, "debate the technical merits of"
# [01:43] <DanC_lap> indeed, the chair takes into consideration the fact that somebody *could* have made an argument sooner and chose not to.
# [01:44] <Zeros> schepers, Maybe. Just last night he was making comments about why they won't implement a feature the spec requires because they don't think it's necessary.
# [01:44] <mjs> It seems to me that the chairs need to decide whether to let a question carry notwithstanding objections, or to let it fail due to a minority of objectors
# [01:44] <h3h> it seems unbalanced and short-sighted to have form objections only considered by the chairs
# [01:44] <Zeros> I'm not picking on mjs though, it's the general attitude of the browser developers
# [01:44] <DanC_lap> h3h, if you can show that an argument was already made and rebutted, that's helpful at this point. but if you respond to an objector's argument directly, you're substantiating their request to re-open the discussion.
# [01:44] <mjs> Zeros: the general attitude of most browser developers is that we want our implementations to match each other and the spec
# [01:45] * Quits: Zoffix (Zoffix@99.244.41.243) (Ping timeout)
# [01:45] <h3h> so if the argument hadn't been made until the formal objection, then a new discussion must be opened?
# [01:45] <mjs> Zeros: ideally where all of the implementations and the spec can be changed depending on what is best in a particular instance
# [01:45] <DanC_lap> unbalanced, short-sighted, quite possibly. W3C process and our charter have many warts. think carefully about the cost of changing them at this point, though.
# [01:45] <Zeros> schepers, what will be different about HTML5? mjs "violently disagrees" with the network portion of HTML5. Does that mean Webkit won't have support?
# [01:45] <DanC_lap> must? no. only may. and only if the chair thinks it's in the interest of the chartered goals of the WG.
# [01:46] <mjs> Zeros: it means I will argue for it to be significantly changed or removed from the spec
# [01:46] <Zeros> mjs, and if it isn't?
# [01:46] <schepers> Zeros: I'm acting on the assumption (perhaps naive) that the vendors are coming to the process with good faith
# [01:46] <hyatt> Zeros: then we'll still do it
# [01:46] <Zeros> alright
# [01:46] <Zeros> :)
# [01:46] * h3h didn't understand this nuance of the W3C Process
# [01:46] <hyatt> Zeros: although we'll obviously prioritize things we love over things we hate when determining implementation order :)
# [01:46] <mjs> I wouldn't commit to whether we will do it or not, but if my objections are only ones of taste and not of technical substance, we probably would
# [01:47] <mjs> I think the current design does not sufficiently address security issues
# [01:47] <DanC_lap> "the chairs need to decide whether to let a question carry notwithstanding objections, or to let it fail due to a minority of objectors". indeed, once the response period closes, that's my task. (along with Chris W.)
# [01:47] <mjs> that's my main objection
# [01:47] <Zeros> hyatt, heh. One would hope you'd get to it eventually though...
# [01:47] <hyatt> security issues are enough for us to say "no we wouldn't implement it"
# [01:47] <h3h> I agree with mjs that this is a perfect setup for an objector to wait until the last moment to present an argument as a formal objection to force a decision and avoid any debate or technical validation by the members of the WG
# [01:47] <hyatt> if those issues existed and had not been resolved
# [01:47] <mjs> but I don't think you should interpret my personal objection at this very early stage to be a commitment about implementing something or not
# [01:47] <schepers> Zeros: they know which side their bread is buttered on, and to a degree market pressure will align them with other browsers
# [01:48] <Zeros> mjs, It wasn't that exactly, it was a comment about the general attitude of the developers
# [01:48] <mjs> DanC_lap: I thought you would prefer to hear substantial responses to objections on the merits, since it would inform your decision whether there might be enough substance there that it is worth delaying progress
# [01:48] <DanC_lap> there are lots of ways to try to game the system. this chair has seen most of them.
# [01:48] <Zeros> schepers, and to be inconsistent paves the road for proprietary technology that isn't.
# [01:48] <schepers> Zeros: hint... for MS IE, it's buttered on the top, for the rest it's buttered on the bottom, and the bread is falling
# [01:48] <mjs> DanC_lap: if you prefer not to hear the other side of the argument, I can make it somewhere that you won't see, but I'm not sure what forum would be appropriate
# [01:49] <Zeros> hyatt, I've heard many comments about why IE having it's own event model and DOM interfaces is a good thing. Even the box model, since it "makes more sense"
# [01:49] <h3h> mjs: indeed, agreed again and the same question I posed
# [01:49] <hyatt> Zeros: you can use ie's box model in webkit or mozilla if you want
# [01:49] <Zeros> My point is that once the spec is passed it doesn't matter what makes more sense or not, it needs to be implemented by everyone or no one.
# [01:49] <hyatt> css allows for both box models
# [01:49] <hyatt> it's called "box-sizing"
# [01:49] <schepers> Zeros: I agree
# [01:49] <hyatt> implemented in ffx as -moz-box-sizing
# [01:49] <hyatt> and in latest webkit as -webkit-box-sizing
# [01:50] <Zeros> hyatt, I know
# [01:50] <h3h> DanC_lap: with due respect, I don't feel comfortable resting binding decisions on any one or two people without prior discussion among the WG members
# [01:50] <DanC_lap> well, mjs, actually, no. once I put a question, I prefer not to see any further discussion. Sometimes it's worthwhile, but mostly only if I made a mistake, or if somebody's trying to game the system or something.
# [01:50] * schepers really does leave for dinner
# [01:50] <hyatt> Zeros: i don't think ie's box model makes more sense
# [01:50] <Philip`> Zeros: Or it needs to be updated/fixed so that it will be implementable by everyone
# [01:50] <hyatt> it's funny to me that content developers will write this:
# [01:50] <hyatt> <img border=2 width=100 height=100>
# [01:50] <mjs> DanC_lap: once someone objects, there's already further discussion that you are obliged to see
# [01:50] <hyatt> and expect width/height to describe the image
# [01:51] <hyatt> but when they write <img style="border:2px solid black; width:100px; height:100px">
# [01:51] <DanC_lap> h3h, you're darned right to not feel comfortable. I'm sure not comfortable. if you can get the objectors to withdraw, you'll take the decision out of my hands and I'll be eternally greatful.
# [01:51] <hyatt> suddenly they think the width/height should include the border
# [01:51] <Zeros> hyatt, Some do, I don't. My point is that browser vendors/developers shouldn't be making decisions about what make sense, they should be implementing the spec. If the spec is awful, then no one should implement it.
# [01:51] <hyatt> we did implement the spec in that case
# [01:51] <h3h> DanC_lap: understood. thanks for the clarification
# [01:51] <hyatt> as did everyone else
# [01:51] <hyatt> so not sure that the box model is a good example
# [01:51] <DanC_lap> no, mjs, if I've done my job well, I already know what objections are going to come when I put the question.
# [01:52] <Zeros> hyatt, It is since IE implemented what made sense to them, everyone else implemented what the spec said. And now the argument is "was IE really wrong? Their model made more sense!"
# [01:52] <Zeros> I've heard comments that were similar about the IE event model.
# [01:53] <mjs> DanC_lap: well I didn't know what objections were going to come in... so you can't possibly know my potential counter-arguments, whether or not I keep them to myself
# [01:53] <hyatt> Zeros: you have the history wrong
# [01:53] <hyatt> Zeros: IE implemented things that way before the spec really existed i believe
# [01:53] <hsivonen> DanC_lap: will the chairs consider the objections that did not have any comment text whatsoever as Formal Objections?
# [01:54] <DanC_lap> it's my job to draw out the arguments against *before* I put the question.
# [01:54] <Zeros> hyatt, I know, IE did it long before the whole thing existed, but they never changed it either
# [01:54] <hyatt> Zeros: i don't think they flouted a spec on purpose
# [01:54] <DanC_lap> I didn't do it all that well this time.
# [01:54] <hyatt> Zeros: sure they did
# [01:54] <hyatt> Zeros: you get the right box model in strict mode in IE
# [01:54] <Zeros> hyatt, sort of.
# [01:54] <Zeros> hyatt, And the event model?
# [01:54] * Joins: Zoffix (Zoffix@99.244.41.243)
# [01:54] <DanC_lap> no; the objections with no comments are nothing but paperwork.
# [01:54] <hyatt> well the event model got specified during their neglect period :)
# [01:54] <mjs> DanC_lap: well, Terje even had a non-"no" vote until the very last day of the survey, it's hard to see how it could have been predicted what he'd do
# [01:54] <hyatt> when they were leaving IE to rot :)
# [01:54] <Zeros> What about Firefox's missing inline-block for years hyatt?
# [01:55] <hyatt> Zeros: that had to do with technical issues in gecko
# [01:55] <hyatt> Zeros: they needed to rearchitect their code to be able to do shrink wrapping better
# [01:55] <Zeros> hyatt, like your issues with generated content on inline elements yes.
# [01:55] <DanC_lap> yes, well, the terje case is what makes a group this size such a challenge for formal decision-making
# [01:55] <hyatt> anyway technical difficulties can delay the implementation of something
# [01:55] <Zeros> hyatt, That's another aspect of the same problem. Browsers are very inconsistent.
# [01:55] <hyatt> but that should not be construed as the browser vendors "not wanting to do it"
# [01:55] <hsivonen> interesting that MS didn't vote
# [01:56] <h3h> interesting or disturbing
# [01:56] <DanC_lap> not yet, at least
# [01:56] <hyatt> heck i'm implementing @font-face right now mainly because tina's comments about it pissed me off enough to just go do it. lol
# [01:56] <Zeros> hah
# [01:56] * xover notes that DanC_lap asked for a non-Member to test the voting form right after it was put up...
# [01:57] <Dashiva> On any element, hyatt? :)
# [01:57] <Zeros> hyatt, Anyway, I'm not bashing vendors, or your work. I'm saying that Flash is viable because of the consistency, same with silverlight. browsers need to be tons more consistent both in JS/CSS and HTML support before they can compete.
# [01:57] <hyatt> i'm honoring the spec
# [01:57] <hyatt> even though i hate the spec
# [01:57] <hyatt> so there. :)
# [01:57] <Zeros> okay, hyatt wins :)
# [01:57] * DanC_lap tries to remember if xover and terje refer to the same person
# [01:58] * Dashiva poitns DanC_lap at /whois
# [01:58] * xover was about to say... :-)
# [01:58] <mjs> they do
# [01:58] * Quits: Zoffix (Zoffix@99.244.41.243) (Ping timeout)
# [01:59] <Zeros> hyatt, now we just need to get you guys to merge Tamarin in there to get KJS faster ;)
# [01:59] <DanC_lap> xover, did you see my "I'm monitoring the level of consensus" and "I suppose I'll put the question next week" messages? Did they make any sense a the time?
# [01:59] * hyatt rolls his eyes
# [01:59] <mjs> xover: can you think of less drastic remedies that might address your concerns?
# [02:00] <hyatt> yes, because JITing a bunch of javascript that often runs only once will be sooo much faster
# [02:00] <mjs> Zeros: has anyone benchmarked Tamarin on real-world JS yet?
# [02:00] <DanC_lap> I made a few attempts to say "I'm only interested in discussion of a few items" but I think my messages got lost in the noise.
# [02:00] * Joins: Zoffix (Zoffix@99.244.41.243)
# [02:00] <mjs> if it tests well, we'd consider it
# [02:00] <xover> DanC_lap: Not really. The... right. The firehose is impossible to swallow.
# [02:00] <mjs> so far, optimising KJS has proven more productive
# [02:00] <Zeros> mjs, It's the same engine running in Flash 9, it's quite fast
# [02:01] <jdandrea> Every time I go back to reading WA 1.0, I'm 24 threads behind. ;)
# [02:01] <DanC_lap> I tried to post rarely enought that I could expect WG members to read every message I sent.
# [02:01] <Zeros> JS? no. ActionScript yes. And in benchmarks it was as much as 10x faster than Flash8
# [02:01] <hyatt> and our JS engine in webkit is pretty much the speed king
# [02:01] <hyatt> when compared with other real browsers
# [02:01] <xover> mjs: I'm wonderig whether I have expressed myself poorly since you percieve the remedies as "drastic".
# [02:01] <mjs> Zeros: I don't know how I can relate Flash8 or Flash9 benchmarks to JS benchmarks
# [02:01] <hyatt> Zeros: people also often write "javascript" tests that don't really test the language
# [02:01] <mjs> xover: I do think that not adopting HTML5 as a starting point is a pretty drastic remedy when the question is whether to adopt it
# [02:01] <Zeros> mjs, the engine is an ECMAScript 3 compliant engine
# [02:01] <hyatt> Zeros: but often are really testing the DOM or bindings
# [02:01] <Zeros> mjs, it'll run JS just like AS
# [02:02] <hyatt> the 24fun benchmark is a funny example of this
# [02:02] <hyatt> it calls itself a "javascript" test
# [02:02] <mjs> Zeros: has anyone benchmarked the same code running in both a web page and Flash?
# [02:02] <hyatt> but it's basically a dhtml test
# [02:02] <Zeros> mjs, That doesn't work because you have too many variables
# [02:02] <Philip`> My only JS-intensive code spent pretty much its entire time in the browser's rendering code, which was nice since I could add optimisations that made the JS several times slower and more complex without it having any effect on overall performance
# [02:02] <mjs> Zeros: then how can I tell if it will be faster or not?
# [02:03] <DanC_lap> well, I'm an hour overdue for family time. hasta.
# [02:03] <mjs> Zeros: that's why I said we're waiting to see how it performs on JS as seen on the web
# [02:03] <xover> DanC_lap: fwiw, I'm sorry that your in the current position. I don't envy you.
# [02:03] <mjs> later DanC_lap
# [02:03] <Zeros> mjs, Alright, wait for Gecko to merge it.
# [02:04] <mjs> Zeros: we're going to try it even with command-line JS-only benchmarks as soon as feasible
# [02:04] <mjs> but in the meantime we'll keep optimizing our own engine
# [02:04] <Zeros> mjs, Some of it is obvious though. It uses native numeric types, and considering it supports all the features of ECMAScript 3 (which KJS does not), which lets it do native math and other things that JS will slow down on because of type conversion.
# [02:05] <mjs> Zeros: it uses native numeric types when you use the non-ECMAScript 3 feature of type annotation
# [02:05] <xover> mjs: Without in any way making an accusation; could I humbly suggest you make an assumption of good faith and pragmatic realism on the part of the author, and read my message again?
# [02:05] <mjs> Zeros: I'm not sure how that will help existing ECMAScript 3 code
# [02:06] <mjs> xover: I already read it with the best possible understanding I could give it - if you think I misunderstood something, it would be really helpful if you could clarify directly
# [02:06] <hsivonen> xover: I fail to see the pragmatic realism
# [02:06] <Zeros> mjs, Mozilla is heading that route with the next version of JS for Gecko
# [02:07] <Philip`> I'm guessing http://www.playercore.com/pub/Tamarin/Avmplus_vs._javascript.htm are some of the non-real-world benchmarks
# [02:07] <mjs> you said: 'This would ideally be to use the HTML 4.01 Recommendation as a starting point (the basis for review), with the “HTML5” submission relegated to “merely” the most useful and relevant external source (and quite probably ending up comprising the vast majority of the eventual text).'
# [02:07] <xover> Hmm. I must conclude I've failed to make myself understood, or I've failed to understand something.
# [02:07] <mjs> that seems to me to ask for HTML5 to not be adopted as the starting point, when the question is whether to adopt HTML5 as the starting point
# [02:07] <Philip`> (Doesn't seem to do too well with untyped JS code)
# [02:08] <Zeros> mjs, For long running code like Gmail or the Canvex demo I can imagine performance gains as well.
# [02:08] <mjs> given how much we beat spidermonkey on a lot of untyped JS code, it's not obvious that Tamarin would be a win
# [02:08] <Philip`> Canvex is almost all drawImage()
# [02:08] <Philip`> so if anyone can optimise that, I'd be happy :-)
# [02:08] <xover> mjs: I'm in agreement when you consider it free of context. But considered in light of your ultimate goal, does it still seem as drastic?
# [02:09] * jdandrea just gets to xover's FO - reading ...
# [02:09] <Zeros> Whatever it is Opera is lighting fast compared to Safari, and Safari is using Core Image IIRC
# [02:09] <mjs> xover: I believe it would impose many years of delay to get largely the same result, so yes, it does seem drastic to me
# [02:09] <mjs> Zeros: we don't use CoreImage for basic image blitting
# [02:09] <xover> Ok. Thank you for the clarification.
# [02:09] <Philip`> Firefox is apparently really slow at rendering on Macs
# [02:09] <Philip`> but FF2 and FF3 are faster than O9 on Windows
# [02:10] <Zeros> mjs, oh, then it's the render path actually in Safari that needs optimization
# [02:10] <Philip`> (just for this drawImage stuff)
# [02:10] <hyatt> Opera's HTML rendering is way slower than Safari on Mac
# [02:10] <Zeros> webkit rather
# [02:10] <hyatt> we've benchmarked that plenty
# [02:10] <mjs> Zeros: I'm happy to profile it what's slow on that one example
# [02:10] <Zeros> Opera in general is way slower on os x
# [02:10] <hyatt> yeah
# [02:10] <mjs> Zeros: we can probably fix it - I don't think it is indicative of a widely applicable performance difference
# [02:10] <Zeros> Safari loads faster, but falls over trying to scroll or render long pages
# [02:11] <Zeros> Gecko can handle pages that are significantly longer (like the entire php manual in a single file) better.
# [02:12] <Zeros> mjs, It was when I thought you were using Core Image
# [02:13] <hyatt> are these pages well-formed?
# [02:13] <hyatt> our long page problems usually stem from malformed pages being pathologically nested
# [02:13] <hyatt> gecko caps nesting at 200
# [02:13] <Hixie> xover: in order to satisfy your formal objection, you want me to promise not to stop being editor, whatever happens?
# [02:13] <hyatt> we don't cap nesting
# [02:14] <hyatt> i did a bunch of work very recently in this area
# [02:14] * Quits: Zoffix (Zoffix@99.244.41.243) (Ping timeout)
# [02:14] <hyatt> to improve webkit's long page perf
# [02:14] <hyatt> so things should be much better
# [02:14] <Zeros> oh, I'll look into it them
# [02:14] <Zeros> then*
# [02:14] <hyatt> i'd be curious though
# [02:14] <hyatt> in general large page perf problems interest me greatly
# [02:14] <Zeros> previously it would beachball for very long periods of time where Firefox wouldn't
# [02:14] <hyatt> yeah that sounds like malformation
# [02:15] <hyatt> with my recent changes pages that would hang every browser practically forever now load in a matter of seconds heh
# [02:15] <Zeros> nice
# [02:15] <Zeros> There's also a bug with finding fragment identifiers in the document in Webkit that would be nice to have fixed
# [02:16] <Zeros> Webkit loads the page incrementally and sometimes it'll load and jump down part of the way and stop, and then keep loading where the place it should have been is still farther down the page
# [02:16] <Zeros> refreshing fixes it
# [02:16] <hyatt> weird
# [02:16] <hyatt> sounds like layout may not be up to date before it jumps or something
# [02:17] <Zeros> possibly. It's not all the time, so I assume it's a function of how fast the network is
# [02:17] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [02:19] <xover> Hixie: Now I know I've failed to make myself understood, since you've apparently mistook what I thought was quite plain English to that degree.
# [02:19] <Hixie> i don't understand what your objection is
# [02:19] <Hixie> here's the problem i have:
# [02:19] <Hixie> i have 8 hours per day to do work
# [02:20] <Hixie> amongst other things, my employer requires me to work on the whatwg spec
# [02:20] <Hixie> working on the whatwg spec takes about 9 hours of work per day
# [02:21] <Hixie> working on a separate spec would take some comparable amount of time, assuming we want it to be finished in the next decade or so
# [02:21] <Hixie> i have to sleep for 8 hours a day
# [02:21] <hyatt> learn2notsleep
# [02:21] * Joins: Zoffix (Zoffix@99.244.41.243)
# [02:21] <Hixie> and i would like at least some personal time
# [02:21] <hyatt> learn2NotHaveALife
# [02:21] <Hixie> now, given the above, how can i work on the html wg spec if the html wg spec is not the whatwg spec?
# [02:21] <hyatt> you can have my daughter Hixie
# [02:22] <Hixie> dude
# [02:22] <hyatt> she'll cure you of that pesky desire to get sleep and/or have a life
# [02:22] <Hixie> a) i already have a girlfriend and b) she's WAY too young for me
# [02:22] * Hixie ducks
# [02:22] <hyatt> !!!
# [02:22] <Hixie> :-P
# [02:22] * xover is uncertain to what extent he should take DanC_lap request that this not be the topic of further (public) discussions...
# [02:22] <Dashiva> Political marriage to ensure peace among editor families
# [02:22] <Dashiva> I like where this is going
# [02:22] <hyatt> lol
# [02:23] <Hixie> dan asked that we not discuss this?
# [02:23] <Hixie> what/
# [02:23] <Hixie> ?
# [02:23] * Hixie confused
# [02:23] <xover> Well, he was responding to mjs and the context was alittle different.
# [02:23] <Hixie> ah well anyway, i would be curious to find out what you meant
# [02:23] <xover> Basically I think he was telling mjs that if he kept it shut it'd be easier for him to proceede in spite of my objection.
# [02:24] <Hixie> mjs: there is as much reason to believe that we'll define 100% of the error handling rules as there is to assume that we'll define 100% of the rules for handling non-erroneous content
# [02:24] * Quits: asbjornu (asbjorn@84.48.116.134) (Connection reset by peer)
# [02:24] <xover> You can consider one part of it to be an objection to form; the question should not have been put, the way it was, before the other question had been decided.
# [02:25] <Hixie> xover: well that's entirely between you and dan, my question is about what you meant when you said i should promise not to not be editor or whatever it was
# [02:25] <hyatt> Hixie: yeah that's a good way of putting it
# [02:25] <hyatt> no spec ever covers 100%
# [02:25] <hyatt> even the stuff that's valid
# [02:25] <mjs> Hixie: I'm trying to make a more limited claim - that the parser spec in principle can and likely will map every input stream to at most one conforming DOM
# [02:25] <Hixie> hyatt: yeah, it's like code
# [02:25] <Hixie> in a way in _is_ code, in fact
# [02:25] <hyatt> mjs: even there, i would not expect 100% interop
# [02:25] <Hixie> mjs: we can hope
# [02:25] * Joins: asbjornu (asbjorn@84.48.116.134)
# [02:25] <mjs> whether that's the correct error handling is an open question
# [02:26] <mjs> but obviously conformance requirements can fail to address a case, just as code can
# [02:26] <Hixie> right
# [02:26] <mjs> still, state machine models are more checkable through formal methods than grammar plus exception rules
# [02:26] <xover> Hixie: I meant that you've made some public statements that (intents aside) amount to holding the WG hostage to your (good, valuable, and very much appreciated) work as Editor. And I want you to stop doing that.
# [02:27] <hyatt> xover: i don't think Hixie has made any such statements.
# [02:27] <mjs> hyatt: there will likely be interop failures even if every case is defined, so maybe it's not relevant
# [02:27] <Hixie> xover: you misread my statements. I am not holding the WG hostage. I am volunteering to help, if the situation is such that I could physically help.
# [02:27] <mjs> but I think Chris W was applying the wrong mental model
# [02:27] <Hixie> xover: are you saying that i should volunteer to help even if i wouldn't have the time? I don't understand.
# [02:27] <mjs> assuming that you have a grammar and then a bunch of rules that say "if error foo happens, do bar"
# [02:29] <xover> Hixie: The WG has been asked to decide that you should be Editor (read the question on the ballot).
# [02:29] <xover> You say you can only be Editor if the HTML WG spec == the WHAT WG spec.
# [02:29] <xover> Thus, saying yes to you as Editor would require that you say yes to the WHAT WG spec.
# [02:29] <mjs> xover: I think if Hixie would decline appointment as Editor under condition X, that's no reason to refuse to consider him even if condition Y should hold
# [02:30] <mjs> (where X != Y)
# [02:30] <Hixie> xover: right
# [02:30] <Zeros> hyatt, I think I have a consistent test case for that, I'll submit a ticket tonight.
# [02:30] <Hixie> xover: so? why does that means that _I_ should promise to be editor no matter what?
# [02:30] <hsivonen> xover: how is that holding anyone hostage?
# [02:30] <hyatt> Zeros: awesome
# [02:31] <hyatt> Zeros: you can ping bdash on #webkit tonight, since he was interested in those bugs
# [02:31] <xover> Hixie: My message doesn't ask for that.
# [02:31] <Hixie> what did it ask of me then?
# [02:31] <Zeros> hyatt, cool, thanks.
# [02:31] <Hixie> "Ian Hickson must give a clear statement that he accepts the role of Editor in the WG, that is not contingent on how the WG chooses to produce its deliverables."
# [02:31] <Hixie> sounds very much like what I just said
# [02:31] <hyatt> i guess now is as good a time as any to say that i would also decline the editor position if the whatwg specs are not the starting point
# [02:32] <xover> That you either volunteer or not. If you feel you cannot until the WG decides how it will proceede then.. .don't.
# [02:32] <Hixie> xover: i have _always_ said that i only volunteer contingent on that.
# [02:32] <hyatt> i have no interest in starting from scratch when so much work has already been done
# [02:32] <Hixie> xover: where have a i said otherwise?
# [02:32] <xover> The it was inappropriate for Dan to put the question.
# [02:32] <Hixie> hyatt: shocking! you are holding us hostage!
# [02:32] <Zeros> At this point, if the WHATWG specs are not the starting point how many browser vendors plan to implement W3 HTML5 ? hyatt, anne?
# [02:33] <Hixie> xover: that's entirely between you and him; your objection, however, says that _I_ have to make a statement.
# [02:33] <Zeros> I have a feeling there'd be a vendor exodus
# [02:33] <Hixie> Zeros: i imagine the browser vendors would base their decision to implement on the quality of the spec, not on the immediate decisions of the group
# [02:33] <Hixie> i'd hope so, at least
# [02:34] <hyatt> i think that if whatwg is not used as the basis for the html5 specs
# [02:34] <Hixie> where "quality" includes things like whether it satisfies the proposed design principles
# [02:34] <hyatt> then this group would not be producing anything meaningful for years
# [02:34] <Hixie> that's almost certainly true, yes
# [02:34] <hyatt> and we can't wait that long to compete with silverlight/flash
# [02:34] <Hixie> but that's another problem altogether
# [02:34] <Zeros> Hixie, The WHATWG would most certainly finish sooner.
# [02:34] <Hixie> theoretically, the htmlwg might have something ready in 20 years or so as an "html6" or something
# [02:34] <Zeros> If W3 HTML5 would be better would then be moot unless they want to wait
# [02:34] <Hixie> at which point it might be useful
# [02:34] <xover> Hixie: You've said things like you don't plan to attempt to get consensus (which is very inappropriate for an Editor), and you argue in favor of using the WHAT WG submission based on the fact that you won't play if we don't.
# [02:35] <Zeros> Hixie, I suppose. Though how much of HTML5 is from XHTML2?
# [02:35] <Hixie> xover: yes, i have no interest in being editor if i couldn't physically do it, which i couldn't if it would require getting consensus between 350 people.
# [02:35] <Hixie> xover: would you rather i _didn't_ tell you under what conditions i'd be willing to volunteeer?
# [02:36] <Zeros> I'm not sure we really need consensus, though right now a big problem is the biases of the group members with influence
# [02:37] <xover> TimBL is the only benevolent dictator at the W3C, and even he is limited by Process. Getting Consensus is how this works.
# [02:38] <Zeros> I think a distributed consensus could work, but Hixie has already commented that that would be "a lot of work"
# [02:39] <Hixie> xover: you didn't answer my question
# [02:39] <Zeros> If we broke the group into parts each with a goal and a leader and let them argue it out a smaller subset, come to a conclusion and merged it.
# [02:39] <xover> Which one?
# [02:39] <Hixie> xover: would you rather i _didn't_ tell you under what conditions i'd be willing to volunteeer?
# [02:39] <hsivonen> xover: as a corollary, when there's no consensus, a consensus process doesn't work
# [02:39] <hsivonen> xover: http://www.intertwingly.net/blog/2007/05/02/Different-Drummer
# [02:39] <hyatt> design by committee = not a good way of doing things
# [02:39] <hyatt> you need someone to listen to the technical arguments and then make a call
# [02:40] <hyatt> a pure voting process doesn't work
# [02:40] <xover> I'd rather you didn't say the WG should use the WHAT WG spec as its basis because if it doesn't then it won't get you as an Editor.
# [02:40] <hyatt> democracy doesn't work
# [02:40] <Zeros> hyatt, That can produce gross bias. We could get <object> all over again
# [02:40] <hyatt> since that assumes everyone is operating on the same technical level
# [02:40] <hyatt> when frankly they aren't
# [02:40] <xover> hsivonen: Seen it. I might cite it right back at you.
# [02:41] <Hixie> xover: so that's a "yes" then?
# [02:41] <Hixie> xover: you'd rather i had a secret agenda?
# [02:41] <Zeros> hyatt, At this point I'm content though. I wanted more than one editor for a more diverse view and I got it. :)
# [02:41] <hyatt> xover: btw you may as well object to me too
# [02:42] <hyatt> xover: since i will also only edit html5 if the whatwg specs are the starting point
# [02:42] <xover> hyatt: So I understand. Aren't you pleased you're finally controversial? :-)
# [02:42] <hyatt> my motivation is a bit different from hixie's though
# [02:42] <hyatt> it's not a lack of time issue for me
# [02:42] <hyatt> it's more that if this group doesn't start with a body of work that it will not be relevant
# [02:42] <hyatt> you can't start from scratch
# [02:43] <hyatt> otherwise we'll all be writing XAML or flex in 5 years
# [02:43] <xover> hyatt: You haven't been "throwing your weight around" (for lack of a better way to put it). There was a reason I didn't object to you there.
# [02:43] <hyatt> HTML needs to evolve quickly to meet the threat of these proprietary stacks head-on
# [02:43] <hyatt> so does CSS
# [02:43] <Zeros> Hopefully we can get this conversation bundled in nice email for to the list.
# [02:43] <Zeros> in a*
# [02:44] <Zeros> We're going no where fast until we get this out of the way.
# [02:44] * Zeros goes to dinner
# [02:44] <hyatt> note there are entire sections of wf2 and web apps that i think should be redone
# [02:44] <hyatt> but that doesn't mean they should not be used as a starting point
# [02:44] <hyatt> you need some kind of body of work to start with
# [02:45] <xover> hyatt: I seriously think I must not have made myself clear on that point.
# [02:45] <Dashiva> hyatt: Maybe you should make a post about that, in case people have missed it before?
# [02:45] <Hixie> xover: btw, note that dan has repeatedly said that the whatwg model of "editor listens, makes proposal, iterate" is exactly the model he expects to use for this group, with exceptions only made for cases where there are big objections.
# [02:45] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [02:45] <xover> Sounds like a good sound model to me.
# [02:46] <hyatt> dinner time
# [02:46] <hyatt> later
# [02:46] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [02:51] * Quits: MrNaz (Naz@203.214.95.166) (Ping timeout)
# [02:53] <mjs> xover: Hixie was nominated several times, and said his willingness to serve depended on the direction of the group
# [02:54] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [02:54] <mjs> xover: while it's true that the answer to question 3 may be contingent to question 1, I think serializing the voting would only have added delay, and I don't think a statement from Hixie now will solve the problem
# [02:54] <mjs> especially if that statement is untrue
# [02:54] * Quits: sbuluf (wenma@200.49.140.136) (Ping timeout)
# [02:56] * Hixie replies on the list
# [02:56] * xover awaits it with interest...
# [02:58] * Joins: sbuluf (wudbjjo@200.49.140.36)
# [03:02] * Joins: DanC_lap (connolly@128.30.52.30)
# [03:14] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [03:16] * jdandrea (and family) exeunt - bbl
# [03:17] * Joins: polin8 (polin8@24.184.204.6)
# [03:20] * xover responds to Hixie...
# [03:22] <xover> Thank you Ian! That was very graciously handled, and seems to adress all my concerns. Kudos!
# [03:24] <xover> DanC_lap: Given the questionnaire is still open and my objection on the Editor question is resolved, should I just change the vote on the form?
# [03:24] <mjs> xover++
# [03:35] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [03:35] <xover> Ok, on the assumption that changing that entry on the form is the least painfull way forward I'm going to go ahead and do that while the vote is still open (and before I go to bed).
# [03:41] * Joins: DanC_lap (connolly@128.30.52.30)
# [03:54] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:55] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [03:57] * Joins: myakura (myakura@125.194.247.196)
# [04:00] * Joins: DanC_lap (connolly@128.30.52.30)
# [04:18] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [04:18] * Joins: DanC_lap (connolly@128.30.52.30)
# [04:20] * Joins: dbaron (dbaron@71.198.189.81)
# [04:42] * Quits: AGraf (Ashe@213.47.199.86) (Connection reset by peer)
# [04:55] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [05:20] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [05:25] * Joins: gavin_ (gavin@74.103.208.221)
# [05:36] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [05:36] * Joins: DanC_lap (connolly@128.30.52.30)
# [05:41] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: さようなら)
# [05:43] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: This computer has gone to sleep)
# [05:47] <gavin> Shunsuke
# [05:47] <gavin> 's quit message beeps my terminal every time I switch to this channel :)
# [05:51] * Parts: Zoffix (Zoffix@99.244.41.243) (K-Lined)
# [06:27] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [06:28] * Joins: DanC_lap (connolly@128.30.52.30)
# [06:28] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [06:28] * Joins: DanC_lap (connolly@128.30.52.30)
# [06:28] * Quits: asbjornu (asbjorn@84.48.116.134) (Ping timeout)
# [06:36] * Joins: hyatt (hyatt@24.6.91.161)
# [07:06] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [07:22] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [07:25] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
# [07:26] * Joins: hyatt (hyatt@24.6.91.161)
# [07:27] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [07:33] * Joins: gavin_ (gavin@74.103.208.221)
# [07:57] * Joins: MrNaz (Naz@203.214.95.166)
# [08:21] * Joins: dbaron (dbaron@71.198.189.81)
# [08:26] * Quits: heycam (cam@203.214.12.71) (Quit: bye)
# [08:30] * Joins: Zoffix (Zoffix@99.244.41.243)
# [09:32] * Quits: MrNaz (Naz@203.214.95.166) (Ping timeout)
# [09:35] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [09:40] * Joins: gavin_ (gavin@74.103.208.221)
# [09:44] * Joins: ROBOd (robod@86.34.246.154)
# [10:09] * Quits: loic (loic@90.29.237.247) (Ping timeout)
# [10:16] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [10:24] * Joins: loic (loic@90.29.119.252)
# [10:43] * Quits: schepers (schepers@69.134.24.226) (Quit: Free at last!)
# [10:44] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [11:28] * Joins: mw22 (chatzilla@213.51.191.252)
# [11:40] <gsnedders> some people are managing to state things very well
# [11:42] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [11:48] * Joins: gavin_ (gavin@74.103.208.221)
# [12:01] <Lachy> gsnedders, which people?
# [12:02] <gsnedders> Lachy: David, Maciej, and Jonas
# [12:02] <gsnedders> but others also
# [12:03] <gsnedders> (that's not to say they weren't stating stuff well before — just very well now)
# [12:15] * Joins: ROBOd (robod@86.34.246.154)
# [12:15] * Joins: molily (molily@85.212.25.62)
# [12:15] <molily> hello
# [12:17] <Lachy> hi
# [12:31] * Joins: hasather (hasather@81.235.209.174)
# [12:34] <anne> Hhmm, John missed the context of the <foo:bar/> question it seems
# [12:34] <anne> oh well
# [12:35] * anne goes to read some e-mail
# [12:50] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [12:51] * Quits: sbuluf (wudbjjo@200.49.140.36) (Ping timeout)
# [12:53] <anne> quite some misunderstanding on that list :(
# [12:58] <anne> ooh, formal objections
# [13:00] * Joins: tH (r@87.102.20.82)
# [13:01] <jgraham> lol at Gareth Hay's latest email "I think [a spec that describes what to do with every possible set of input characters] is impossible"
# [13:02] <jgraham> How about: "For every input character: do nothing" That is a (useless) spec that describes what to do with every possible input character
# [13:04] <anne> would be nice if he tried to inform himself a little better
# [13:04] <anne> guess you can't have it all
# [13:14] <gsnedders> I guess the experiences of all implementers are irrelevant
# [13:22] * Joins: edas (edaspet@88.191.34.123)
# [13:27] <hasather> jgraham: http://hasather.net/html5/parsetree/
# [13:27] <hasather> hasather: (the GET should be a POST there)
# [13:28] <jgraham> hasather: Cool! I was just about to send an email mentioning this so it's just come at the right time :)
# [13:29] <hasather> it should also be mentioned on the page that you are the author
# [13:31] <jgraham> Where should the get be a post?
# [13:31] <hasather> for the textarea
# [13:32] <Dashiva> I suggest get for URI, post for source
# [13:32] <hasather> Dashiva: yea, that's what I had in mind
# [13:33] <jgraham> So put them in different forms? I guess that makes sense (though it's sad to use POST because you can't bookmark the result)
# [13:34] <Dashiva> hsivonen: Is the lack of a 'use referer' option on the conformance checker part of the 'no badges' effort?
# [13:34] <hasather> jgraham: yea, different forms
# [13:35] <hasather> jgraham: agree about the bookmarking, but there are limitations about GET length
# [13:35] <xover> jgraham: According to WebArch, that's how you need to do it since GET is supposed to be idempotent. (or so I've been informed)
# [13:35] <Dashiva> Wouldn't you usually bookmark URIs rather than plain source (which wouldn't update)?
# [13:36] <hasather> Dashiva: yea, agreed
# [13:37] <anne> xover, I don't think that applies here
# [13:37] <anne> hasather, I think it should be GET
# [13:37] <hasather> anne: for source? Why?
# [13:37] <jgraham> The use case for "bookmarking" when you input source is that you can pass around the URI e.g. by email
# [13:38] <anne> yup, much like we do for the live dom viewer
# [13:38] <jgraham> s/the URI/the resulting URI/
# [13:38] <Dashiva> "Providing a block of data, such as the result of submitting a form, to a data-handling process" is described as a primary use cast for POST
# [13:39] <anne> this is not data-handling or anything
# [13:39] <anne> you shouldn't use GET for deleting stuff for instance
# [13:39] <jgraham> I always thought that GET should be used for things that don't change state on the server, which is the case here
# [13:39] <anne> or "update" buttons, etc.
# [13:39] <Dashiva> It's the reverse, GET should not be used when state changes
# [13:39] <anne> jgraham, right
# [13:39] <anne> well yeah
# [13:40] <hasather> my main concern was about the limitations for GET
# [13:40] <jgraham> (but the practical limitations here are pretty annoying)
# [13:40] <hasather> it's easily broken
# [13:40] <anne> what are the practical limitations?
# [13:40] <Dashiva> The maximum length of a request URI
# [13:41] <jgraham> Actually the biggest problem is with the view in browser link since that always sends the source at the moment
# [13:41] <anne> role attribute, advantage #1: "Totally new element, no conflicts with existing content."
# [13:41] * Dashiva chuckles
# [13:41] <anne> both statements are false :)
# [13:41] <anne> in various ways
# [13:42] * jgraham considers just limiting the amount of data in the textarea
# [13:42] <xover> anne: I agree. But the TAG apparently do not.
# [13:43] <Dashiva> Also, the logs would benefit from not having random source cluttering them :)
# [13:43] <anne> 'URI:<br> <input type="text"'
# [13:43] <anne> euh
# [13:43] <anne> xover, I don't think the WebArch document forbids this type of usage
# [13:43] <anne> xover, if it does, it's indeed silly
# [13:44] <xover> anne: Trust me on this. It's why validator.w3.org has two separate forms on it.
# [13:45] <anne> xover, you mean they think that Google should use POST too for queries?
# [13:45] * anne doesn't really get this
# [13:45] <hasather> jgraham: I also want a "Not a valid URI" instead of http://hasather.net/html5/parsetree/parsetree.py?uri=%27&;source= :)
# [13:45] * xover doesn't really get this either...
# [13:46] <anne> I think you should remove the POST form for URIs if you have added one for them and tell them it doesn't make sense :)
# [13:46] <jgraham> hasather: Can you dump all the problems into an email or a bug report somewhere
# [13:46] * jgraham has to go shopping now
# [13:46] <hasather> jgraham: yep
# [13:47] <jgraham> Thanks :)
# [13:47] <anne> can't we just fix it?
# [13:47] <anne> as in, isn't it checked in in p/html5/?
# [13:47] <hasather> anne: it is
# [13:48] * anne might do s/type="text"/type="url"/
# [13:50] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [13:56] * Joins: gavin_ (gavin@74.103.208.221)
# [14:21] * Joins: zcorpan_ (zcorpan@84.216.40.144)
# [14:26] <zcorpan_> we have people who are 60 and 78 year old on the list?
# [14:26] <jdandrea> Aye.
# [14:26] * zcorpan_ didn't expect that
# [14:26] <jdandrea> :)
# [14:26] <anne> there's also someone who's 14
# [14:27] <zcorpan_> yeah
# [14:28] <anne> copyright claims on HTML5 and WF2?
# [14:28] * anne ponders
# [14:30] <anne> Did anyone got wiser on what Canonical HTML means?
# [14:30] <anne> s/got/get/
# [14:31] <jdandrea> Apparently it's HTML appearing in a biblical canon.
# [14:31] <jdandrea> Hmm.
# [14:31] <jdandrea> Did they mean normative? Um - hmm ... :\
# [14:32] <anne> someone says that it should not be HTML5 but Canonical HTML without actually explaining what it implies
# [14:32] <jdandrea> canonical: authorized; recognized; accepted - http://dictionary.reference.com/browse/canonical
# [14:33] <anne> k
# [14:33] <Philip`> Maybe it's meant to be developed as a sister product of Ubuntu
# [14:33] <jdandrea> LOL
# [14:33] <anne> maybe he did indeed just mean the literal meaning
# [14:33] <jdandrea> Maybe.
# [14:34] * jdandrea is delighted to see nine revised/new threads on public-html ... because reading is fundamental! (catching up ...)
# [14:34] <anne> seems that the people objecting are better served with XHTML2 :)
# [14:35] <jdandrea> There does appear to be a fundamental misunderstanding around HTML vs XHTML in terms of when to use. Casting HTML as XHTML ... might as well use XHTML.
# [14:37] <anne> One of the issues is that HTML is used to refer to the HTML syntax, HTML parsing and the HTML language (its semantics)
# [14:37] <anne> XHTML only uses the HTML language
# [14:37] <anne> but has the syntax and parsing of XML
# [14:38] <anne> And they both share a common model in which that language is exposed: the DOM
# [14:39] <anne> It would be nice if there was either a separate term for the HTML syntax / parsing or for the HTML language
# [14:39] <anne> On the other hand, because of script execution they're quite intertwined
# [14:40] * jdandrea nods
# [14:40] <jdandrea> WAML - web apps markup language? :)
# [14:40] <jdandrea> or is that taken
# [14:40] <anne> WML
# [14:41] <jdandrea> ah
# [14:41] <anne> But instead of having W for Wireless make it W for Web :)
# [14:41] <jdandrea> :)
# [14:41] <jdandrea> "It sounds so crazy, it just might work."
# [14:42] <jdandrea> Only bit of caution (and it may be unfounded/moot): WML is XML-based.
# [14:43] <anne> Yeah, sort of. Can't use that name really.
# [14:43] <jdandrea> hehe
# [14:43] <jdandrea> WebML
# [14:44] <zcorpan_> Web 5.0
# [14:44] <anne> We also need DOM5 and CSS5 for that, at least
# [14:45] * jdandrea wonders aloud if using the word "web" in place of "hypertext" is actually OK to do ... and then hears his son wake up ... brb
# [14:47] <anne> omg
# [14:47] <anne> Gareth is getting ridiculous
# [14:47] <anne> He just told Jonas Sicking that he probably hasn't used C and JavaScript :D
# [14:47] <anne> Actually, it's rather sad I suppose, not funny
# [14:58] * jdandrea is back - "Gareth did WHAT now?" :-o
# [14:58] * jdandrea probably hasn't reached that thread yet ... can't wait!
# [14:59] <Philip`> To be fair, he didn't say that directly - he just said that people who say what Jonas said usually haven't used the two languages
# [15:00] <anne> Jonas is one of the people hacking Mozilla and was just told he probably never had a look at JavaScript and C... (Mozilla uses those languages extensively.)
# [15:00] <jdandrea> ouch
# [15:00] <anne> Philip`, I hoped "probably" would make that clear
# [15:00] <gsnedders> anne: me? 14?
# [15:00] <anne> oh, you're not?
# [15:01] <gsnedders> anne: had my birthday just over two weeks ago
# [15:01] <gsnedders> I was 14 when I joined the WG, though
# [15:01] <zcorpan_> then we have someone who is 15 on the list ;)
# [15:01] <gsnedders> :P
# [15:01] <Philip`> He could be implying 'people who say what you're saying usually haven't used the two languages, though obviously I know you have so it's amusing to hear it from you too', or something, in which case he wouldn't be thinking that Jonas probably hasn't used them
# [15:02] <anne> Fair enough, although so far he seems quite uninformed
# [15:05] * jdandrea just got to "I think that is impossible" ("The spec describes what to do with every possible stream of input characters.") ROTFL!
# [15:05] <jdandrea> Oh my.
# [15:05] <gsnedders> "I don't want to keep responding to posters who are clearly trying to turn my argument into something else to fit their argument."
# [15:05] <gsnedders> what _is_ his argument, then?
# [15:06] <molily> i'm an outsider, hence a dumb question: are the results of the ballot binding for the WG? when will be decided if WA1.0 and WF2 will be adopted?
# [15:07] <gsnedders> any "No" vote is a formal objection, but the chairs can chose to ignore any formal objection
# [15:08] <gsnedders> molily: http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus
# [15:08] <anne> molily, what do you mean with binding?
# [15:10] <molily> ah, thanks *reading*
# [15:10] * jdandrea gets to James Graham's reply illustrating the WHATWG parsing spec as ... a state machine - ta-dah!
# [15:10] <gsnedders> jdandrea: it's a direct quote from the spec
# [15:11] <jdandrea> gsnedders: Indeed! This is one of the allures of the spec (for me) - having explicit state machine descriptions.
# [15:12] <gsnedders> jdandrea: it'd be thy impossible to represent them in any other way
# [15:12] <jdandrea> So when I read "I think that is impossible" I almost fell off my chair.
# [15:12] <jdandrea> Yes, but it's now being done to a rather explicit degree.
# [15:13] <gsnedders> it does however make implementing rather easy
# [15:13] <jdandrea> Bingo!
# [15:13] <gsnedders> though inevitably you end up changing away from exactly how it is stated in the spec
# [15:13] <Philip`> It looks like it'd be not entirely trivial to prove the parsing algorithm covers every possible input, but maybe it'd be worth someone trying it anyway (once it's finalised)
# [15:14] <anne> Philip`, because you could get loops and such with states?
# [15:14] <anne> xover, by doing the work at the W3C you handle the RF case implicitly, not?
# [15:14] <Philip`> You'd have to prove e.g. you can never be in the Tag open state with the content model flag being PLAINTEXT, because no behaviour is defined for that situation
# [15:15] <anne> That seems doable...
# [15:16] <Philip`> Yep, just probably not entirely trivial :-)
# [15:16] <anne> The content model flag is only changed after emitting a tag
# [15:16] <xover> anne: I dunno. The way the WHAT WG submission arrived is slightly unusual.
# [15:17] <anne> after emitting a tag you are always in the data state
# [15:17] <anne> xover, it went the same way for Web Forms 2 and XBL2
# [15:17] <anne> not sure it's that unusual
# [15:17] <xover> anne: As I said, I'm hopefull this is already on someone's todo list and has been or will be dealt with in due time.
# [15:18] <anne> I don't see the problem
# [15:18] <anne> if this wg does the docs wg members will have to sign them off after 90 days of FWPD or something
# [15:18] <anne> this includes, e.g., Apple
# [15:18] <anne> (actually, they have to do something within 90 days iirc)
# [15:19] <Philip`> Maybe it'd be easy if you just constructed a state space like { (Tag open, PCDATA), (Tag open, RCDATA), (Tag open, PLAINTEXT), ... } and found all the possible transitions and then you could easily prove what bits are never going to be reachable
# [15:19] <xover> I'm not enough of a hobby landshark to know whether the process automatically handles this or there is a need for some explicit action.
# [15:19] <zcorpan_> the current parsing spec already does cover every stream of characters, doesn it? (except pages that don't start with the doctype are undefined)
# [15:19] <anne> (like saying they have a patent and don't want to submit it or something)
# [15:19] <anne> zcorpan_, it's about proving
# [15:19] <Philip`> (and did the same for every other state and every other relevant variable)
# [15:19] <xover> Thus I wish someone who knows their way around this stuff would look at it and say “Yeah, that's handled. Don't worry your pretty little head with it.”.
# [15:19] <anne> yeah, i've been thinking of changing our implementation to instead of having flags having additional states
# [15:20] <zcorpan_> anne: perhaps pointing out that it says what to do with "anything else" cases everywhere
# [15:20] <anne> zcorpan_, please read the point Philip` raised above
# [15:20] * Joins: AGraf (Ashe@213.47.199.86)
# [15:20] * anne is pretty sure every case is in fact covered
# [15:20] * anne isn't sure they're covered in the correct way though
# [15:24] * anne wonders why Murray does so authorative
# [15:31] <molily> �Formal Objections receive Director consideration.� - director means TimBL? (if I understand http://www.w3.org/2005/10/Process-20051014/organization.html#def-Director correctly)
# [15:31] <xover> yes
# [15:34] <molily> is it likely that the objections will be dissolved?
# [15:35] <xover> Depends on your definition of "likely", but, yes, it is not an impossibility that the Chairs' will let the question carry over the objections.
# [15:36] <xover> However, the idea here is that if there are objections you reopen the question for discussion with the aim of achieving Consensus.
# [15:37] <molily> so it's rather a question of how and under which circumstances WA1 and WF2 will be adopted?
# [15:37] <xover> Which is why objections are required to suggest possible avenues to achieving Consensus.
# [15:37] <krijnh> [14:50] <anne> I suppose you could request some enhancements from krijnh <-- anne, which?
# [15:38] <xover> At this point, yes, essentially. And to what degree.
# [15:38] <xover> Further dicussions may alter the situation however, if there is significant new input.
# [15:41] <molily> I see. I wonder what will happen to the DOM/JavaScript innovations in the whatwg specs
# [15:42] <anne> krijnh, maybe a few lines above that? Don't recall
# [15:43] <xover> My personal guess is that they will be adopted with only minor changes. An organized review of it will be needed to ensure there aren't any boo-boo's lurking there, but...
# [15:43] <anne> molily, they are part of the proposal
# [15:44] <krijnh> anne: about the telcon minutes
# [15:45] <anne> oh right
# [15:45] <anne> comic sans and yellow background colors and such, like XForms :)
# [15:45] <molily> so they will perhaps be part of the future w3c html5 spec and not be incorporated into the w3c dom spec?
# [15:45] <Philip`> For extra fun, trying proving that the note in "Bogus comment state (This can only happen if the content model flag is set to the PCDATA state.)" is correct
# [15:45] <krijnh> anne: ah ;)
# [15:45] <Philip`> (Maybe I'm missing something, but it seems very non-obvious...)
# [15:46] <anne> molily, yeah, as per the charter
# [15:46] <anne> Philip`, what seemswrong with it?
# [15:47] * Quits: edas (edaspet@88.191.34.123) (Ping timeout)
# [15:47] <Philip`> You could get into Bogus comment state from Close open tag state when it's not PCDATA if the next few characters do match the tag name described earlier
# [15:48] <anne> are you sure?
# [15:48] <anne> I think in that case the characters will just be emitted
# [15:48] <xover> molily: The division between the HTML and DOM specs will be something to figure out during a review or similar. Right now it would seem they'll end up in the HTML spec, but that may change.
# [15:50] <anne> Philip`, you can never run into the anything else case because you already examined the characters
# [15:50] <Philip`> (Looks like there's also a sort of conflict in Close open tag state, because both the "If" and "Otherwise" clauses match when you're in RCDATA/PCDATA and the next characters do match the tag name but are not followed by one of the listed characters)
# [15:50] <anne> I'm pretty sure it's correct
# [15:50] <anne> Although I suppose the language could use some rewording
# [15:50] <Philip`> (though only 'sort of' because it's saying "If A, do X, otherwise if B, do Y" making it sound like B = !A when actually you can get A & B, I think)
# [15:51] <anne> no, it's more difficult than that
# [15:52] <anne> if A && !B do X otherwise if C or B do Y
# [15:52] <anne> you can substitute C with !A I suppose
# [15:52] * Quits: jdandrea (jdandrea@68.192.161.254) (Quit: jdandrea)
# [15:53] <Philip`> anne: Is it possible for "the tag name of the last start tag token emitted" to have other (invalid) characters which would fall in the 'anything else' case if it's like <:> or something?
# [15:53] <Philip`> I haven't read much of the parsing section at all, so it's probably covered somewhere - it's just a case where it's non-obvious that it's covered somewhere :-)
# [15:54] * Quits: zcorpan_ (zcorpan@84.216.40.144) (Ping timeout)
# [15:55] <anne> Philip`, that tag name can only be <script>, <style>, <xmp>, <noframes> and some others
# [15:55] <anne> Philip`, all very specific (sometimes old) elements compatible with [a-Z]
# [15:56] <Dashiva> Wonder if a script could read the parsing algorithm and automatically generate a graph for the state transitions
# [15:56] <Philip`> anne: I think it's "If A or (not A and B) do X, otherwise if not A do Y", which is slightly confusing when not A and B
# [15:57] <anne> first you have a check for CDATA or RCDATA
# [15:57] <anne> inside there's a check about the tag name
# [15:57] <Philip`> (where A = 'next few characters do not match', B = 'they are not immediately followed by one of these characters')
# [15:57] <anne> then there is the otherwise
# [15:57] <Philip`> anne: Ah, okay, that makes sense about tag names
# [15:58] <Philip`> Still non-obvious, though ;-)
# [15:58] <anne> which covers matching the tag name and PCDATA
# [15:58] <anne> so I think it's A && !B do X otherwise if !A && B do Y
# [15:59] <anne> Philip`, a specification requires detailed reading :)
# [15:59] <anne> Philip`, forwards, backwards, etc. :p
# [15:59] <anne> (that's actually noted somewhere near the top)
# [16:00] <anne> Also <:> is not an option
# [16:00] <anne> A tag name has to start with [a-Z] otherwise there won't be a tag name
# [16:01] <Philip`> Oh, I was forgetting the *DATA bit - in that case, it's saying "if C and (A or (not A and B)) do X, otherwise if not C or not A do Y", which is equivalent to "if (C and A) or (C and not A and B) do X, otherwise if C and not A do Y"
# [16:01] <anne> oops
# [16:01] <Philip`> which still isn't of the form "if D do X, otherwise if not D do Y"
# [16:01] <anne> if A && !B do X otherwise if !A _or_ B do Y
# [16:02] <anne> I'm not sure why yours is much more complicated :)
# [16:02] <Philip`> C = 'is RCDATA or CDATA', A = 'next few characters do not match', B = 'they are not immediately followed'
# [16:03] <Philip`> and the problem is the distinction between that A and B, where only A is mentioned in the otherwise clause
# [16:03] <Philip`> It'd be easy to solve by just dropping the whole "otherwise if not D" and just writing "otherwise" :-)
# [16:04] <Philip`> anne: The problem is that "requires detailed reading" is incompatible with 'obviously covers every possible stream of input characters'
# [16:04] <anne> fwiw, I'm merging the check of matching the tag name and the characters that follow fwiw
# [16:05] <Philip`> That merging doesn't seem to be made in the spec's text, though
# [16:05] <gsnedders> Fatal error: Unrecognised word — fwiw.
# [16:05] <gsnedders> (I'm still in draconian English mode)
# [16:06] <anne> fair enough
# [16:07] * anne wonders why html5lib checks if there's a current token
# [16:07] <anne> because in theory that situation should never occur!
# [16:09] <Philip`> Dashiva: The parsing algorithm has far too much English for that, I believe. Someone could probably try to write a formal model based on it, which I guess would be a bit tricky since the English describes some tricky things, but it'd be really nice to do that so you can have a reference implementation (for building tests) and prove certain properties
# [16:09] * Joins: DanC_lap (connolly@128.30.52.30)
# [16:09] <Philip`> and then you could convince people that it really does cover every possible input
# [16:10] <Philip`> (and I suppose it might help find redundancies in the spec's algorithm, and possible safe optimisations)
# [16:11] <anne> the spec algorithm just defines that "a" results in "b"
# [16:11] <anne> it doesn't actually prescribe "magic" which sits in between (although it gives you an idea of how to do it)
# [16:16] <Dashiva> Philip`: All you'd need would be to pick up the presence of state names inside each state, though
# [16:21] <Philip`> Dashiva: Ah, you could do that; but I'm not sure what it'd be useful for, since it'd be an overestimate of the real transitions
# [16:22] <Dashiva> Instead of having to check every single state, you'd only have to check the ones that -might- lead to it
# [16:23] <Philip`> If you're doing that by hand, you can just use the browser to search for the state name
# [16:23] <Philip`> If you're doing it automatically, you'd need much more detail to follow the real state transitions
# [16:24] <Dashiva> Gives a better overview, though
# [16:24] * Dashiva also plans to post it on digg as "map of html5"
# [16:25] <Philip`> (Er, by "real state" I think I mean something more than the explicitly listed states - i.e. you'd have a state like ( Close tag open state, RCDATA, tag-name-is-one-of-the-list-of-weird-ones, some-other-variables ) which is precise enough)
# [16:26] <Philip`> Ah, I do appreciate nice overview pictures :-)
# [16:27] <Philip`> I'd guess that'd be reasonably easy to construct since you just look for the <dt>s and <a href="#*-state">s and then output a Graphviz file
# [16:28] * Quits: AGraf (Ashe@213.47.199.86) (Ping timeout)
# [16:30] * Joins: AGraf (Ashe@213.47.199.86)
# [16:30] * Philip` would be quite interested in seeing such a thing :-)
# [16:30] <gsnedders> anyone want to draw a flow chart?
# [16:31] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
# [16:34] * Joins: myakura (myakura@125.194.247.196)
# [16:44] <gsnedders> I can't get the Opera 9.2 disk image to mount on Mac OS 10.4.9…
# [16:45] * Joins: zcorpan_ (zcorpan@217.211.77.236)
# [16:49] * Quits: tH (r@87.102.20.82) (Ping timeout)
# [16:55] <anne> xover, http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing
# [16:57] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
# [16:59] * Quits: myakura (myakura@125.194.247.196) (Quit: Leaving...)
# [17:01] <xover> anne: Thanks. But I can't sufficiently decipher the legalese to tell one way or another whether that settles it, or would settle it 90 or 150 days after the first public WD, or not at all etc..
# [17:01] <xover> For instance, is the WHAT WG submission a “Member Submission”?
# [17:04] * Joins: polin8 (polin8@24.184.204.6)
# [17:07] * Joins: MrNaz (Naz@203.214.95.166)
# [17:08] <anne> no
# [17:08] <hsivonen> xover: what is unclear considering that Apple, Mozilla and Opera are all participating in the HTML WG for the purposes of the Patent Policy?
# [17:08] <anne> WF2 was at some point
# [17:11] <xover> hsivonen: I'm simply not a lawyer. Given it's come up, and things like Apple's lawyer-gram on <canvas>, I would just like someone like W3C Legal (or even Apple Legal or whatever) to say “It's not a problem.”
# [17:12] <anne> The spec won't be anything if it's a problem
# [17:12] <hsivonen> xover: the Apple lawyer-gram essentially alluded that it isn't a problem in a carefully non-committal lawyer-language
# [17:12] <anne> That's what the above pointer will tell you
# [17:13] <xover> anne: Exactly. So it would be good to get that squared away.
# [17:13] <hsivonen> xover: the way the W3C Patent Policy works, you wait until later and let things be resolved by inaction on Apple's behalf
# [17:13] <hsivonen> (hopefully, IANAL)
# [17:14] * xover doesn't even play a lawyer on TV... :-)
# [17:14] <anne> right
# [17:17] * Quits: polin8 (polin8@24.184.204.6) (Quit: polin8)
# [17:18] <hsivonen> xover: my non-lawyer assesment is that Apple is more likely to be willing to grant a blanket license for <canvas> later in the process (by inaction) than to ever identify which ones of their patents they think might be construed to cover <canvas>. I think that should satisfy us. (but I am not an Apple lawyer and I'm only speculating as myself with any Mozilla hat strictly off)
# [17:19] <xover> hsivonen: Yes, as mentioned (several times), I fully expect someone has either handled this or has it on their todo to handle it in due time.
# [17:20] <Dashiva> hsivonen: Is the lack of a 'use referer' option on the conformance checker part of the 'no badges' effort?
# [17:20] <hsivonen> Dashiva: part of the comply with RFC 2616 effort
# [17:20] <xover> I just would like to see someone say that to get it out of the way.
# [17:21] <hsivonen> xover: the whole point is that the Apple non-lawyer staff won't say anything about it and the lawyer already said what she said
# [17:21] <xover> ANd to me it seems natural that the companies behind the submission come out and make a statement on this.
# [17:21] <Dashiva> hsivonen: How so?
# [17:21] <anne> We all agreed to the patent policy
# [17:21] <anne> It's quite clear
# [17:22] <anne> (We = The companies behind the submission.)
# [17:22] <anne> I don't think much else will be said
# [17:22] <hsivonen> Dashiva: it is inappropriate to use Referer for purposes other than log analysis-type diagnostics
# [17:24] <anne> Does anyone know why that header name is misspelled btw?
# [17:24] <hsivonen> anne: someone misspelled it early on
# [17:25] <anne> heh
# [17:26] <Dashiva> Good thing that doesn't invalidate the entire rfc 2616
# [17:29] <hsivonen> Dashiva: but yeah, it is partially part of the no badges effort as well as it would suggest that people link pages to the conformance checker for visitors instead of using a bookmarklet for themselves
# [17:38] * Joins: tH (r@87.102.20.82)
# [17:44] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [17:49] * Quits: Lachy (Lachlan@124.168.27.56) (Ping timeout)
# [17:49] * Joins: gavin_ (gavin@74.103.208.221)
# [17:50] * Joins: Lachy (Lachlan@124.168.27.56)
# [17:54] * Quits: hasather (hasather@81.235.209.174) (Client exited)
# [17:55] * Joins: hasather (hasather@81.235.209.174)
# [18:01] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [18:11] <anne> Zeros, I'm not sure why you blame the vendors of not implementing the specs when the specs are broken
# [18:14] <Zeros> anne, I blame the vendors for cherry picking the specs
# [18:15] <Zeros> The comment was made in the context of viability for Flash. Flash works because it's implemented completely, it does what's expected of it.
# [18:16] <Lachy> flash works because it's only implemented by one vendor, and their implementation is the definition of conformance
# [18:16] <Zeros> Lachy, Browsers don't need to be this inconsistent
# [18:17] <Lachy> that's true, but until HTML5 came along, there was no spec they could reliably follow
# [18:17] <Zeros> While Gecko implemented print css, safari got text shadow?
# [18:17] <Zeros> Lachy, that's not true
# [18:17] <zcorpan_> Zeros: sgml doesn't define error handling
# [18:17] <zcorpan_> for most cases anyway
# [18:17] <Zeros> zcorpan_, I'm not even talking about error handling, where did that come from?
# [18:18] <Zeros> I'm talking about huge disparities in the feature set
# [18:18] <zcorpan_> Zeros: you said it wasn't true that they had no spec to follow
# [18:18] <zcorpan_> ah
# [18:18] <zcorpan_> ok
# [18:18] <anne> Zeros, specs have been pretty bad and there is a huge amount of undocumented stuff we've been mostly busy with
# [18:18] <anne> Zeros, catching up with IE, so to say
# [18:19] <Zeros> Browsers won't be able to take Flash/Silverlight head on until there's an expectation of consistency across all of them
# [18:19] <Philip`> (Do people in the SGML world believe that all SGML documents should be valid, and is that actually true in the real SGML world?)
# [18:19] <anne> There's an SGML world?
# [18:19] * Joins: jdandrea (jdandrea@68.192.161.254)
# [18:19] <zcorpan_> anne: was about to say the exact same words
# [18:20] <anne> Zeros, yes, we're trying to improve situation
# [18:20] <Zeros> anne, I know
# [18:20] <anne> Zeros, thanks to HTML5 there's been more consistency on features such as <object> for instance
# [18:20] <anne> And thanks to CSS 2.1 and Acid2 browsers get more interoperable in rendering
# [18:21] <Zeros> We still have a ways to go though. My concern is that when it comes time to implement HTML5 Opera will implement points 1-6, and Gecko 2-8 and Webkit 1-2 and 5-3
# [18:21] <Philip`> I assume some people must have used SGML for something in the past - at least I've seen examples of the OED being marked up as SGML, so I was wondering if they just ran everything through a validator so that processing tools wouldn't have to care about errors
# [18:21] <anne> The problem is mostly that we've been stuck with lots of legacy crap.
# [18:21] <Lachy> in what message did Zeros blame vendors for not implemeting things?
# [18:21] <anne> See the logs of this channel.
# [18:21] <Zeros> Lachy, It was a conversation about why Flash was viable yesterday
# [18:21] <Lachy> I just did, but couldn't find it
# [18:21] <Lachy> oh
# [18:22] <anne> Zeros, yes, it's likely that that will happen
# [18:22] <anne> Zeros, customer demand, basically
# [18:22] <Dashiva> 1-6, 2-8 has already happened with CSS, so no surprise there
# [18:22] <Zeros> And that's why HTML can never reach a level of consistency that can sink flash
# [18:23] <Zeros> Lachy, If the spec was to blame then no one would have implemented it. If Gecko and presto have it and Webkit doesn't you can't blame the spec.
# [18:23] <anne> Zeros, you can, actually
# [18:23] <Zeros> anne, you can't. If the spec was /that/ vague then no one would have supported it.
# [18:24] * Dashiva points at HTML4
# [18:24] <anne> untrue
# [18:24] <Zeros> The fact that lots of features exist in various browsers with big gaps is something else entirely.
# [18:24] <anne> browsers reverse engineer each other which takes a lot of time and resources
# [18:24] <anne> For instance, that's how parsing of HTML is implemented
# [18:24] <anne> Or how <object> was mostly done
# [18:25] <Zeros> A linear implementation plan with goals is the only way that HTML+JS+CSS solutions can take on other platforms
# [18:25] <anne> or CSS
# [18:25] <Philip`> (Oh, from http://www.ariadne.ac.uk/issue24/oed-tech/ it sounds like SGML wasn't actually good enough for their needs, so they only use SGML for a simplified online-searchable version)
# [18:25] <anne> browser engineers have invested lots of time in reverse engineering weird things IE did with CSS which eventually ended up in CSS 2.1
# [18:26] <Zeros> hardly
# [18:26] <Zeros> you spent lots of time implementing HTML5 features that haven't even been finalized
# [18:26] <Zeros> Webkit spent lots of time adding text effects
# [18:26] <Zeros> Gecko spent lots of time on JS features that aren't in the spec
# [18:26] <Zeros> The browser vendors are to blame for the fragmentation
# [18:27] <zcorpan_> Zeros: how is that incompatible with what anne said? can't they spend lots of time with both?
# [18:27] <Philip`> (Interestingly that page also mentions archaeologists from the year 3000)
# [18:27] <Lachy> Zeros, it's called competition and innovation
# [18:27] <Lachy> browsers implement the features that they feel will be most useful. When others see that features in one browser are successful, it gives them more motivation to implement it too
# [18:28] <Zeros> Lachy, It's reduces consistency and makes other solutions that are more consistent more viable
# [18:28] <anne> I agree with the larger point though that more convergence would be nice
# [18:28] <anne> And I think HTML5 is a good start for that
# [18:28] <Zeros> I hope so
# [18:28] <Lachy> consistencey will come from better quality specs and test suites
# [18:28] <anne> Especially given that lots of HTML5 is already in browsers, it's just that it's not interoperable enough
# [18:29] * zcorpan_ will work on test cases for already-implemented things that currently lack tests, which will help other vendors to implement the same
# [18:29] <Zeros> zcorpan_, they can't do both, clearly. It's like putting the wall paper up before the roof is on the house
# [18:30] <anne> We're doing both
# [18:30] <anne> (It's how most companies work.)
# [18:30] <Lachy> can't do both what?
# [18:31] * Lachy missed some messages...
# [18:31] <zcorpan_> reverse engineer other browsers and implement new stuff
# [18:31] <Zeros> Lachy, become conferment and innovate.
# [18:32] <anne> The problem currently is that we can't just implement CSS or HTML4 to the letter
# [18:32] <Zeros> Lachy, They're spending lots of time adding features that aren't in the spec, while features that are in the spec haven't been implemented yet.
# [18:32] <anne> we'd break stuff
# [18:32] <Philip`> Maybe it's a case of having feature 1 which can't be worked on by more than n people simultaneously (because they'd just get in each other's way) and feature 2 which can't be worked on by more than m, and when you have n+m people that means it's just as quick to work on both independent features and won't slow down the other features
# [18:32] <anne> Changes have to be carefully tested, etc., which eats time
# [18:32] <Zeros> How many man hours did it take to implement Canvas for instance?
# [18:32] <Zeros> And yes, and I know, vendors respond to market pressure since they're businesses.
# [18:33] <anne> I've no idea what it took to implement <canvas>
# [18:33] <Zeros> Anyway, without this turning into a bash vendors discussion. I think that setting conformance goals for browser vendors would benefit everyone
# [18:33] <anne> I heard statements from Apple employees that it took a lot less long than implementing SVG
# [18:33] <anne> And other implementors had implementations ready quite quickly too. Even 3D <canvas> demos
# [18:33] <Zeros> If Gecko, Webkit, Presto and IE teams got together and said "By the end of 2010 we'll all have implemented CSS2 completely"
# [18:34] <anne> That's not the right way to put it.
# [18:34] <Zeros> We need to converge, not fragment
# [18:34] <Lachy> that would be nice if the could, and then CSS2.1 could move to REC
# [18:34] <anne> The question is whether CSS is fixed fast enough and if there'll be enough tests
# [18:34] <zcorpan_> Zeros: who are we?
# [18:34] <Zeros> anne, Throwing a spec at the vendors and saying "implement whatever you want in whatever time frame you want" doesn't get consistency
# [18:35] <Zeros> It gets the same fragmentation we have now
# [18:35] <anne> Throwing a spec at a vendor in general doesn't give you consistency
# [18:35] <anne> Because specs typically suck
# [18:35] <Zeros> Webkit gets X feature and Opera gets Y, and Flash all the while is consistent
# [18:35] <Lachy> Zeros, do you have a concrete proposal to improve the situation?
# [18:35] <Dashiva> Zeros: Offer a substantial reward to the first browser to implement it successfully :)
# [18:36] <zcorpan_> the reward is more market share
# [18:36] <anne> You get convergence with tests and fancy tests like Acid
# [18:36] <Dashiva> Correlation, not causation
# [18:37] <Zeros> Lachy, Yes, the vendors need to come to a consensus on target implementation goals and milestones for HTML5 conformance.
# [18:38] <zcorpan_> Zeros: do you agree that a good way to improve this situation is to create test cases for things that at least one browser already has implemented?
# [18:38] <Zeros> zcorpan_, of course
# [18:38] <zcorpan_> good, because that's what i will be doing :)
# [18:38] <Zeros> zcorpan_, that doesn't actually compel the developers to not cherry pick though
# [18:39] * Philip` is trying too, at least in one tiny area :-)
# [18:39] <Dashiva> Once there's a public test case, it becomes easy to see that some browsers are failing to support it
# [18:39] <zcorpan_> Zeros: who will decide what they should implement and in what order?
# [18:39] <anne> I don't think you'll get vendors to commit to something like that.
# [18:39] <Zeros> zcorpan_, they will, I want /them/ to set the goals and the time frame and them agree to it. re "vendors need to come to a consensus"
# [18:40] <anne> I think having lots of testcases will be compelling to encourage them to improve their support. Especially if other vendors pass those tests already.
# [18:40] <zcorpan_> Zeros: what if e.g. opera and mozilla have different goals? surely being first to implement a feature is a reason for users to switch to that browser
# [18:40] <anne> s/be compelling to//
# [18:41] <Zeros> zcorpan_, and it's a reason for developers to use Flash
# [18:41] <zcorpan_> Zeros: i don't disagree
# [18:41] <Lachy> zcorpan_, it only becomes a reason if sites begin to use those features and users are aware that they're available in an alternative browser
# [18:41] <Philip`> If Flash has more features than the subset of HTML which all browsers support, what's actually wrong with Flash?
# [18:42] <zcorpan_> but telling other vendors what you will implement might mean that the other vendor implement it before you, which is a reason for user to switch to that browser
# [18:42] <zcorpan_> so telling other vendors what to implement is against the competition
# [18:43] <zcorpan_> which may be a reason for them to not do so
# [18:43] <anne> Philip`, apart from it being proprietary and the need for devices to pay for a license for a player? dunno
# [18:43] <zcorpan_> not being able to view source ;)
# [18:43] <anne> (well, it's not so interoperable among devices and between devices and desktop and linux runs a few versions behind)
# [18:43] <Zeros> Philip`, HTML+CSS+JS has the potential to remove the need to use flash for applications, and with canvas maybe even for animations
# [18:44] <Zeros> We just need consistency first :)
# [18:44] <Zeros> ("we" as in the web browsers, developers and users)
# [18:45] <Philip`> If browser A has features 1-100 and browser B has features 50-150, and Flash has features 50-100, then there's still no consistency between browsers but it's still providing enough reasons to use the inconsistent HTML rather than Flash
# [18:45] <anne> Philip`, maybe that it requires some type of authoring tool other than a text editor, but I'm not sure if that's still true
# [18:45] <Dashiva> Flash applications feel like straitjackets to me. Probably not a general reason, though.
# [18:45] <Philip`> If Flash instead had features 50-100 and 151-200, I guess that's the problem case where it's better to use Flash because it's just better than the alternatives
# [18:46] <Zeros> Philip`, You're comparing them in the wrong manner
# [18:46] <Philip`> If Flash instead had features 1-100 then I guess that's the problem case where it's better to use Flash because ~100% of users have it whereas ~20% have browser A
# [18:46] <Philip`> but I have no idea what cases are realistic
# [18:46] <Zeros> Flash has features 0-150, it implements everything the developer expects it to
# [18:46] <Zeros> Browsers are where the fragmentation is, flash does what it's supposed to
# [18:46] <Philip`> Zeros: In that case, Flash is just better than everything else, so it deserves to win
# [18:47] <anne> It would already have won :)
# [18:47] <Zeros> um... That wasn't what I was trying to argue
# [18:47] <Zeros> :p
# [18:47] <Zeros> It's not about winning, lets make HTML based solutions more viable.
# [18:47] <Zeros> HTML5 is a big step
# [18:48] <Zeros> Now we need collaboration between the vendors
# [18:48] <anne> What do you think WHATWG was? A tea party?
# [18:48] <anne> s/was/is/
# [18:48] * gsnedders dances!
# [18:49] <gsnedders> _One_ unread email!
# [18:49] <Philip`> Maybe the WHATWG is a tea party without the mad hatter, but now we've got the HTML WG to fix that
# [18:49] <Zeros> anne, What WHATWG got us a collaborative spec. I don't see where it prevents feature set fragmentation.
# [18:50] <Zeros> And it wasn't truly collaborative since IE (was|chose to be) left out
# [18:51] <Zeros> I guess if every other browser was consistent in features and IE was the last man standing it would be a strong case to get users to switch, or kick MS in the pants to get rolling
# [18:51] <zcorpan_> ms were invited several times, aiui, but they wouln't join because of patent policy things... which is why the html wg started
# [18:52] <zcorpan_> if the whatwg had a proper patent policy the html wg might not have existed
# [18:52] * zcorpan_ is only speculating, of course
# [18:52] <anne> Yes, the HTML WG mostly started because IE couldn't participate in the WHATWG
# [18:53] <hsivonen> Philip`: http://2006.xmlconference.org/proceedings/162/presentation.html
# [18:56] <hsivonen> Philip`: in reference to SGML and validation
# [18:56] <hsivonen> zcorpan_: it wouldn't have been as much a matter of having a policy as a matter of getting companies to agree to it
# [18:57] <hsivonen> zcorpan_: the W3C and the IETF have established themselves as organizations whose PP companies respect
# [18:57] <hsivonen> zcorpan_: so engineer can tell lawyers to comply :-)
# [19:14] <zcorpan_> hsivonen: ok
# [19:15] * Quits: ROBOd (robod@86.34.246.154) (Client exited)
# [19:15] * Joins: ROBOd (robod@86.34.246.154)
# [19:28] * Parts: Zoffix (Zoffix@99.244.41.243) (K-Lined)
# [19:44] * Joins: edas (edaspet@88.191.34.123)
# [19:44] * Joins: dbaron (dbaron@71.198.189.81)
# [19:51] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [19:53] <anne> interesting, David just pointed out we have over a hundred e-mails a day now
# [19:57] * Joins: gavin_ (gavin@74.103.208.221)
# [20:00] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [20:05] <edas> anne, and I'm asking myself ho many people really read all emails each day
# [20:05] <edas> we need less traffic on this list (and better signal/noise ratio)
# [20:15] * Joins: DanC_lap (connolly@128.30.52.30)
# [20:50] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [20:55] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [21:04] * Joins: Roger (roger@213.64.74.230)
# [21:07] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [21:11] * Quits: molily (molily@85.212.25.62) (Client exited)
# [21:24] * Joins: hyatt (hyatt@24.6.91.161)
# [21:25] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [21:27] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [21:29] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [21:29] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [21:42] * Quits: DanC_lap (connolly@128.30.52.30) (Client exited)
# [21:48] * Joins: sbuluf (hvtbcfc@200.49.140.172)
# [21:51] * Quits: loic (loic@90.29.119.252) (Quit: hoopa rules)
# [21:59] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [22:00] * Quits: zcorpan_ (zcorpan@217.211.77.236) (Ping timeout)
# [22:04] * Joins: gavin_ (gavin@74.103.208.221)
# [22:05] * Joins: schepers (schepers@208.38.57.47)
# [22:36] * Quits: schepers (schepers@208.38.57.47) (Ping timeout)
# [22:52] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [23:33] * Joins: mjs (mjs@64.81.48.145)
# [23:42] * Joins: zcorpan_ (zcorpan@217.211.77.236)
# Session Close: Sun May 06 00:00:00 2007

The end :)