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

Options:

# Session Start: Thu May 03 00:00:00 2007
# Session Ident: #html-wg
# [00:00] * tH wonders when this irc log became a meeting
# [00:02] <schepers> looks like sometime late last night...
# [00:02] <billmason> It's in a charter somewhere, probably.
# [00:03] <schepers> man, this crowd can be pretty snide...
# [00:03] <hsivonen> schepers: what was snide?
# [00:05] <schepers> well, almost everything anne said to boyer, for example, and then also anytime someone makes a typo or disagrees with some aspect of the WHATWG work, or brings up W3C process... that will do for starters, I guess?
# [00:05] * schepers read through the backlog
# [00:07] <hsivonen> schepers: it is perfectly reasonable to ask for technical detail when someone objects to the WHATWG work. how else could it we fixed?
# [00:07] <schepers> hsivonen: do you really think that's what I'm talking about?
# [00:08] <hsivonen> schepers: I don't know. What are you talking about?
# [00:08] <schepers> it's not... I'm talking about the tone of the discussions
# [00:09] * Joins: mjs (mjs@17.255.99.9)
# [00:09] <hsivonen> mjs: you missed a discussion about forms and charter
# [00:12] <Hixie> at the risk of being called snide, "avoided" might be a better word
# [00:13] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
# [00:13] <schepers> Hixie: you're snide!
# [00:15] <schepers> (not that I actually think that was snide)
# [00:16] <mjs> hsivonen: summary?
# [00:16] <mjs> or should I read the logs?
# [00:17] <hober> Reading the log shouldn't be too bad
# [00:17] <schepers> boyer made minutes here: http://www.w3.org/2007/05/02-html-wg-minutes.html
# [00:17] <mjs> I still have 40 unread public-html emails so I'd find a summary helpful, but of course no obligation
# [00:18] <hsivonen> mjs: http://krijnhoetmer.nl/irc-logs/html-wg/20070502#l-381
# [00:18] <hsivonen> mjs: John Boyer objected to adopting WF 2.0 as a starting point citing charters
# [00:19] <hsivonen> mjs: also objected to this wg developing forms tech on its own
# [00:19] <hober> Basically, he objects to the following interpretation of the HTML WG charter
# [00:19] <mjs> so he cited political arguments in lieu of technical ones to support his Formal Objection?
# [00:20] <hsivonen> mjs: in summary, yes
# [00:20] <gavin> technical arguments about the process was the way he put it I think
# [00:20] <gavin> since the question at hand was a process question and not a technical one
# [00:21] <hober> (the interpretation) "The HTML WG starts with HTML5, the forms WG starts with XForms, and the goal of the Joint TF is to ensure that both documents converge on architectural compatibility"
# [00:21] <gavin> as I understand it, he is opposed to using WF2 as a base
# [00:21] <gavin> so it makes sense for him to formally object
# [00:21] <gavin> what's not clear are the reasons why he objects
# [00:22] <schepers> it does seem in bad faith to interpret the charter that way, to me
# [00:22] <gavin> (not clear to me)
# [00:22] <hober> His interpretation is that neither WG has anything about forms in independent documents, that the TF starts with an empty document and produces something in the spirit of a smerge of xforms and wf2, and then gives this to each wg
# [00:22] <hober> or something like that; it wasn't entirely clear
# [00:22] <schepers> I think that's a fair summary
# [00:23] <Hixie> as far as i can tell what's happened here is that some proponents of xforms got the w3c to agree that xforms would be part of the html5 language in some way, and then the w3c opened up the working group to the public, and the majority of people on the group now couldn't care less about xforms
# [00:23] <hober> Given that interpretation, he saw the HTML WG's vote to adopt WF2 as a starting point as an attempt to subvert the TF before it starts
# [00:23] <mjs> so the XForms REC would be resciended under his proposal?
# [00:23] <Hixie> and so as i see it there are three ways forward:
# [00:23] <mjs> or does he require only the HTML WG to drop existing forms features pending TF results?
# [00:23] <Hixie> 1. ignore the majority, honour the earlier agreement with xforms, and push xforms through this wg
# [00:23] <hober> mjs: I don't know
# [00:24] <Hixie> 2. create a task forcee to create a new language from scratch that involves xforms wg members
# [00:24] <Hixie> 3. ignore the prior agreement with xforms, and push an html-specific language through this wg (i.e. base the work on wf2)
# [00:24] <Hixie> 1 would basically cause a big chunk of the wg to quit
# [00:24] <schepers> would it?
# [00:24] <mjs> probably
# [00:25] <hober> I don't think those are the only three options
# [00:25] <schepers> I thought you said that the majority doesn't matter, that only technical arguments matter?
# [00:25] <hsivonen> Hixie: #2 sounds like a compromise designed to make everyone equally inconvenient
# [00:25] <Hixie> 2 would cause the forms part to never be finished, because you'd end up with the same kind of stand-off situation we had with sXBL (probably very similar, again with me in the position of annoying guy who won't compromise)
# [00:25] <mjs> well, there are no technical arguments on the merits for option 1
# [00:25] <schepers> and I agree that those aren't the only 3 options
# [00:25] <Hixie> and 3 would cause the xforms people to blow their top
# [00:26] <hsivonen> schepers: what other options you see?
# [00:26] <hober> I think the "each wg has own document, and (via the tf) try to come to some kind of compatible middle without killing each other" could be option #4 (and is the current option, at least the way I read the charter)
# [00:26] <Hixie> hober: that's 2
# [00:26] <Hixie> s/from scratch// if you like
# [00:26] <mjs> I don't think #4 and #2 are the same
# [00:26] <hsivonen> I see this: adopt WF 2.0 as part of W3C HTML5, extend parsing algorithm to produce DOMs that XForms extensions can hook to
# [00:27] <mjs> #4 would make the TF advisory to two separate specs, rather than in charge of a single co-owned spec
# [00:27] <hober> Well, 2 sounded like the TF starts with nothing -- on my read #4 means the TF produces, not a form language, but a document showing (if possible) that the two wgs' form tech are in some sense compatible, whatever that means
# [00:27] <hober> mjs: yes, exactly
# [00:27] <Hixie> well you can certainly create lots of process that makes 1, 2, and 3 above _look_ like other options
# [00:27] <schepers> 1a. honor the earlier agreement with xforms, and come up with a technically sound and useful upgrade path from some variant on wf2 to some variant on xforms
# [00:27] <mjs> hober: not "compatible" but "architecturally consistent"
# [00:28] <hober> perhaps with a third, non-spec document coming out of the tf
# [00:28] <hober> mjs: yes, again excatly :)
# [00:28] <mjs> schepers: the problem is there's no clear meaning for what "architecurally consistent" means
# [00:28] <mjs> thus, it is not clear what, if any, changes to WF2 are needed
# [00:28] <mjs> John Boyer refuses to even propose specific changes to WF2
# [00:28] <hober> schepers: that presumes that that's an upgrade path
# [00:28] <mjs> so that makes it less clear
# [00:28] <Hixie> the thing is at the end of the day the xforms proponents and the proponents of the proposed html5 design guidelines have fundamentally incompatible goals.
# [00:28] <schepers> then let's come up with one in good faith, how about?
# [00:29] <mjs> my interpretation is that WF2 and XForms are already architecturally consistent
# [00:29] <mjs> they live in different namespaces
# [00:29] <Hixie> john boyer doesn't care about architecturally consistent
# [00:29] <mjs> and WF2 has enough features to machine-translate XForms content to it
# [00:29] <schepers> that's not good faith
# [00:29] <Hixie> that's not what he wants
# [00:29] <hsivonen> schepers: can't we admit in good faith that the goals are incompatible so there are two form technologies in different namespaces?
# [00:29] <mjs> schepers: I sincerely think that's architecturally consistent
# [00:29] <Philip`> mjs: I think he was refusing to propose specific changes before the TF is formed, because that's meant to be the TF's job
# [00:29] <Hixie> anyway
# [00:29] <hsivonen> schepers: what's good faith?
# [00:29] <Hixie> i don't see this conversation going anywhere productive
# [00:30] <Hixie> so i'm gonna go back to work :-)
# [00:30] <mjs> my preference would be to let Boyer's FO go to the Director with suitable response from us
# [00:30] <mjs> as far as procedure goes
# [00:31] <schepers> hsivonen: I'm not going to be backed into defining every word I use... I think maciej knows what I mean
# [00:31] <mjs> and The Director can give it all due consideration
# [00:31] <mjs> schepers: I honestly don't -- do you think I'm insincere in my claim that I believe that constitutes architectural consistency?
# [00:32] <mjs> obviously you can't have a language that's syntactically compatible with both existing XForms and existing HTML Forms
# [00:32] <schepers> I can't comment on your sincerity, but I don't think that was the intent of the charter
# [00:32] <mjs> so that can't be what "architecturally consistent" means
# [00:33] * Philip` always imagines the name The Director (especially with capitals) as some evil shadowy movie villain whose true identity is unknown
# [00:33] <mjs> I would take it to mean "no conflicts if you implement both in one implementation" or something like that
# [00:33] <mjs> the way JPEG is architecturally consistent with GIF
# [00:33] <mjs> Philip`: people say "The Director" instead of "Tim" because, I guess, it sounds more imposing
# [00:33] <Hixie> the way that the svg text model is not architecturally consistent with css? :-)
# [00:33] * Hixie ducks
# [00:35] <schepers> we're getting feedback about specific ways in which certain implementations are finding issues with implementing both CSS and SVG text, and we're hoping to take that into account... it may be that there is no solution, but we hope not
# [00:35] * Quits: tH (r@87.102.32.222) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [00:35] <schepers> we've also gotten implementor feedback to the contrary
# [00:38] <mjs> from an implementation that's shipped? (the only such feedback I heard was from Adobe on an implementation that hadn't yet shipped at the time, and I believe their SVG plugin has since been desupported)
# [00:39] <schepers> does that matter?
# [00:39] <schepers> it's about technical assessments, not popularity contests, right?
# [00:41] <schepers> but in any case, as I said, we're hoping to find a path forward for those implementations that did have a problem
# [00:44] <mjs> it does matter, because you can't check whether an unshipped implementation got it right
# [00:44] <schepers> fair enough
# [00:44] <mjs> implementations that are not available to the public carry no weight for things like "2 interoperable implementations" requirements
# [00:45] * schepers isn't sure about that
# [00:45] <mjs> well, at least the CSS WG requires them to be shipping products available to the public and not experimental or testing only
# [00:46] <schepers> I'm not sure why you're ignoring my larger point, though
# [00:46] <mjs> I think your larger point, that you are taking implementation issues into account on this matter, is a good one
# [00:46] <mjs> or rather, it is welcome news to me
# [00:47] <schepers> if it were up to me, there are lots of things I'd change about SVG
# [00:47] <schepers> but this is OT for #html
# [00:49] <mjs> yeah, not really relevant here
# [00:55] * Joins: zcorpan (zcorpan@84.216.43.182)
# [01:07] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [01:18] * Quits: Lachy (Lachlan@124.168.27.56) (Ping timeout)
# [01:19] * Quits: kingryan (rking3@66.92.187.33) (Quit: kingryan)
# [01:22] * Quits: billmason (billmason@69.30.57.156) (Quit: .)
# [01:25] <heycam> mjs, i believe "architecturally consistent" means having a (non-trivial) mapping to the same underlying model
# [01:26] <heycam> at least that's my interpretation, i wasn't there during the months of charter teeth-gnashing
# [01:27] * heycam begins reading 230 unread public-html mails
# [01:27] * Joins: John_Boyer (boyerj@32.97.110.142)
# [01:27] <John_Boyer> rrsagent, make minutes
# [01:27] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/02-html-wg-minutes.html John_Boyer
# [01:28] * Parts: John_Boyer (boyerj@32.97.110.142)
# [01:28] <mjs> heycam: clearly both have a mapping to a Turing machine, but that's hardly non-trivial
# [01:29] <mjs> I don't know what counts as non-trivial
# [01:29] <heycam> non-trivial and useful then :)
# [01:29] <mjs> it's hard to think of a model that XForms and XForms Transitional both map to that Web Forms 2 doesn't
# [01:29] <heycam> and the most obvious one to my mind is a model of form fields, expressions, and so on
# [01:30] <mjs> what's the expression language model to which we can map both JavaScript and XPath?
# [01:30] <mjs> is there any model for that higher-level than "turing machine"?
# [01:30] <heycam> actually i take expressions back
# [01:30] <heycam> i think it's the data model that's the bit that neds consistency
# [01:31] <heycam> so, defining how a WF2.0 form maps to an xforms data model
# [01:31] <heycam> maybe with something like what mark birbeck was suggesting for xforms (being able to write forms without defining the model)
# [01:31] <heycam> (explicitly)
# [01:31] <mjs> it's easy to define that in the abstract
# [01:31] <mjs> the name of each field is the name, and the type for each is string
# [01:32] <Hixie> (in fact, wf2 does define that)
# [01:32] <mjs> (since HTML forms fields are not strongly typed)
# [01:32] <Hixie> (as the xml submission model)
# [01:32] <heycam> why not map type='number' to xs:number etc.?
# [01:32] * Joins: John_Boyer (boyerj@32.97.110.142)
# [01:32] <heycam> (or xs:whateverItIs?)
# [01:32] <John_Boyer> Hixie, your characterizations of me and what I want are slanderous
# [01:32] <John_Boyer> please stop doing that
# [01:33] <Hixie> hey John
# [01:33] <John_Boyer> If you would stop and actually read what I said,
# [01:33] <mjs> John_Boyer: maybe you could state clearly what you do want?
# [01:33] <mjs> cause I personally have been unable to determine that
# [01:33] <John_Boyer> Please read the logs
# [01:33] <Hixie> did you have any specific characterisations in mind?
# [01:33] <John_Boyer> just reading the minutes and I cannot believe the thigns you say about me when I am not around
# [01:33] <John_Boyer> your behavior is scandalous
# [01:33] <Hixie> i have no interest in misrepresenting you, i assure you any such misrepresentations are purely based on my misunderstanding your position
# [01:34] <Hixie> if you could cite what it is you think i misunderstand and correct me, that would be most helpful
# [01:34] <John_Boyer> What did you intend when you said "johnboyer does not care about architectural consistency" for example
# [01:36] <Hixie> is it not the case that you are interested more in having the actual xforms model in html5 rather than having something that is merely similar in an architectural sense?
# [01:36] <John_Boyer> or "that's not what he wants" (seemingly in response to "good faith"
# [01:36] <Hixie> by "that's not what he wants" i meant that you didn't want mere architectural consistency
# [01:37] <Hixie> am i wrong in this assumption?
# [01:38] <John_Boyer> Hmm. your actual quote is quite different
# [01:39] <Hixie> i assure you that the lines you have quoted were not intended to mean any more than what i have just now stated
# [01:39] <John_Boyer> I don't think the nascent work on "transitional" is reflective of any attempt to "force" an xforms model in html5, if by that you mean at the markup/lexical level
# [01:40] <John_Boyer> ok thanks
# [01:41] <John_Boyer> For starters, I am trying really hard NOT to get drawn into a rathole of technical fault-finding with WF2.
# [01:41] <Hixie> i must admit that it would be helpful if you could clearly state what your technical requirements for html5 are in terms of the forms capabitilities, as it hasn't been possible for me to understand your requirements from your e-mails and IRC discussions so far
# [01:41] <John_Boyer> The main reason for that is that I am trying not to do the work of the task force in order to justify what work the task force should be doing.
# [01:43] <John_Boyer> I have to chair a WG, edit a spec (that's 100% by itself), try to help get the right people together on a TF, try to help with nailing down what that TF will actually do, not to mention holding down a day job.
# [01:43] <John_Boyer> Lots of other people need to be doing this besides just me.
# [01:43] <John_Boyer> So grinding through WF2 for technical faults would be about as useful to me as grinding through XForms on the same mission.
# [01:44] <John_Boyer> But what I want is, roughly, this
# [01:44] <John_Boyer> 1) I want a tag set that means the same thing whether it is serialized as XML or not
# [01:45] <mjs> HTML Forms (serialized as HTML or XHTML) provides such a tag set
# [01:45] <John_Boyer> 2) I want a tag set that maps to data model constructs in the XForms architecture where appropriate
# [01:45] <mjs> so I'm guessing you have more requirements than that
# [01:45] <Hixie> please, mjs, allow John to finish his list of requirements
# [01:45] <mjs> ok
# [01:47] <John_Boyer> 3) I can see there is a desire to attach data model properties to UI controls; fine, so let the names of the UI controls suggest the data model...
# [01:47] <John_Boyer> and let the hierarchic structure of the UI suggest the structure of the data...
# [01:47] <John_Boyer> and let the properties defined on those controls suggest properties on the data.
# [01:49] <John_Boyer> 4) It should be possible to submit the suggested data as XML, and to indicate either receipt of a new replacement document or a new data
# [01:50] <mjs> is it ok if I write down these requirements and send them to the list when you are done stating them? (or you can do it yourself if you prefer)
# [01:50] <John_Boyer> 5) It should be really easy to grow or shrink "repeated" data (as expressed by repeated controls)
# [01:50] <John_Boyer> Yes, I am trying to just think of the basket of things off the cuff though; I had really hoped that the task force would nail all of this down.
# [01:51] <John_Boyer> so apologies in advance if I don't get it all...
# [01:51] * Joins: sbuluf (dggara@200.49.140.40)
# [01:51] <Hixie> Could you elaborate on your second requirement? I don't really understand what you mean by "data model constructs" or "the XForms architecture", or how to determine if it would be appropriate or not. Do you just mean the <model> feature?
# [01:52] <mjs> I'm hoping writing them down earlier can lead to refinement by HTML WG and Forms WG members even in advance of having an official Task Force
# [01:52] <John_Boyer> 6) it should be easy to receive prepop data for things that repeat and yet still have a way to add new "rows" that are empty
# [01:53] <John_Boyer> 7) It should be possible to delete until a repeating construct is empty and then be able to insert to get an empty one row "Table"
# [01:54] <John_Boyer> 8) It should be possible to express relevance, readonlyness, datatype, constraints on value, and calculated value
# [01:54] <John_Boyer> The last one is somewhat in answer to the question about #2
# [01:55] <Hixie> ah so your second requiremnt is more about the <bind> feature of XForms?
# [01:56] <John_Boyer> Sort of. I think it is not hard to set up attributes on the controls that "suggest" so-called binds for things like constraints or calculated values.
# [01:56] <John_Boyer> Would love to be able to say
# [01:56] <John_Boyer> <input name="lowpage" ...
# [01:56] <Zeros> WHy not just add a Bind() object for JS?
# [01:57] <John_Boyer> <input name="highpage" constraint="highpage >= lowpage" ...
# [01:58] <John_Boyer> The constraint *could* be implemented as a shorthand for some JS, or it *could* be implemented by creating an implicit xf model with an implicit xf bind that contains the given constraint as an expression
# [01:59] <Zeros> Are we talking about html forms or xforms?
# [01:59] <heycam> John_Boyer, do you think the syntax for the constraint needs to be identical for xforms and html5's forms?
# [01:59] <heycam> or can they have two different syntaxes that map to the same model-y thing?
# [02:00] <Hixie> John_Boyer: so as far as i can tell, web forms 2.0 as it currently stands addresses all of these requirements, except that there is no formal mapping to xforms (which seems to be what you are asking for in your second requirement, though i admit i'm not sure i understand exactly what you mean there)
# [02:00] <Hixie> John_Boyer: but it would be great if you could forward these requirements to the mailing list so that we can more carefully examine each one and see if they are indeed addressed.
# [02:01] <Hixie> John_Boyer: possibly i could give code samples for each one and/or point to the relevant parts of the specification.
# [02:01] <mjs> John_Boyer: if it turns out that WF2 already addresses most or all of your architectural consistency technical requirements, would you withdraw your Formal Objection to adopting it as a basis for review?
# [02:01] <heycam> John_Boyer, if this discussion is pre-empting the taskforce, then perhaps the taskforce can be created asap, so that these things can be discussed?
# [02:02] * heycam thinks this discussion of the last 10 minutes is the most useful of the whole "xforms vs web forms 2.0" argument
# [02:02] <Zeros> Hixie, where's the data binding between controls in XF2?
# [02:03] <John_Boyer> Have been corresponding with DanC about task force set up. Should be coming along soon.
# [02:03] <heycam> great
# [02:05] <mjs> heycam: me too!
# [02:06] <mjs> John_Boyer: are you willing to answer my question?
# [02:06] <mjs> "if it turns out that WF2 already addresses most or all of your architectural consistency technical requirements, would you withdraw your Formal Objection to adopting it as a basis for review?"
# [02:06] <John_Boyer> Sorry got distracted...
# [02:08] <mjs> are you less distracted now, or should I wait?
# [02:09] <John_Boyer> The problem with putting out such a mature spec so early in the process is that, regardless of front matter claiming things can change, it becomes increasingly difficult to do so.
# [02:09] <John_Boyer> I am sure there are quite a few things I didn't get to off the cuff
# [02:09] <Zeros> John_Boyer, one would hope that Hixie and hyatt would be open to changes
# [02:09] <Hixie> certainly personally i am more than willing to change the spec to meet concrete technical requirements and use cases
# [02:09] * Joins: hyatt (hyatt@17.255.99.92)
# [02:10] <Hixie> John_Boyer: indeed i was somewhat hoping that your list of requirements would include something WF2 _couldn't_ already do, so that I could go and change the spec and show you how eager I am to address your needs
# [02:10] <mjs> John_Boyer: regardless of how much work has gone into it, it would be entering the process as an immature spec, pre-Working Draft stage
# [02:11] <mjs> John_Boyer: also, what I'm asking you is about the requirements - if it meets most or all of them already, surely mutability is not a big issue
# [02:11] <mjs> John_Boyer: I actually haven't studied it enough to say right now if it does or not
# [02:11] <mjs> John_Boyer: also, if you remember other requirements, you could add them to the list
# [02:12] <mjs> John_Boyer: so modulo requirements you may not have realized off the cuff, if WF2 meets most or all of them, would you withdraw your Formal Objection, or would it still stand?
# [02:13] <John_Boyer> Yes, Maciej, this is the key issue. What is the statement of requirements and use cases that WF2 currently addresses?
# [02:13] <mjs> John_Boyer: does it matter to you what other requirements it may address besides yours?
# [02:14] <mjs> John_Boyer: if it addresses yours would you be satisfied?
# [02:14] <John_Boyer> What are the use cases/requirements that XForms addresses?
# [02:14] <John_Boyer> When the same requirement is being met, is there a reason to have it done by different syntax?
# [02:15] <John_Boyer> These are the things the task force is supposed to work out.
# [02:15] <mjs> Well, Web Forms 2 tries to satisfy the additional requirement of being compatible with handling existing HTML Forms, and of degrading gracefully in HTML4 user agents
# [02:15] <John_Boyer> I object not to WF2 (nor to XForms, to be clear). I only objected to a proposal that seemed to be preempting work that needs to be done.
# [02:15] <John_Boyer> by the task force.
# [02:15] <mjs> XForms syntax clearly does not satisfy these
# [02:16] <John_Boyer> agree
# [02:16] <mjs> I see the job of the Task Force as defining the requirements that express architectural consistency, and making sure that XForms and Web Forms 2 both satisfy those requirements
# [02:17] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [02:17] <mjs> I am pretty happy with your rough draft of the requirements, and I think we should evaluate WF2 against them to see if we can avoid blocking work on HTML until the Task Force defines them further
# [02:17] <John_Boyer> Well, I don't want to repeat that discussion. I obviously think the task force is responsible for forms.
# [02:18] <mjs> so your understanding of the charter is that the HTML Working Group can't define form features in the HTML specification?
# [02:18] <John_Boyer> The HTML WG members who join the task force are part of teh HTML WG who are defining the forms features in HTML.
# [02:18] <John_Boyer> So are the Forms WG members who join the same task force.
# [02:18] <Zeros> the xforms task force?
# [02:19] <hober> "are part of" or "are the part of"?
# [02:19] <mjs> is that symmetric? is the Forms WG also not allowed to define forms features in XForms outside the task force?
# [02:19] <John_Boyer> zeros: The joint forms task force
# [02:19] <Zeros> ah
# [02:20] <John_Boyer> hober: sinc ethe html wg members are on the task force AND are on the HTML WG, I didn't see how mjs got to the assertion that the HTML WG couldn't define forms features
# [02:20] <mjs> what I see in the HTML charter is "The HTML WG and the Forms Working Group will work together in this Task Force to ensure that the new HTML forms and the new XForms Transitional have architectural consistency and that document authors can transition between them"
# [02:20] <mjs> that says to me that the Forms Task Force is responsible for ensuring the consistency, not writing any specs
# [02:20] <hober> mjs++
# [02:21] <mjs> writing a spec might be one way to do that, but perhaps not the best way, compared to stating the requirements
# [02:21] <Zeros> So we have the xforms wg, the forms wg, and wf2 over at whatwg?
# [02:21] <John_Boyer> consistency to the point of doc authors being able to transition...
# [02:21] <Zeros> that's some incredible redundancy
# [02:21] <John_Boyer> Trying to reduce that !
# [02:21] <John_Boyer> Want ONE task force.
# [02:21] <mjs> right, I'm hoping sufficient consistency can be defined in the form of requirements
# [02:21] <John_Boyer> Come together to fix problem of trifurcation.
# [02:22] <mjs> John_Boyer: is the Forms WG holding off on all editing and review of XForms documents until the task force is formed?
# [02:22] <mjs> John_Boyer: you're really not answering any of my questions
# [02:22] <mjs> I'm not sure why, since they are pretty simple yes-or-no questions
# [02:23] <John_Boyer> Questions are coming from multiple people faster than I can type
# [02:23] <mjs> does anyone mind if I restate my 2 questions for John and then give him a chance to answer clearly?
# [02:23] * Joins: gavin_ (gavin@74.103.208.221)
# [02:23] <John_Boyer> mjs: The Forms WG is currently working on last call comments for XForms 1.1. The mods for HTML forms are part of XForms 1.2 and XFOrms transitional
# [02:24] <John_Boyer> we are holding off on all that until the "who" of it gets solved.
# [02:24] * Quits: hober (ted@66.162.32.234) (Quit: ERC Version 5.2 (IRC client for Emacs))
# [02:24] <John_Boyer> But we have other work to do in the meantime, just as theres lots to do on HTML besides forms I presume.
# [02:24] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [02:24] <mjs> John_Boyer: so you expect the HTML WG to hold off on all forms work until the Task Force is formed, but the XForms WG is not doing so
# [02:24] <John_Boyer> That was one, Maciej, what was the one I missed?
# [02:24] <mjs> John_Boyer: I don't think that is a reasonable expectation
# [02:25] <John_Boyer> XForms 1.1 entered last call before the new working groups were even chartered. It's old work.
# [02:25] <mjs> John_Boyer: my other question was, would your Formal Objection to adopting WF2 as a basis for review still stand, if it turned out that WF2 met most or all of your stated technical requirements (module ones you may have forgotten)
# [02:25] <John_Boyer> It's like the XFOrms 1.0 you already don't like.
# [02:26] <John_Boyer> I already answered that.
# [02:26] <Hixie> Web Forms 2 entered W3C WD status before the groups were chartered too, fwiw
# [02:26] <John_Boyer> I don't think so
# [02:26] <mjs> is your answer "yes" or "no" to that question?
# [02:26] <mjs> I didn't get that from your answer
# [02:26] <John_Boyer> mjs: right now my answer is I don't hink so.
# [02:26] <John_Boyer> s/hink/think
# [02:27] <Hixie> (http://www.w3.org/TR/web-forms-2/ was published on the REC track in August 2006)
# [02:27] <Hixie> (so it's "old work" just like XForms 1.1)
# [02:27] <John_Boyer> Yes, and that's what started the whole ball rolling on the new charters.
# [02:27] <mjs> John_Boyer: ok, if you have a Formal Objection that would not be satisfied through addressing the technical merits, we'll have to deal with it as appropriate
# [02:27] <John_Boyer> Our charter says that we will deliver XForms 1.1
# [02:28] <John_Boyer> mjs: you haven't satisfied the "technical merits"
# [02:28] <John_Boyer> because the technical merits concern the process
# [02:28] <John_Boyer> not WF2
# [02:28] <John_Boyer> please, how many times do I have to day that?
# [02:28] <John_Boyer> I don't object to WF2
# [02:28] <John_Boyer> I don't object to WF2
# [02:28] <John_Boyer> I don't object to WF2
# [02:28] <John_Boyer> I don't object to WF2
# [02:28] <John_Boyer> I don't object to WF2
# [02:28] <mjs> what do you object to, then?
# [02:29] <mjs> if you don't object to it, how can you object to adopting it as a basis for review?
# [02:29] <John_Boyer> That's not how I understood the question, so it's not how I answered it. That's also why I said "I don't think so" rather than "no"
# [02:30] <John_Boyer> You were here in the earlier conversation where I already went through all of this.
# [02:30] <mjs> John_Boyer: your vote says "no", that is what makes it a Formal Objection
# [02:30] <mjs> actually I wasn't here
# [02:30] <mjs> someone did point me to the logs
# [02:30] <John_Boyer> Oh, please see the minutes.
# [02:30] <John_Boyer> rrsagent, make minutes
# [02:30] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/03-html-wg-minutes.html John_Boyer
# [02:31] <mjs> I can't access that URL
# [02:31] <mjs> "We're sorry but the link you tried to access is forbidden."
# [02:31] <John_Boyer> rrsgagent, make log public
# [02:31] <John_Boyer> mjs: please see the minutes for yesterday...
# [02:31] <John_Boyer> they are already public
# [02:31] <John_Boyer> looks like the day flipped during this conversation
# [02:32] <mjs> where can I find the minutes for yesterday, the ones you linked appear to only cover our conversation just now
# [02:32] <John_Boyer> Use the same URL as above, only change 03 to 02
# [02:32] <Hixie> http://krijnhoetmer.nl/irc-logs/
# [02:32] <Hixie> has more complete IRC logs
# [02:32] <John_Boyer> Anyway gotta run for now...
# [02:32] <Zeros> the log from that bot is interesting
# [02:33] <Zeros> aside from the warnings at the bottom of the page
# [02:33] <John_Boyer> Would be great to start with empty document and look at *what* is being attempted.
# [02:34] <Zeros> with respect to what?
# [02:34] <mjs> I still don't understand what you object to, and what your proposed alternative is
# [02:34] <mjs> if you don't object to WF2, then I don't see why you would object to adopting it as a basis for review
# [02:34] <mjs> HTML WG reviewing it does not preclude Forms Task Force also reviewing it
# [02:34] <John_Boyer> making things work with old HTML is one requirement, but that shoudl have little bearing on what the "repeating" construct or the XML submission construct looks like, right?
# [02:35] <mjs> I don't think "start with an empty document" is a valid technical or process requirement
# [02:35] <John_Boyer> Start with the task force doing the work rather than preempting it with a solution in hand before the task force even starts?
# [02:36] <mjs> I don't think asking the HTML WG to stop work on some area is a valid process requirement either
# [02:36] <mjs> the task force is chartered to ensure architectural consistency, it has no charter to start from scratch on a new language
# [02:36] <mjs> that might be one way of achieving architectural consistency, but it is surely not required to achieve it
# [02:36] <John_Boyer> All I asked is that the HTML WG (or rather the HTML WG members on the forms task force) should consider WF2 and XForms as the starting point
# [02:36] <mjs> revising an existing language is another equally valid way
# [02:37] <Hixie> XForms was the starting point for WF2, for what it's worth
# [02:37] <Hixie> it was even originally called XForms Basic
# [02:37] <mjs> since XForms is syntactically incompatible with HTML Forms, I don't see how we can consider XForms as a starting point for an HTML spec
# [02:37] <Hixie> (the XForms WG complained so I changed it)
# [02:37] <John_Boyer> the wg already had a thing called XForms basic
# [02:38] <mjs> it would be like adopting PDF as a basis for review
# [02:38] <John_Boyer> can't understand why you didn't just join the working group and get the changes made to XForms?
# [02:38] <Hixie> sure. my point is just that XForms was already adopted as a starting point, that's how we got to WF2.
# [02:38] <John_Boyer> Why do things look so different then?
# [02:38] <John_Boyer> Maybe creating a bit of a rosetta stone would help.
# [02:38] <John_Boyer> The repeats don't look much like each other
# [02:38] <Hixie> well, we have to make it compatible with the proposed design principles -- graceful fallback, legacy content handling, etc
# [02:39] <Hixie> that necessarily constrains what the language can look like
# [02:39] <John_Boyer> and it doesn't make sense to adopt a different mechanism when you are already have to add to the language anyway
# [02:39] <mjs> it does make sense if the new mechanism is better suited to graceful degradation and compatible handling
# [02:40] <Hixie> it is quite possible to add to HTML without breaking legacy content handling, and without sacrificing graceful degradation in legacy UAs
# [02:40] <Hixie> but such additions are very constrained in what syntax they can use
# [02:40] <mjs> I have to head out
# [02:40] <John_Boyer> Hmm. OK, let me get this. Suppose you have a form that comes down the pipe with an empty "table", then the user presses a button that says "load my work from yeseterday"
# [02:41] <John_Boyer> then
# [02:41] <mjs> John_Boyer: thanks for having this conversation, it's by far the most useful XForms-related conversation I've ever had
# [02:41] <John_Boyer> down the pipe comes a blob of XML that represents the data the user worked on yesterday
# [02:41] <John_Boyer> how does the table get filled up?
# [02:41] <John_Boyer> with controls I mean?
# [02:42] <Hixie> in WF2, there is a method resetFromData() on the HTMLFormElement interface, to which you can pass a Document object (e.g. obtained through XMLHttpRequest)
# [02:42] <Hixie> this method, when invoked, casuse repetition blocks to be filled appropriately based on the data in that Document object
# [02:42] <Hixie> this is described here: http://www.whatwg.org/specs/web-forms/current-work/#seeding
# [02:42] <Hixie> and here: http://www.whatwg.org/specs/web-forms/current-work/#resetFromDataDOM
# [02:43] <mjs> John_Boyer: I'll probably send some email summarizing this discussion later tonight or tomorrow
# [02:43] * Quits: mjs (mjs@17.255.99.9) (Quit: mjs)
# [02:43] <John_Boyer> ok
# [02:44] <John_Boyer> I'm trying to imagine how that maps to just replacing the data and the table automatically regenerating itself because it is bound to the data that got replaced
# [02:45] <Hixie> well, "replacing the data" is the call to resetFromData() -- the table does indeed automatically regenerate itself as a result of that call
# [02:46] <John_Boyer> What if two tables are bound to parts of the same data?
# [02:46] <John_Boyer> do you have to reset them each manually?
# [02:47] <Hixie> the WF2 repetition model supports multiple sets of repetition blocks per instance document, and is actually independent of the <table> markup (you could apply it to <fieldset>s, <p>s, raw <input>s, anything)
# [02:47] <Hixie> just calling resetFromData() with the Document that contains the form's data will fill in all the relevant parts of that form
# [02:49] <John_Boyer> sorry, DanC and I are just working out details of task force call for participation
# [02:50] <John_Boyer> How does this play when you put a table inside a table?
# [02:51] <John_Boyer> If similar capabilities exist, I end up wondering why there are two such different tag sets
# [02:51] <John_Boyer> this is a net new feature
# [02:51] <John_Boyer> no old html 4 forms are going to contain this.
# [02:52] <Hixie> again, nested tables just work, assuming you declare them in the right order in the instance document
# [02:52] * Quits: hyatt (hyatt@17.255.99.92) (Quit: hyatt)
# [02:52] <John_Boyer> what does the data look like
# [02:52] <John_Boyer> when you submit it?
# [02:53] <Hixie> to answer your earlier query, the point is the web forms 2 syntax can be used such that with a legacy UA and server-side support, the exact same document will work -- that's why the syntax is different to xforms'
# [02:53] <Hixie> let's see
# [02:53] <Hixie> if you search for <formdata in the spec you'll find some examples
# [02:53] <Hixie> at the end of section 5.4
# [02:53] <John_Boyer> but xforms can also be delivered either to browser that understand it, or to todays browser with server-side support
# [02:54] <John_Boyer> so that doesn't seem to work as a justification
# [02:54] <Hixie> well with the repetition structures it's certainly true that the wf2 fallback isn't ideal
# [02:54] <John_Boyer> Yes, I suppose I could look at the specs, but really what I'd hoped for is that a task force would be formed to go off and do the work
# [02:55] <Hixie> with the other features, e.g. new controls, the fallback in wf2 doesn't require any server-side support at all
# [02:55] <John_Boyer> of pulling these two things together
# [02:55] <Hixie> i'd be very happy to participate in a task force that collected together the requirements for html5 forms
# [02:55] <John_Boyer> agree, xforms is also pretty much baked on the idea of "custom controls" too
# [02:55] <John_Boyer> it's not that hard actually
# [02:56] <Zeros> Hixie, speaking of wf2, the min/max attributes on <input type="file"> needs a requirement that the range cannot be smaller than 1
# [02:56] <John_Boyer> we could have used someone carryign the ball
# [02:56] <John_Boyer> and making it more a reality sooner
# [02:56] <Hixie> John_Boyer: i didn't say it was hard, i'm just saying that that's why the syntax is like it is, we were constrained by what html4 browsers supported.
# [02:56] <Hixie> (and still are)
# [02:57] <John_Boyer> why, the html4 browser won't understand the html5 behavior.
# [02:57] <Hixie> but it will degrade in a graceful way
# [02:57] <Hixie> for example, if you ask for a number:
# [02:57] <Hixie> <input type=number ...>
# [02:57] <John_Boyer> We have people today who deliver JS libraries that translate pure XForms into what today's browseres understand
# [02:57] <Hixie> the HTML5 UA will know it's a number field, and will support that
# [02:57] <Zeros> John_Boyer, that's not accessible
# [02:57] <Hixie> but the HTML4 UAs will still actually display a text field
# [02:58] <Zeros> xforms actually works nicely as a server side description format for transformation into HTML+JS using XSL though
# [02:58] <Hixie> so effectively, the html4 browser _does_ understand the html5 behaviour, though in a degraded way
# [02:58] <John_Boyer> zeros, wcag 2?
# [02:59] <John_Boyer> hixie, that seems to be true of wf2 and xforms, so is there another reason for diff
# [02:59] <John_Boyer> s/diff/diffs
# [02:59] <Zeros> John_Boyer, WCAG, 508, you name it.
# [02:59] <Hixie> John_Boyer: it isn't true of xforms -- an xform document doesn't show form controls at all in an html4 browser.
# [02:59] <Hixie> xforms document, rather
# [03:00] <John_Boyer> hixie, it sounds like wf2 is optimizing a use case that is not very useful
# [03:00] <John_Boyer> an xf document can show actual controls in an html4 browser in numerous ways
# [03:01] <Hixie> it's a requirement that the browser vendors have said they won't compromise on. I'm just working within the constraints of what the browser vendors require of HTML5.
# [03:01] <John_Boyer> I think we've had this conversation before
# [03:01] <Hixie> for example, visit this page in mozilla without the xforms plugin: http://www.mozilla.org/projects/xforms/samples/tax_form/TaxForm.xhtml
# [03:01] <Hixie> you don't see any form controls
# [03:01] <Hixie> but visit this WF2 form in that same browser: http://www.whatwg.org/demos/multiform-01/
# [03:02] <Hixie> and the form will actually work, even if it doesn't work as perfectly as it would in an HTML5 browser
# [03:02] <John_Boyer> I *know* we've had this conversation before.
# [03:03] <Hixie> that's quite possible. the requirements from browsers haven't changed since then.
# [03:03] <John_Boyer> The "XForm" is expressed with the xforms namespace
# [03:03] <John_Boyer> that's why the controls don't show
# [03:03] <Hixie> right
# [03:03] <Hixie> that's a problem
# [03:03] <John_Boyer> That has nothing to do with why your tag set differs
# [03:04] <John_Boyer> we've gone through a number of iterations already of how to provide xforms tags to html IN HTML namespace
# [03:04] <John_Boyer> that would satisfy the browser vendors
# [03:04] <John_Boyer> the controls would show up then
# [03:04] <John_Boyer> that's one of the bases of the so-called XForms transitional work
# [03:04] <Zeros> Isn't xforms xml?
# [03:05] <Hixie> if you change the namespace to XHTML's (ignoring for now that XHTML isn't HTML4), it still doesn't work: http://damowmow.com/temp/TaxForm.xhtml
# [03:05] <John_Boyer> XForms is currently serialized as XML
# [03:05] <Zeros> John_Boyer, If it was in a html document would it require the xml syntax?
# [03:05] <John_Boyer> but tags should mean the same thing whether you serialize as xml or not
# [03:05] <John_Boyer> no
# [03:05] <John_Boyer> this is why face to face meetings are needed
# [03:06] <Hixie> the <input> element in XForms has different processing requirements than the <input> element in HTML4, to the point where they cannot be implemented in the same UA
# [03:06] <John_Boyer> too bad we can't get 400 people in a room :-)
# [03:06] <Hixie> it is simply not true that <input> in XForms has legacy UA graceful degradation
# [03:06] <Zeros> the number isn't the problem
# [03:06] <Zeros> that's easy in a hotel
# [03:06] <Hixie> nor is it true that the <input> element in XForms supports legacy content
# [03:06] <Hixie> regardless of the namespace
# [03:08] <Hixie> sending the above document as text/html, i.e. as HTML, shows even more problems: http://damowmow.com/temp/TaxForm.html
# [03:09] <John_Boyer> I really really have to run now; I still don't see obstacles; I see opportunities for alignment. Would have been nicer to have had whatwg help doing that to xforms rather than now having to things that diverged that we have to pull together.
# [03:10] <John_Boyer> water under the bridge though
# [03:10] <John_Boyer> rrsagent, make minutes
# [03:10] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/03-html-wg-minutes.html John_Boyer
# [03:10] <Hixie> later
# [03:10] * Parts: John_Boyer (boyerj@32.97.110.142)
# [03:23] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [03:42] * Joins: mjs (mjs@17.255.99.9)
# [03:43] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [03:47] * Quits: mjs (mjs@17.255.99.9) (Ping timeout)
# [03:54] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [04:35] * Quits: zcorpan (zcorpan@84.216.43.182) (Ping timeout)
# [04:37] * Joins: zcorpan (zcorpan@84.216.43.182)
# [05:11] * Quits: zcorpan (zcorpan@84.216.43.182) (Ping timeout)
# [05:29] * Joins: hyatt (hyatt@24.6.91.161)
# [05:29] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
# [05:29] * Joins: zcorpan (zcorpan@84.216.43.182)
# [05:29] * Joins: hyatt (hyatt@24.6.91.161)
# [05:32] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [05:37] * Joins: gavin_ (gavin@74.103.208.221)
# [05:40] * Quits: hyatt (hyatt@24.6.91.161) (Ping timeout)
# [05:50] * Joins: hyatt (hyatt@24.6.91.161)
# [05:51] * Joins: htmlr (htmlr@203.158.34.70)
# [05:53] * Quits: zcorpan (zcorpan@84.216.43.182) (Ping timeout)
# [06:18] * marcos wishes he had pop-corn while reading the Hixie, Boyer, Mjs discussion on XForms... it's quite a comical drama :D
# [06:20] <heycam> but out of it came some useful discussion (for once!)
# [06:21] * hyatt has just been staying out of the forms stuff completely
# [06:27] <marcos> html/irish pub rules: no politics, no religion, no xforms discussions :P
# [06:27] <hyatt> xforms *is* a religion
# [06:27] <marcos> hehe
# [06:27] <hyatt> so is xml
# [06:27] <hyatt> strict html
# [06:27] <hyatt> puppies
# [06:27] <hyatt> and paris hilton.
# [06:28] <heycam> bow down before your well-formed canine overlords
# [06:28] <marcos> I do like puppies but not Paris'
# [06:28] <marcos> I wonder why Dominik Tomaszuk voted no both times in the survey
# [06:29] <marcos> maybe he wanted to be different
# [06:29] <hyatt> voted no to what
# [06:29] <heycam> she has puppies?
# [06:29] <marcos> she has one...
# [06:29] <marcos> I would not classify that dog as a dog though
# [06:29] * heycam discovers www.myspace.com/parishiltonpuppy
# [06:30] <marcos> The thing she carries in her handbag is more closely related to a rat
# [06:31] <marcos> omg, puppy mill!
# [06:33] <marcos> I didn't know about puppy mills... that's wrong and sad :(
# [06:42] * Quits: marcos (chatzilla@131.181.148.226) (Quit: ...and I'm gone.)
# [06:43] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [06:43] * schepers missed all the excitement... good conversation
# [06:46] * Quits: Preston (chatzilla@70.181.71.135) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007040314])
# [07:17] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [07:21] * Joins: mjs (mjs@64.81.48.145)
# [07:28] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [08:03] * Joins: John_Boyer (boyerj@216.210.106.249)
# [08:03] <John_Boyer> rrsagent, make minutes
# [08:03] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/03-html-wg-minutes.html John_Boyer
# [08:03] * Parts: John_Boyer (boyerj@216.210.106.249)
# [08:19] * Joins: loic (loic@90.41.2.216)
# [08:30] * Joins: hyatt (hyatt@24.6.91.161)
# [08:44] * Joins: tH (r@87.102.32.222)
# [08:47] * Quits: Zoffix (Zoffix@99.244.41.243) (Ping timeout)
# [08:57] * Joins: Zoffix (Zoffix@99.244.41.243)
# [09:00] * Joins: zdenko (zdenko@193.77.152.244)
# [09:09] <anne> some more stuff on www-archive
# [09:09] <anne> http://lists.w3.org/Archives/Public/www-archive/2007May/
# [09:10] * Quits: htmlr (htmlr@203.158.34.70) (Quit: htmlr)
# [09:28] * Joins: htmlr (htmlr@203.158.34.70)
# [09:33] * Joins: mw22 (chatzilla@84.41.169.151)
# [09:34] * Joins: mw22_ (chatzilla@84.41.169.151)
# [09:36] * Quits: mw22 (chatzilla@84.41.169.151) (Quit: Chatzilla 0.9.75-rdmsoft [XULRunner 1.8.0.4/2006060814])
# [09:37] * mw22_ is now known as mw22
# [09:43] <anne> heh, this Gareth Hay is really quite upset
# [09:44] <hyatt> yup!
# [09:49] <hyatt> i do not understand the people who want html5 to not be backwards compatible
# [09:54] <htmlr> http://www.intertwingly.net/blog/2007/05/02/Different-Drummer
# [09:55] <Dashiva> Maybe we should get someone from xhtml2 to come by and advertise for their WG. Seems many people would be happier there.
# [09:56] <schepers> or maybe we should take into account feedback?
# [09:58] <Dashiva> Sure, but when the feedback is "we should make a clone of xhtml2" it feels a bit empty
# [09:58] <schepers> if neither editor understands the perspective of those who don't want backwards compatibility, which is one of the strongest differences in the group, that doesn't seem representative
# [09:59] <anne> The HTML WG is about backwards compatibility schepers
# [09:59] <anne> I'm not sure how it can be about anything else
# [09:59] <anne> No backwards compatibility implies XHTML2
# [10:00] <schepers> I know you're not sure, anne, but I also don't think you're interested in bothering to resolve that uncertainty
# [10:00] <hsivonen> schepers: when people want mutually exclusive things the editors cannot please everyone at the same time
# [10:00] <hsivonen> schepers: that's why consensus doesn't work
# [10:00] <Dashiva> It's like they can't get their own bill (xhtml2) passed, so they want to tag it onto a popular bill (html5) instead
# [10:01] <anne> schepers, if you have a clear suggestion to resolve it, please bring it forward
# [10:01] <anne> schepers, I have been unable to do so
# [10:02] <schepers> "Consensus is a core value of W3C. Section 3.3 Consensus in the W3C process defines consensus as a "substantial number" in support of a proposal and no formal objections." (from the poll you all voted on)
# [10:02] <schepers> anne, I've been thinking a lot about it
# [10:02] <hsivonen> schepers: I know. I'm just saying it won't work here unless some people change their minds.
# [10:03] <Dashiva> I would hope it means _valid_ formal objections, or that FO implies it
# [10:03] <hsivonen> schepers: obviously, if people have mutually exclusive opinions, consensus requires some people to change their mind
# [10:05] <schepers> then give them a real reason to change their minds, or consider changing your own... so far on the list, there has been a lot of rhetoric on both sides, with the assumption that the other is wrong... there have been a few good posts by the WHATWG contingent, but most of them are either +1s or invectives hurled at the other side
# [10:06] <schepers> maybe you can make a stronger case why you're right, better than RTFM
# [10:06] <schepers> and do so politely
# [10:06] <schepers> (you=y'all)
# [10:06] <schepers> and the other side should do the same
# [10:07] <hsivonen> schepers: posts by the WHATWG regulars haven't been +1s but have cited reasons
# [10:07] <hsivonen> (in general)
# [10:07] <schepers> I stand by my comments
# [10:08] <anne> RTFM = Read The Fucking Mail?
# [10:08] <hyatt> schepers: i understand it, i just see no point
# [10:08] <schepers> RTFM as metaphor... the WHATWG spec
# [10:08] <hyatt> schepers: if html5 is not backwards compatible you'rej ust making xhtml2
# [10:08] <hyatt> schepers: so what is the point of html5 then
# [10:09] <hyatt> there's no reason not to move to xml if the syntax is not going to be backwards-compatible
# [10:09] <schepers> I've been thinking of how we can reach a compromise
# [10:09] <hsivonen> schepers: do you find it reasonable to suggest that participants to this WG read the parts of the WHATWG drafts they object to?
# [10:10] <schepers> hsivonen: I find it reasonable for people who want something to be bought into make a case for it
# [10:10] <anne> schepers, what arguments have been unconvincing so far?
# [10:10] <hsivonen> I read that as a "no"
# [10:10] * anne too
# [10:11] <schepers> you guys are just not listening to what I'm saying
# [10:11] <anne> No, we're reading it
# [10:11] <Dashiva> You aren't saying anything
# [10:11] <hyatt> it's really quite simple though. mozilla, opera and apple aren't going to implement an html5 that is not backwards compatible.
# [10:11] <schepers> ok, ignoring the peanut gallery for a minute, I'm trying to make a point...
# [10:12] <anne> what hyatt said
# [10:12] <hyatt> if the WG wants something browser vendors are actually willing to implement... well, they basically just have to give on this point.
# [10:12] <hyatt> is that unfair? maybe.
# [10:12] <hyatt> but that's how it is.
# [10:12] <anne> s/are actually/aren't actually/
# [10:13] <schepers> I think that what a lot of people (not all, but most) who are less concerned with backwards compatibility are saying is that they see the danger of a downward spiralling set of content that makes no attempt to improve
# [10:13] <hyatt> i just see a bunch of people with no knowledge of what it means to have to ship real products
# [10:13] <schepers> in fact, I think that may be the core issue
# [10:14] <hyatt> asking every browser vendor to build in two complete html rendering modes
# [10:14] <hsivonen> I also see a bunch of people who obviously haven't shipped Web software
# [10:14] <hyatt> is insane
# [10:14] <hyatt> it's absolutely batshit insane
# [10:14] * Joins: marcos (chatzilla@131.181.148.226)
# [10:14] <anne> btw, the charter says: "A serialized form of such a language using a defined, non-XML syntax compatible with the 'classic HTML' parsers of existing Web browsers."
# [10:14] <hyatt> this isn't like quirks vs. strict
# [10:14] <Dashiva> I see people saying "It says here browsers have to support <center>, that means people will use it" without considering the fact that browsers will still support it if the spec leaves it out, so the end result is identical
# [10:14] <anne> note "existing Web browsers"
# [10:15] <schepers> I understand that the WHATWG spec makes a difference between what is required for authoring and for implementations
# [10:15] <hyatt> yeah, which i think is the reasonable line to draw
# [10:15] <hyatt> but asking browser vendors to build a completely new rendering mode
# [10:15] <hyatt> that parses completely differently
# [10:16] <schepers> but it doesn't provide an incentive to author valid, well-formed content
# [10:16] <hyatt> would really create a mess out of webkit's current html parser
# [10:16] <hyatt> schepers: well (and here's where i'm really going to display my heresy)
# [10:16] <schepers> maybe a good compromise would be to find a way to encourage valid, well-formed content
# [10:16] <hyatt> i don't think valid well-formed content matters
# [10:17] <hyatt> to your average person
# [10:17] * Dashiva recalls holy/unholy/enemy to all mankind replacements
# [10:17] <hyatt> they just want to cut/paste some code in, and have it work
# [10:17] <hyatt> if they miss a " here or a > there, who cares
# [10:17] <hyatt> it's not the end of the world
# [10:17] <hyatt> as long as everyone handles the error thesame way
# [10:17] <hyatt> that's HTML
# [10:17] <hyatt> if you want draconian, go with XML
# [10:18] <hyatt> you have the best of both worlds right now basically
# [10:18] <hyatt> you can pick the path that works for you
# [10:18] <Dashiva> I think part of the issue is that they want to pick for everyone else too
# [10:18] <schepers> I think I'll type this up in a proposal instead, none of you seem to be listening... I'm talking about a way to satisfy multiple viewpoints here, not *only* to reach a technical solution (of which there are many)
# [10:19] <hyatt> what is your proposal?
# [10:19] <schepers> I'll send it via email, I'm losing patience here
# [10:19] <hyatt> i think the spec can encourage valid well-formed content by stating that tags are bad practice
# [10:19] <hyatt> or by saying that something is not valid
# [10:19] <anne> there are not many technical solutions to the parsing problem
# [10:19] <schepers> night
# [10:20] <anne> the WHATWG people mentioned that more than once on the mailing list already
# [10:20] <anne> simply ignored
# [10:20] <hyatt> i guess what drives me really crazy is that this isn't really even about the language design
# [10:20] <hyatt> this is just about people wanting to force browser vendors to render with draconian error handling
# [10:21] <anne> (note that even for XML you're not required to show an error message)
# [10:21] <hyatt> there's also the problem that i don't want any versioning in webkit for html5
# [10:21] <anne> (you're allowed to render up to where it went wrong)
# [10:21] <hyatt> i don't want to have to put a doctype at the top of my file just to use <video>
# [10:21] <hyatt> or to use a new web form control
# [10:21] <hyatt> the reality is that we're all going to implement this years before msft
# [10:22] <hyatt> and while we're building it, it is simply practical to allow the new features to work from any html file
# [10:24] <schepers> RRSAgent, make minutes
# [10:24] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/03-html-wg-minutes.html schepers
# [10:24] <schepers> nope...
# [10:26] * Quits: marcos (chatzilla@131.181.148.226) (Connection reset by peer)
# [10:27] <hsivonen> conformance is nowhere near as important as the people who want browsers to give incentive by being Draconian make it appear
# [10:27] <hsivonen> and I'm the conformance checking guy
# [10:28] * Quits: MrNaz (Naz@203.214.95.166) (Quit: Leaving)
# [10:28] <hsivonen> document conformance that is
# [10:28] <hsivonen> given the legacy Web that we have
# [10:36] <hyatt> i think html5 needs to be able to creep virally into existing documents
# [10:37] <hyatt> stuff like <video> needs to be able to sneak in without forcing an author to redesign the entire surrounding page
# [10:37] <anne> anything else would be a pain to implement too
# [10:37] <anne> certainly not worth the cost
# [10:38] <anne> especially given that the benefits are not really clear
# [10:38] <sbuluf> david, but isn't the case that microsoft decides?
# [10:39] <schepers> so, hyatt, before I hit the sack... how does your perspective differ from Hixie's?
# [10:40] <hyatt> in which area?
# [10:40] <hyatt> my perspective on versioning was pretty different
# [10:40] <hyatt> more in line with chris wilson's
# [10:41] <sbuluf> david, if they do not implement something, or don't do it for years...then would people use it?
# [10:41] <hyatt> if you mean on the topic of html5 backwards compat and such though i think you'll find that all browser vendors are in violent agreement
# [10:41] <schepers> you agree with him on wf2, too, right?
# [10:41] <hyatt> hmm?
# [10:41] <hyatt> what about wf2?
# [10:42] <schepers> I thought I saw you say earlier that you also wanted to adopt wf2 pretty much unchanged, is that right?
# [10:42] <hyatt> do you mean the whole xforms vs. wf2 cage match?
# [10:42] <schepers> right
# [10:42] <hyatt> no i don't think my perspective is the same
# [10:43] <hyatt> i was on the xforms wg for a while
# [10:43] <hyatt> when i worked at netscape
# [10:44] <schepers> that doesn't say much about your current perspective
# [10:44] <schepers> Hixie claims to really like XForms, too, for that matter
# [10:44] <hyatt> my current perspective is that i would actually need to review both specs again more closely
# [10:44] <schepers> (I'm not disputing that claim)
# [10:44] <hyatt> i haven't commented in that debate at all
# [10:44] <schepers> that's why I asked
# [10:44] <hyatt> mainly because i need to be a bit better informed
# [10:45] <schepers> my point in asking for multiple editors was to account for different perspectives, and I'm trying to scope out the breadth of the perspectives here
# [10:45] <hyatt> i think i'd put it this way then:
# [10:46] <hyatt> if xforms was the republican party
# [10:46] <hyatt> and web forms was the democratic party
# [10:46] <hyatt> i'd be a moderate sitting right in the middle
# [10:46] <hyatt> :)
# [10:46] <hyatt> it's not an area i feel very strongly about
# [10:47] <hyatt> i.e., if more xforms features crept into wf2 that would not bother me
# [10:47] <schepers> but neither would you promote it?
# [10:47] <hyatt> xforms has plenty of advocates. i don't think i need to
# [10:47] <hyatt> sebastian, boyer, raggett, t.v. raman
# [10:48] <hyatt> xforms is well-represented here.
# [10:48] <hyatt> i'd try to be impartial is what i'm saying
# [10:48] * Joins: Lachy (Lachlan@124.168.27.56)
# [10:48] * anne mumbles something about doing something productive as opposed to worrying about the editors
# [10:48] * schepers invites anne to go do that then
# [10:48] * anne isn't worrying
# [10:49] <hyatt> schepers: i try to be very impartial
# [10:49] * schepers is
# [10:49] <hyatt> but i can't help but have strong opinions on the backwards compat issue
# [10:50] <hyatt> since from a purely technical perspective that would be hellish to implement
# [10:50] <hyatt> i'm sure too we'd get bugs where people put that doctype at the top of the file and WinIE renders it like html4
# [10:50] <hyatt> and we'd break
# [10:50] <hyatt> because somebody got confused and thought they should put it up there
# [10:51] <anne> Editors are not the chairs, nor can they make descisions the majority of the group will disagree with
# [10:51] <anne> They're just doing all the hard work while you read e-mail, or something
# [10:52] <hyatt> but yes, i'm not an ian hickson clone
# [10:52] <hyatt> i have my own opinions
# [10:52] <hyatt> :)
# [10:52] <schepers> I don't doubt that
# [10:52] <hyatt> heck maciej and i got into a nice little argument on the list about versioning
# [10:52] <hyatt> and we work for the same company :)
# [10:53] <hyatt> i have really only seen two big "debates" raging on this list so far
# [10:53] <hyatt> and they basically boil down to xforms vs. wf2
# [10:53] <hyatt> and xhtml vs. html
# [10:53] <hyatt> it is hard for any browser vendor to come down on the side of xhtml or compatibility breaks
# [10:54] <hyatt> because we have to shoulder that cost
# [10:54] <sbuluf> the cost of what? lawsuits?
# [10:55] <hyatt> no implementation
# [10:55] <schepers> development, I'd guess
# [10:55] <hyatt> having to create a brand new html parser/tokenizer
# [10:55] <hyatt> being draconian is not something we could share with the existing code
# [10:55] <hyatt> people have no idea what a nightmare a real html parser/tokenizer is
# [10:56] <hyatt> (or for that matter what a real css parser has to deal with)
# [10:56] <schepers> anne, didn't you write one in an afternoon?
# [10:56] <sbuluf> isn't a strict one easier?
# [10:56] * Joins: ROBOd (robod@86.34.246.154)
# [10:56] <hyatt> sbuluf: to some degree yes
# [10:57] <hyatt> there are lots of obscure edges though
# [10:57] <hyatt> document.write makes things very compliated
# [10:57] <sbuluf> what percentage would you say (roughly)?
# [10:57] <hyatt> since scripts can document.write more elements and other scripts
# [10:57] <hyatt> and so on
# [10:58] <anne> schepers, our HTML parser took a few weeks (though not fulltime development at all)
# [10:58] <hyatt> i'm not sure anyone has ever really specified the exact "correct" behavior there either
# [10:58] <hyatt> a few weeks to write followed by a million little bug fixes presumably
# [10:58] <anne> schepers, it's not complete and doesn't do all the tricky bits a browser would have to do (such as script execution and input stream injection)
# [10:58] <hyatt> :)
# [10:58] <hyatt> script execution is huge
# [10:59] <hyatt> sbuluf: i think one of the problems here is that html is so poorly specified that it's hard to even know when you're doing something "invalid"
# [10:59] <anne> yes, we're still fixing bugs :)
# [10:59] <schepers> hyatt: I don't understand your stance on versioning, if you don't want different rendering modes
# [10:59] <hyatt> in a way that's how the whatwg stuff came about
# [10:59] <hyatt> to try to actually figure out what the behavior is supposed to be
# [10:59] <hyatt> schepers: my stance was that the spec should not dictate rendering modes
# [10:59] <hyatt> other than to say that the doctype would mean you are an html5 document
# [11:00] <hyatt> like the spec would say "this doctype identifies html5"
# [11:00] <sbuluf> david, but i was asking what percentage a strict parser would be, compared to a non strict one. or am i missing something?
# [11:00] * Joins: MrNaz (Naz@203.214.95.166)
# [11:00] <hyatt> but it would not say "if that doctype is not there, user agents can't treat the doc as html5"
# [11:00] <hyatt> sbuluf: i'm saying i can't even tell you because often we don't even know which parts are "strict"
# [11:00] <hyatt> nobody has even defined what a strict parser would be
# [11:01] <sbuluf> david, in say xhtl?
# [11:01] <hyatt> could we be strict about open/close tags, balanced quotes, etc.?
# [11:01] <hyatt> yeah pretty easily
# [11:01] <schepers> isn't the point of the WHATWG work that it shouldn't matter what "version" of HTML is... they all render the same?
# [11:01] <hyatt> schepers: not quite
# [11:01] <anne> sbuluf, there's not much difference in my experience
# [11:01] <hyatt> the point is that html5 should degrade gracefully in browsers that can't handle it
# [11:01] <hyatt> it can do that even with a subset of the elements if well defined
# [11:01] <sbuluf> anne, thanks.
# [11:02] <anne> sbuluf, error handling in tokenizing / parsing doesn't actually require extra code
# [11:02] <hyatt> residual style does
# [11:02] <anne> yes
# [11:02] <hyatt> that's the big error handling problem
# [11:02] <anne> that's the exception, but you wouldn't have to do that for XML with error handling
# [11:02] <hyatt> right
# [11:02] <sbuluf> residual atyle?
# [11:02] <sbuluf> (david, thank you too, btw)
# [11:03] <hyatt> http://ln.hixie.ch/?start=1037910467&count=1
# [11:03] <hyatt> the "tag soup" problem
# [11:03] <schepers> but you're also advocating bleeding video (presumably other elements) into other (non HTML5.0) documents.. so how does a version matter?
# [11:03] <hyatt> schepers: i have no idea if this is part of the html4 spec or not, i'd have to go research
# [11:03] <hyatt> but basically existing browsers all parse tags they don't understand
# [11:03] <hyatt> and still put them in the document tree
# [11:04] <schepers> sure
# [11:04] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [11:04] <hyatt> so if you design the new elements to degrade
# [11:04] <hyatt> you can use html5 elements safely
# [11:04] <hyatt> but yes, i as an alternative browser vendor, do not want to have an html5 mode
# [11:05] <anne> the think the point is that he's ok with browsers having an html5 mode and that the spec should not forbid that
# [11:05] <hyatt> right
# [11:05] <hyatt> i think it's totally ok if a browser *does* decide they won't render html5 unless the doctype is there
# [11:05] <schepers> I get that, but I don't understand what version="5.0" would *do* in your scenario...
# [11:05] <hyatt> some people were trying to say that a browser should not do that
# [11:05] <schepers> ahhhhh
# [11:05] <schepers> ok
# [11:05] <hyatt> i basically was defending microsoft's position
# [11:06] <hyatt> because i do have a funny story about that
# [11:06] <hyatt> safari 2 introduced a custom form control
# [11:06] <hyatt> to do apple's search field
# [11:06] <hyatt> the rounded one with the magnifying glass
# [11:06] <hyatt> we used <input type=search>
# [11:06] <hyatt> and were very proud of ourselves because it would degrade to text fields in other browsers
# [11:06] <hyatt> until of course we hit a real-world web site that accidentally said type=search instead of class=search
# [11:07] <hyatt> so adding new attributes/elements to the language can potentially break things
# [11:07] <hyatt> so i am very sympathetic to microsoft's position
# [11:07] <hyatt> and think people were being pretty naive to think that a vendor as constrained as they are by backwards compat could just dump these new tags/attributes/features into their existing html docs
# [11:08] <hyatt> if msft want to opt-in to html5 then that is their right
# [11:08] <hyatt> wans
# [11:08] <hyatt> argh
# [11:08] <hyatt> wants
# [11:08] <hyatt> can't type.
# [11:08] <anne> http://diveintomark.org/archives/2007/05/02/silly-season
# [11:08] <schepers> ok, that clears it up, thanks
# [11:08] <hyatt> anne: i saw that
# [11:09] * anne is laughing for real
# [11:09] <hyatt> schepers: hixie and mjs were basically (i think) arguing against versioning at all
# [11:09] <Lachy> would it have really been a problem if an author accidentially used type=search, instead of class=search?
# [11:09] <hyatt> Lachy: it looked pretty ugly
# [11:09] <hyatt> :)
# [11:09] <hyatt> but yes, it was a minor league misrendering
# [11:09] <hyatt> you could imagine a more dramatic one
# [11:09] <hyatt> the sad reality is sites invent tag names all the time
# [11:09] <hyatt> and use them as delimiters and placeholders
# [11:10] <hyatt> but the new features are not where msft would have to worry
# [11:10] <hyatt> it's stuff like changing their parsing model to be like web apps
# [11:10] <hyatt> if they solved the residual style / tag soup problem as per the spec
# [11:10] <hyatt> then sites would break guaranteed
# [11:10] <Lachy> how?
# [11:11] <hyatt> sites rely on IE's precise error recovery
# [11:11] <hyatt> it's sad but true
# [11:11] <hyatt> we have lots of bugs on this still
# [11:11] <Lachy> I just can't see how any site could rely on a non-tree structure
# [11:11] <hyatt> it's sad
# [11:11] <hyatt> pathetic even
# [11:12] <hyatt> sites pathologically nest without knowing it
# [11:12] <hyatt> the web apps spec encourages pathological nesting in certain scenarios
# [11:12] <schepers> mashups get even worse
# [11:12] <hyatt> and the residual style algorithm in the web apps spec can turn into O(n^2) in the depth of nesting and blow out
# [11:12] <Philip`> Maybe they're more likely to rely on e.g. "<unknown>text</unknown>" creating three nodes at the same level instead of making a useful nested structure
# [11:12] <Lachy> well, making any changes is a tradeoff. You can never guarantee that nothing will break, but freezing bugs like IE is going to do, is far more harmful
# [11:12] <anne> "@jkl: Wow, I totally missed the “eventually Linux” line from JD’s comment. Eventually Linux. That’s priceless. As an AMD64 Linux user, let me be the first (well, I guess the second) to spit a big fat raspberry towards Adobe’s idea of “eventually Linux.”"
# [11:12] <anne> comments are priceless too
# [11:13] <hyatt> i'm just saying, dictating to a vendor that they have to change their existing behavior even if it breaks their own products and customers' web sites is not fair to that vendor
# [11:14] <hyatt> we have things in the webkit engine we couldn't change
# [11:14] <hyatt> fortunately we're much less constrained
# [11:15] <hyatt> people also forget that in the case of webkit and trident
# [11:15] <sbuluf> i thought microsoft given reason, however, was not cost of implementing, but lawsuits
# [11:15] <hyatt> we are used for many apps on the system
# [11:15] <hyatt> and changes don't just break the web
# [11:15] <hyatt> they can break apps in your os
# [11:15] <hyatt> that's a big deal
# [11:16] <hyatt> for example for webkit, the behavior of css2.1's inline-block is actually hard for us to change
# [11:16] <hyatt> because it's so heavily used in OS X
# [11:16] <hyatt> even though it's non-existent on the Web
# [11:16] <hyatt> so we're even constrained in crazy ways
# [11:16] <hyatt> fix a bug in display:compact, break XCode, wtf.
# [11:17] <hyatt> basically i just don't think the spec should dictate to the vendor how they should opt in to html5
# [11:18] * xover fails to understand...
# [11:19] <xover> Your arguments seem to be in the opposite direction of your conclusion?
# [11:19] * xover double checks that his expresso was not from the "decaf" bin...
# [11:20] <hyatt> my argument is that IE should be allowed to opt in to HTML5 via a doctype
# [11:21] <hyatt> and they should be free to ignore HTML5 tags/features if that doctype isn't there
# [11:21] <Lachy> yeah, I'm ok with them opting in with the DOCTYPE
# [11:21] <hyatt> or via some rules they define
# [11:21] <Lachy> it's not ideal, but I can live with it
# [11:21] <hyatt> i don't plan to do that with webkit
# [11:21] <hyatt> we'll just happily support the html5 features in all html
# [11:21] <xover> Oh, you mean the opt-in should be specified, but not mandatory? i.e. it's a MAY not a SHOULD or MUST?
# [11:21] <Lachy> but I object to the very likely possibility of them freezing some bug state for <!DOCTYPE html> and then requiring a UA specific opt-in after that, for all time
# [11:21] <hyatt> yeah exactly
# [11:22] <hyatt> Lachy: i think that would suck yes
# [11:22] <xover> AH, that makes sense then. Sorry to be so dense. :-)
# [11:22] <hyatt> Lachy: but in the end there's nothing the WG can do about that
# [11:22] <hyatt> xover: np :)
# [11:22] <hyatt> Lachy: it's a moot point since we'll all be writing XAML for silverlight in 5 years anyway
# [11:22] <hyatt> ;)
# [11:22] <Lachy> I've tried to negotiate with Chris to use optional opt-outs for <!DOCTYPE html>, but Chris didn't seem very enthusiastic about them
# [11:23] <hyatt> the safest thing for them is for all existing web pages to render as before
# [11:24] <hyatt> it's an extremely conservative position, but with 80% market share and a whole OS that uses their engine everywhere, it's understandable
# [11:24] <xover> But isn't the logical consequence that the situation for HTML5-6 will be much the same, at this level, as for HTML4-5 making similar future opt-ins acceptable (by your logic above)?
# [11:24] <xover> And doesn't it then follow that you actually need explicit versioning that can distinguish e.g. 4 from 5 from 6?
# [11:24] <hyatt> xover: well, ignoring the details of error recovery and parsing and stuff like that
# [11:24] <hyatt> the new tags/features are designed to degrade gracefully anyway
# [11:25] <hyatt> and specifically tested in WInIE to make sure they do so
# [11:25] <hyatt> this is the spec's way to deal with this problem somewhat
# [11:25] <hyatt> xover: but yes 6 may need an opt-in from msft too
# [11:25] * Joins: Sander (svl@80.60.87.115)
# [11:25] <hyatt> that's why i argued that we should say "5.0"
# [11:25] <hyatt> and be clear about it
# [11:25] <hyatt> in case we do have a 5.1 and msft needs to opt in
# [11:25] <hyatt> etc.
# [11:26] <Lachy> 6 shouldn't require an opt-in, because the parsing requirements shouldn't be changed at all, except to handle the new elements
# [11:26] <xover> Ok, but do I then understand that you are in favor of versionning? Or would that be to put your position too simply?
# [11:26] <Lachy> and they mostly want the opt-in to work around the CSS and DOM limitations anyway
# [11:27] * xover misses Tasman, btw...
# [11:28] <hyatt> yeah it's funny, css/dom/js all create much bigger headaches
# [11:28] <hyatt> html is actually pretty minor league compared to those
# [11:29] <sbuluf> even considering tag soup?
# [11:30] <Lachy> yes, it's the CSS issues that can significantly break a sites rendering
# [11:30] <xover> hyatt: "No comment" on my questions above (inbetween Lachy)?
# [11:31] <sbuluf> i see.
# [11:31] <anne> sbuluf, parsing is not big of an issue
# [11:31] <anne> when people talk about "tag soup" they don't really talk about parsing I think
# [11:31] * xover is asking hyatt-the-person, not the $company representative or similar officiousness btw...
# [11:31] <anne> they mean rendering differences
# [11:31] <anne> because that's what they see
# [11:32] <anne> and rendering differences is CSS
# [11:32] <sbuluf> anne, i think i see, thanks.
# [11:33] <hyatt> which question?
# [11:33] * anne ponders about CSS5
# [11:34] <xover> «Ok, but do I then understand that you are in favor of versionning? Or would that be to put your position too simply?»
# [11:34] * sbuluf ponders too
# [11:34] <hyatt> i am in favor of identifying the version
# [11:34] <hyatt> so that someone who wants to do something with it can
# [11:34] <hyatt> so, yes, i guess you'd say i'm in favor of versioning.
# [11:34] <sbuluf> (unless that third S was not a typo9
# [11:34] * anne would not be against an optional meaningless to most UAs version= attribute
# [11:35] <xover> Hmm. Thank you.
# [11:35] <Philip`> sbuluf: (That was a 5, not a third S)
# [11:35] <xover> On a side note, I actually find that quite reassuring.
# [11:36] <sbuluf> philip, oops! (b/w small old monitor here, thanks.)
# [11:37] <hyatt> schepers: but anyway my long-winded point was that i don't always agree with hixie :)
# [11:38] <xover> Heresy!
# [11:40] <sbuluf> i wonder if peple who developed css really thought what they were doing. perhaps they did. but perhaps they added stuff happily, without thinking of unintended consequesnces
# [11:40] <sbuluf> probably ignorance on my part
# [12:03] * Joins: AGraf|mb (AlexanderG@213.47.199.86)
# [12:13] <Lachy> lol, another no vote: "I would prefer 5.01"
# [12:18] <Dashiva> That's a valid technical argument... I think...
# [12:18] <Lachy> there's no justification, it's just based on personal preference
# [12:18] <Lachy> it's not a technical argument at all
# [12:19] <Dashiva> Maybe it's to put a w3c stamp on the version number, since whatwg stole the plain 5? :)
# [12:20] <Lachy> the WHATWG didn't steal HTML5, ti's what the community started widely using, and so it was adopted
# [12:21] <hyatt> no vote where
# [12:21] <Lachy> http://www.w3.org/2002/09/wbs/40318/htmlbg/results
# [12:21] <hyatt> is there some voting page somewhere i should be looking at? :)
# [12:21] <hyatt> 82 to 2!
# [12:21] <hyatt> hahahaha
# [12:21] <hyatt> that is what i call consensus
# [12:21] <Dashiva> Has anyone tried contacting the guy who put no without justification?
# [12:22] <Lachy> one of them is Boyer who cites bogus reasons, and the other has no justification
# [12:22] <Lachy> don't know
# [12:22] <Lachy> probably not
# [12:23] <Lachy> but since providing justification was a requirement, his vote will be ignored completely
# [12:23] <anne> John Boyer was contacted, www-archive
# [12:23] <hyatt> hahah on the question of whether hixie and i should be editors
# [12:24] <hyatt> "Would prefer just Hixie, but this appears to be the next best thing.
# [12:24] <hyatt> "
# [12:24] * hyatt cries
# [12:24] * hyatt takes his ball and goes home.
# [12:24] * Dashiva doesn't even have a ball to take home
# [12:24] <hyatt> " The only problem I have is that what Dave says through email is so often so very unclear, due to his bad quoting style (typically quoting entire messages, preceding them with a single sentence)."
# [12:25] <sbuluf> i think it should be html 5.2, for historical reasons
# [12:25] <hyatt> i wonder if that is my mailer?
# [12:25] <hyatt> yeah i guess it is
# [12:25] <hyatt> mail.app puts your caret at the top
# [12:25] <hyatt> lots of other apps put the caret at the bottom
# [12:25] <Lachy> yeah, hyatt, don't top post!
# [12:25] <Dashiva> Bad app!
# [12:25] <hyatt> i assume that is what he means
# [12:26] <hyatt> i also write responses in like 5 mins and don't proofread them
# [12:26] <hyatt> which i guess is bad
# [12:26] <Dashiva> Also that your post is separated from the quoted context
# [12:26] <hyatt> but otherwise i'd never get anything sent
# [12:26] * anne has that too
# [12:26] <Dashiva> Non-conformant English will not be displayed
# [12:28] <hyatt> lol
# [12:28] * hyatt usually writes some code, then switches to his email
# [12:28] <hyatt> then sees something to respond to
# [12:28] <hyatt> dashes off a response
# [12:29] <hyatt> then resumes coding
# [12:29] * anne wonders if hyatt is still UTC-8
# [12:29] <hyatt> maciej gives much better responses than i do
# [12:29] <hyatt> he actually sits there and writes them all up
# [12:30] <hyatt> but then again it's consuming like his whole day!
# [12:30] <hyatt> my poorly-constructed ramblings have their place. :)
# [12:30] <anne> it's called "manager" :)
# [12:31] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [12:34] * anne wonders why people think modular specs are so much better
# [12:34] * anne hasn't seen a single successful modular spec
# [12:36] <Lachy> I really don't understand how a spec that is split by determining what each conformance criteria applies to, could be useful in anyway, whatsoever
# [12:36] <Lachy> They seem to be jumping to a solution, without actually clearly defining what the problem is
# [12:37] <Lachy> though I suspect the real problem is basicially "I don't understand it, because I haven't read it, so I want it split up so that I only have to read the stuff that applies to me"
# [12:38] <anne> maybe they're thinking in popular software paradigms
# [12:38] <Lachy> like what?
# [12:38] <hyatt> css3 is modular
# [12:38] <anne> modular approaches
# [12:38] <hyatt> look how thats turned out
# [12:38] <hyatt> kind of a mixed bag
# [12:38] <anne> hyatt, yeah, case in point :)
# [12:38] <anne> XHTML Modularization would be another one
# [12:38] <Lachy> CSS3 is at least split by the features, not conformance criteria
# [12:38] <hyatt> but a lot of that has to do with the css wg focusing so much on css2.1
# [12:39] <anne> you basically need a few people to do a lot of work
# [12:39] <anne> otherwise it will never happen properly
# [12:40] <hyatt> we've nearly fully implemented css3 background/border
# [12:41] <hyatt> would love to see that move forward
# [12:41] <Lachy> awesome
# [12:41] <hyatt> i think the only properties we haven't done
# [12:41] <hyatt> are the background-break, border-break ones
# [12:41] <Lachy> have any other UAs implemented it?
# [12:41] <Lachy> or started?
# [12:41] <hyatt> but we've done multiple backgrounds, border-radius, box-shadow, background-origin, background-clip, and background-size
# [12:42] <anne> border-image too
# [12:42] <anne> right?
# [12:42] <hyatt> yeah we've done border-image too
# [12:42] * anne Opera will be doing some Selectors love for the next release
# [12:42] * anne isn't sure why he /me'd that
# [12:42] <hyatt> yeah i guess we should beef up selectors
# [12:43] <hyatt> i'm so anti-selector-proliferation
# [12:43] <hyatt> since i find so many of the new ones to be kind of questionable
# [12:43] <hyatt> i hate selectors that can't resolve properly on a forward incremental parse
# [12:43] <hyatt> like :last-child
# [12:44] <hyatt> you risk showing content in the wrong state if the page loads incrementally
# [12:44] <Lachy> yeah, how do you work around that?
# [12:45] <hyatt> you don't
# [12:45] <anne> the only workaround is not doing progressive rendering at all, which is silly
# [12:45] <hyatt> you just hope you're not on one of those unlucky boundaries when you decide to paint :)
# [12:45] <anne> but :last-child is useful
# [12:46] <hyatt> sure
# [12:46] <hyatt> i'm just grousing
# [12:46] <hyatt> our engine resolves style as it goes
# [12:46] <hyatt> so this is a weird case where you have to guess wrong and then backtrack
# [12:46] <anne> if :matches($ > foo) or whatever the latest proposal is goes in we'll have bigger issues
# [12:46] <hyatt> is that the parent selector?
# [12:47] <anne> yeah
# [12:47] <hyatt> yeah no way
# [12:47] * Parts: AGraf|mb (AlexanderG@213.47.199.86) (Leaving)
# [12:47] <anne> heh
# [12:47] <hyatt> i won't implement that
# [12:47] <hyatt> i don't think there's even a good use case for it
# [12:47] <anne> the use case is lack of better elements
# [12:48] <anne> like styling <img> when it's the sole child of <p>
# [12:48] <Lachy> many of the use cases for parent selectors could probably be handled by ::outside or XBL
# [12:48] <anne> -> <figure>
# [12:48] <hyatt> it's called the class attribute.
# [12:48] <hyatt> ;)
# [12:48] <anne> hehe
# [12:49] <hyatt> i can't speak for opera
# [12:49] <hyatt> but for both mozilla and safari
# [12:49] <anne> I believe some people rather use lots of complicated selectors than resorting to class or ID
# [12:49] <hyatt> class selector = far and away the fastest way to match
# [12:49] <hyatt> (id/.tag too of course)
# [12:49] <anne> I suppose that's the case for us as well, otherwise we'd be having performance issues
# [12:49] <hyatt> anyone writing a page that they want to be really fast and efficient should just use class
# [12:50] <hyatt> in fact in safari we even optimize if the page has no descendant selectors
# [12:50] <hyatt> since we know we don't have to crawl around in a subtree when ancestors change
# [12:50] <hyatt> which can be the difference between using 50% cpu and using 2% cpu
# [12:50] <Lachy> how often would you get CSS that doesn't use any decendant selectors?
# [12:50] <hyatt> especially when sites (I'm looking at you orbitz.com) are buggy and fire JS timeouts every 10ms in an infinite chain unintentionally
# [12:51] <anne> Lachy, lots of people simple use tag / .class / #id
# [12:51] <anne> simply*
# [12:51] * Quits: sbuluf (dggara@200.49.140.40) (Quit: sbuluf)
# [12:51] <hyatt> yeah lots of people don't use them
# [12:52] <hyatt> which is good
# [12:52] <anne> as opposed to using a more complicated selector they would use an extra class
# [12:52] <hyatt> people have a tendency to write selectors with more info than they need too
# [12:52] <hyatt> i love it when i see stuff like this:
# [12:52] <hyatt> div > img.photo
# [12:52] <hyatt> when all they needed was .photo
# [12:52] <hyatt> stuff like that
# [12:53] <hyatt> it's really common to see people write tagname.classname
# [12:53] <hyatt> when all having the extra tagname there does is force the browser to do two checks instead of 1
# [12:53] * Joins: sbuluf (taeiymn@200.49.140.71)
# [12:54] <sbuluf> (just for the record, the kind of stuff you are mentioning is what i meant before, about people who makde css, and unintended consecuences)
# [12:54] <anne> oh, you didn't mean the CSS WG?
# [12:54] * anne misunderstood that then
# [12:54] <sbuluf> very flexible yes. but...what about the costs?
# [12:54] <hyatt> unintended consequences are the subject of lots of bugs unfortunately
# [12:54] <hyatt> especially with the proliferation of css hacks
# [12:54] <hyatt> people will use advanced stuff that only works in one browser
# [12:55] <hyatt> and then break when things change
# [12:55] <hyatt> a great example is yahoo
# [12:55] <hyatt> they broke safari
# [12:55] <hyatt> because they were identifying opera by looking for media queries
# [12:55] <hyatt> when we implemented media queries suddenly they decided we were opera
# [12:55] <hyatt> so we broke
# [12:55] <hyatt> ridiculous stuff like that
# [12:55] <hyatt> css hacks are just awful
# [12:56] <anne> it's annoying browser checks are required
# [12:56] <hyatt> it is
# [12:56] <hyatt> but as long as we're all buggy it's not surprising. :)
# [12:56] <hyatt> ugh 4am here i should not be awake
# [12:57] <hyatt> night
# [12:57] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [12:57] <sbuluf> (i wasn't even thinking about hacks. just much more basic stuff)
# [12:58] <anne> people just copy and paste
# [12:58] <anne> and it all sort of works
# [12:58] <anne> in an "ugly" but convenient way
# [13:00] <sbuluf> copy and paste...code? templates?
# [13:00] <anne> everything
# [13:03] <sbuluf> later
# [13:03] * Quits: sbuluf (taeiymn@200.49.140.71) (Quit: sbuluf)
# [13:06] <Philip`> I've occasionally thought something like "p:matches($ :target) { background: yellow }" could be useful (assuming I'm guessing the syntax right, to match a p ancestor of a :target)
# [13:08] <Lachy> woah, I'm just shocked Jukka Korpela's most recent post. That's not something I really expected to hear from him
# [13:10] <anne> heh, he's arguing for XHTML2
# [13:10] <anne> which he also dislikes
# [13:10] <Lachy> I know
# [13:11] <anne> I wonder if he realizes that the problems he's enumerating also apply to DOM, CSS, etc.
# [13:13] <anne> XML attribute-value normalization is silly
# [13:13] <anne> it basically requires a lot of extra characters for the common use case
# [13:14] <Lachy> I'm not familiar with how it works
# [13:19] <anne> If you want a newline, you need to use a character reference
# [13:19] * Joins: olivier (ot@128.30.52.30)
# [13:20] <Lachy> isn't in the same in HTML?
# [13:20] <anne> HTML preserves all characters
# [13:20] <anne> implementations do, anyway
# [13:20] <Lachy> Firefox doesn't
# [13:20] <Lachy> I think Opera does
# [13:21] <anne> HTML5 does
# [13:22] <Lachy> yeah, IE and Opera preserve new lines
# [13:24] * anne is going to crack doctype-internal-subset
# [13:31] <hsivonen> Lachy: Firefox does for at least the attributes where it matters in practice (in text/html)
# [13:32] <hsivonen> Lachy: Jukka Korpela in general has a pretty strong view of what specs are legitimate standards
# [13:33] <hsivonen> Lachy: (in the direction of emphasizing that ISO can issue standards and the W3C can issue RECs)
# [13:33] <hsivonen> Lachy: (hence, I am not surprised that he doesn't appreciate CSS3 modules that aren't RECs)
# [13:35] <hsivonen> but it is interesting he takes the idealistic position on HTML specs considering that his writing aimed at authors generally acknowledges legacy reality to a greater degree than competing materials
# [13:53] <Lachy> hsivonen, I was thinking more about his stance on XHTML, which isn't back compat by design, and now he's suggesting an equivalent approach with an all new language
# [13:53] <Lachy> I know he's repeatedly stated how XHTML 1.1 was an exercise in futility, and actively encourages the use of HTML4
# [13:55] * Quits: loic (loic@90.41.2.216) (Quit: hoopa rules)
# [14:15] * Joins: loic (loic@90.29.109.153)
# [14:25] * Quits: htmlr (htmlr@203.158.34.70) (Ping timeout)
# [14:25] * Joins: htmlr (htmlr@203.217.80.229)
# [14:30] * Quits: myakura (myakura@125.194.247.196) (Quit: Leaving...)
# [14:33] <anne> http://lists.w3.org/Archives/Public/public-forms/2007May/att-0012/20070502.html#topic8
# [14:33] <anne> Do you need to officially sign up somewhere?
# [14:33] <anne> If we really need a task force, I think I want to be in it
# [14:43] <Lachy> I'm not entirely happy about working with the XForms group, but yeah, we definiately need to be involved.
# [14:49] <Philip`> How come they get to have yellow and Comic Sans in their teleconference minutes, while the HTML WG is using boring grey? :-(
# [14:50] <anne> One of their members does the minutes
# [14:50] <anne> I suppose you could request some enhancements from krijnh
# [14:54] <Philip`> Hmm, does www-html have an active moderator? (I sent a message but it noted that I hadn't subscribed, but I don't know if it's worth subscribing and resending)
# [14:55] <anne> weird, my e-mail got through
# [14:55] * anne was subscribed at some point in time
# [14:55] <anne> did you cc public-html?
# [14:56] <Philip`> No
# [14:56] <Lachy> either resend it there or to www-archive
# [14:56] <anne> so maybe that's why my messages got through
# [14:57] <Lachy> anne, your's probably got through because you were subscribed before, and your email address is already on the whitelist (though, I don't know if that's actually how it works)
# [14:58] <anne> that's another option, yes
# [14:59] <Lachy> www-html should be made opened up to everyone without subscription, like www-validator is
# [15:13] <Philip`> Oh, hmm, it has the same message about manual processing even after I've subscribed
# [15:13] <Philip`> ((Not that I was being annoying and sending the same message twice - I fixed an error from the first version...))
# [15:14] <Lachy> hmm. weird. You could email sysreq@w3.org and ask them for assistance
# [15:17] <olivier> Lachy: I am not sure why www-html is still using that old moderation system
# [15:17] <olivier> I'll ask
# [15:17] <Philip`> Sounds like that'd waste too much of people's time, for a list I probably won't post to again and for a message that isn't especially interesting :-)
# [15:17] <olivier> AFAICT it should have the same setup as e.g www-validator
# [15:18] <Philip`> Lachy: But since it was sort of in reply to you, and in case anyone can see a mistake I've made, it's http://zaynar.demon.co.uk/misc2/Cleaning%20House.eml
# [15:21] <Lachy> good examples and explanation, except that the last one is non-conforming as well
# [15:21] <Lachy> <b> can't contain <script>, which it would when script is enabled.
# [15:22] <anne> your last example is in error
# [15:22] <anne> i think
# [15:22] <anne> but that doesn't really matter
# [15:25] <Philip`> Lachy: The spec says script can be "Where inline-level content is expected", and the conformance checker seems to accept it (when I manually unroll the scripts)
# [15:25] <Lachy> oh, sorry, my mistake :-)
# [15:26] <anne> maybe it should require <script> independence
# [15:26] <anne> nah, nm
# [15:26] <anne> over engineering + obvious flaws
# [15:27] <Lachy> not sure what you meant by script independence
# [15:27] <anne> when an individual script is executed (but not the others) the document should be conforming
# [15:28] <anne> damn, Metroid Prime 3 isn't out yet?!
# [15:29] <Lachy> ah, yeah that seems pointless. The only case I can think of where 1 script would be executed, but the others wouldn't is when they use different scripting languages and the UA only supports one
# [15:29] <anne> guess that means I could start finishing some books
# [15:29] <Lachy> what's Metroid Prime 3?
# [15:30] <anne> http://en.wikipedia.org/wiki/Metroid_Prime_3:_Corruption
# [15:30] <Philip`> Is there any value in having conformance criteria which are impossible to check automatically and almost impossible for a human to check (because it's too complex to analyse every possible combination of script execution)?
# [15:31] <Lachy> that's why there's the note about the halting problem in the spec
# [15:31] <anne> the UA can check those during runtime
# [15:31] <anne> in theory
# [15:31] <Lachy> yeah, taking checking a snapshot of the DOM is always possible
# [15:32] <anne> not all variants, but certainly the code path executed
# [15:32] <Philip`> Snapshotting the DOM wouldn't help detect parse errors, because they'd have already been parsed
# [15:32] <anne> parse errors can be detected by a UA as well during runtime
# [15:32] <Lachy> the parser would emit parse errors as it parses anyway
# [15:32] <anne> but only for the applicable code path
# [15:33] <Philip`> I guess that's too much of a performance impact to be enabled by default?
# [15:33] * Philip` wonders if you could make something like a Firefox extension which does this kind of dynamic conformance checking
# [15:35] <anne> with applicable code path I meant that user interactions or script nonsense could execute different functions that do different things
# [15:35] <anne> so it's not likely you check all of the script
# [15:35] <anne> i'm not sure how much of a performance hit reporting the parse errors in some console is
# [15:36] <Philip`> Ah, right
# [15:37] <anne> which i suppose, is the halting problem :)
# [15:42] * Joins: Sander (svl@80.60.87.115)
# [15:45] <anne> presentational markup
# [15:45] <anne> i think i'll just go silent for now
# [15:55] * Joins: zcorpan (zcorpan@84.216.40.239)
# [15:56] <hsivonen> Philip`: I think it would be possible to make a conformance checker that runs on the DOM in Gecko. Etna has a RELAX NG engine for Gecko. there's already XPath support in there for Schematron. you'd need to port the datatype library and the non-schema-based checkers
# [15:57] <hsivonen> Philip`: it doesn't follow though, that it would make sense performance-wise to run it all the time
# [16:00] <Lachy> hsivonen, I don't think anyone was suggesting that it run continuously. But such an extension could be useful for authors who want to check conformance
# [16:00] <Lachy> .. one that checks on request, of course
# [16:00] <hsivonen> Lachy: yeah, worth doing
# [16:00] <zcorpan> when gecko implements an html5 parser it could probably easily log html parse errors to the error console
# [16:01] <Lachy> that would be nice
# [16:01] <Lachy> I'm still waiting for Opera to start logging errors to its console
# [16:01] <hsivonen> Lachy: I suggest starting with figuring out how to run the Etna RELAX NG engine inside a Firefox buil
# [16:03] <hsivonen> another interesting cross-browser approach would be taking one of those RELAX NG to C or RELAX NG to Java validator generators and write a JavaScript back end
# [16:06] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [16:10] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [16:10] * Joins: olivier (ot@128.30.52.30)
# [16:17] * Parts: Lachy (Lachlan@124.168.27.56) (Leaving)
# [16:20] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [16:21] <zcorpan> i don't understand dave r's arguments for modularizing the spec at all
# [16:21] <Dashiva> Spec big. Confuse Thog. Thog head hurt.
# [16:22] * Joins: schepers_ (schepers@69.134.24.226)
# [16:22] * Quits: schepers (schepers@69.134.24.226) (Connection reset by peer)
# [16:22] <zcorpan> how is that different from "many specs"
# [16:23] <zcorpan> i don't see how it would reduce confusion at all
# [16:23] <zcorpan> or help writing test cases
# [16:23] <zcorpan> or anything
# [16:23] <zcorpan> all i see is that it would be more work for the editors
# [16:24] <zcorpan> and the whole thing not being published as a rec doesn't mean it won't be adopted
# [16:24] <Dashiva> As I understand it, they consider everything outside conformant document requirements to be irrelevant
# [16:24] * Joins: Lachy (Lachlan@124.168.27.56)
# [16:25] * Quits: Lachy (Lachlan@124.168.27.56) (Quit: Leaving)
# [16:25] * Joins: Lachy (Lachlan@124.168.27.56)
# [16:25] <zcorpan> they are irrelevant to someone who won't implement anything
# [16:25] <zcorpan> that's why i'm working on this style sheet
# [16:26] * Quits: zdenko (zdenko@193.77.152.244) (Quit: zdenko)
# [16:28] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [16:29] <Philip`> If splitting the spec into modules would reduce dependencies between parts of the spec, then I can see that being helpful
# [16:30] <Philip`> (But if it ends up with the same dependencies except they're more convoluted and spread across multiple specs, that would be quite unhelpful)
# [16:30] * Philip` wonders if Graphviz would be able to show the current dependencies...
# [16:32] <zcorpan> there alreday are dependencies across the spec (Hixie explained how e.g. script, parsing, innerHTML and various other parts depend on each other, and they have to)
# [16:34] <zcorpan> http://lists.w3.org/Archives/Public/public-html/2007JanMar/0096.html
# [16:49] * Joins: mjs (mjs@64.81.48.145)
# [16:49] * Joins: billmason (billmason@69.30.57.156)
# [16:56] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [17:02] * Joins: mjs (mjs@64.81.48.145)
# [17:08] <anne> you know, after debating a while on presentational markup it's no longer clear to me what the point of doing that was
# [17:08] <anne> and the point was to get agreement on design principles
# [17:08] <anne> but that seems entirely lost
# [17:09] <hsivonen> it seems that Philip Taylor not only wants to ignore browser vendors but wysiwyg editor vendors, too
# [17:10] <hsivonen> I wonder what enforcement mechanism he has in mind to get his vision implemented
# [17:16] * Joins: hasather (hasather@81.235.209.174)
# [17:16] <anne> A hammer
# [17:21] <anne> Actually, that will just make me run away
# [17:21] <anne> Maybe a cage and a hammer
# [17:24] <hsivonen> how do I address lists.w3.org messages by message id?
# [17:24] <anne> x-archive-at header in the e-mail
# [17:24] <anne> or
# [17:24] <anne> copy the id mentioned on the site
# [17:24] <anne> and place it after www.w3.org/mid/
# [17:25] * mjs heads out
# [17:25] <mjs> catch you guys later
# [17:25] <hsivonen> anne: thanks
# [17:25] <anne> mjs, bye!
# [17:25] <mjs> hopefully an hour on the train will be enough time to catch up on htmlwg flamage
# [17:25] <anne> hsivonen, I'm actually not sure it's the better URL
# [17:25] <mjs> I also have to post something about forms
# [17:25] <anne> mjs, :)
# [17:25] <anne> hsivonen, but it seems to be
# [17:26] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [17:28] <hsivonen> anne: I used the URL from the header
# [17:29] <hsivonen> one of the practical things I was unaware of
# [17:33] * Joins: zdenko (zdenko@84.255.203.169)
# [17:33] <anne> heh
# [17:33] <anne> the access people think <i> means inaccessible
# [17:33] <anne> bet they never talked to TV Raman
# [17:33] <DanC> hmm... should I send another "I suggest discussion of new features at this point in this WG is not likely to be a good use of time." message? perhaps http://lists.w3.org/Archives/Public/public-html/2007JanMar/0735.html has timed out. would somebody like to help with mailing list traffic-shaping.
# [17:33] <anne> i'm talking in multiples again
# [17:33] <anne> it was a single person
# [17:33] <anne> sorry
# [17:34] <anne> DanC, I think you should guide the discussions more
# [17:34] <DanC> I'm maxed out
# [17:34] <anne> DanC, at least try to indicate the scope a bit better
# [17:34] <anne> because currently it seems like we can still go down the XHTML2 route
# [17:34] <anne> which I don't think is what the charter wants, nor we
# [17:35] <DanC> I'm not going to repeat myself. that doesn't set a good example.
# [17:37] <DanC> re the XHTML 2 route, I suggested backing off from the design principles discussion, for now. I expect we will need to finish the "support existing content" discussion eventually, but I don't want to force it just yet.
# [17:38] <anne> I don't see how it's worth everyone's time
# [17:38] <DanC> I want to get consensus to start using a shared text for discussion of changes, issues, new features, etc.; until we have a shared text to focus the discussion, it's horribly painful.
# [17:38] <anne> there's lots of people on the list, that's a lot of money
# [17:39] <Lachy> we just need to get some actual decisions made in the group. We've been at it for 2 months, and exactly 0 have been made
# [17:39] <DanC> exactly, Lachy . We're close on one.
# [17:39] <anne> meanwhile WHATWG has specced <video>, <audio> and lots of other things
# [17:40] <DanC> "I don't see how it's worth everyone's time" <- "it" refers to what? surely backing off from discussion costs zero.
# [17:42] <Lachy> DanC, do you expect John Boyer's formal objection to have any serious impact upon the adoption of HTML5?
# [17:42] <DanC> I've got 21 people signed up for "detailed review of substantial sections of spec" and 4 for "issue tracking, summarization, and clustering". If the HTML 5 question carries, we can start a section-by-section review of the HTML 5 spec.
# [17:42] <Lachy> people should have already started reviewing it.
# [17:43] <Lachy> how can people vote yes or no on something they've never reviewed, at least a high level review
# [17:44] <DanC> right; they need to sorta figure which end is up. But they haven't been obliged to send "I don't like feature XYZ" comments yet.
# [17:46] <Lachy> a lot of people are just objecting to things they just don't understand, which is a problem
# [17:47] <DanC> yeah... one idea I've had for the review is to constrain it so that to raise an issue, you have to attach a sample/test document and say "I disagree with what the text in section X says about the attached document."
# [17:47] <Lachy> I don't agree with requiring test cases for everything
# [17:48] * Joins: ROBOd (robod@86.34.246.154)
# [17:48] <anne> people should cite sound technical arguments
# [17:48] <DanC> I'm interested in other ideas to address your "people are just objecting to things they just don't understand" concern.
# [17:49] <anne> dunno, how do you usually deal with non-experts in a group?
# [17:49] <DanC> I make them focus on test cases.
# [17:49] <anne> fair enough
# [17:50] <DanC> well, story telling (use cases) and test cases.
# [17:50] <Lachy> I once explained on the list how to go about explaining problems and use cases, before disucssing solutions. People need to stop looking for solutions to non-existing problems
# [17:51] <Lachy> if we can get them to focus on the problem, and actually think about the situation, then there's a good chance they'll only be objecting to things they do understand
# [17:51] <Lachy> I'm just not sure how to get the group to do that
# [17:52] <DanC> I wish you luck in getting everyone to work that way. but it's a subtle thing to learn. "your message has no example attached" is black and white. I suggest it's a moderately low-cost distraction, at worst, for people that already know how to give sound technical arguments.
# [17:53] <DanC> likewise "your message doesn't cite a section of the spec"
# [17:53] <Lachy> but test cases need to be written for a specific purpose and have clear pass/fail conditions. Getting people to just write test cases for every feature they suggest, actually has the effect of getting to propose solutions first
# [17:54] <Lachy> i.e. I think we should add a <table3> element, here's a test case!
# [17:54] <DanC> I don't think it's going to be cost-effective to discuss new features for at least 3 months. probably more like a year. I'm not sure how to get that message across.
# [17:55] <Lachy> asking them to cite specific sections of the spec is good
# [17:55] * Joins: kazuhito (kazuhito@222.151.148.169)
# [17:56] <Lachy> HTML5 is fairly close to feature complete anyway, so there really aren't that many more new features to add at this stage anyawy
# [17:57] <DanC> I'm noodling on an essay on humility or something. maybe I could make the point in economic or game-theoretic terms. "A new feature in HTML costs about 100 million dollars. [back that claim a bit]. So when you propose a new feature, you're going to need really, really solid justification and research behind it, and you're going to need a lot of help raising that money [i.e. time/resource/effort]."
# [17:59] <Lachy> 100 million sounds like a lot, but I suppose by the time you factor in the time spent editing the spec, debating it on the list, writing test cases, implementing, fixing bugs, etc. it all adds up
# [18:01] <anne> books
# [18:01] <anne> classes
# [18:02] <anne> tutorials
# [18:02] <anne> using it in sites
# [18:03] <DanC> "using it in sites" might go beyond what I'd include in the cost. but yeah... all those books and training materials. wetware costs a LOT
# [18:03] <DanC> I'd like people to appreciate that the spec writing is a tiny fraction of the cost.
# [18:04] <DanC> and that having a feature in a W3C Recommendation is rarely enough, on its own, to get something deployed
# [18:06] <anne> also considering we're doing standards, not innovation
# [18:07] <anne> we're specifying features multiple people want to implement interoperably
# [18:09] <DanC> hmm... it might be nice to have a wiki topic that discusses the lifecycle of new features in HTML, including 3 examples. it should show that spec writing is one component, but testing, implementaiton, training, advocacy, etc. are also all part of the game
# [18:09] * DanC tries to remember the last time HTML grew a new feature
# [18:09] <anne> <canvas>?
# [18:10] <DanC> using that example would surely get plenty of attention
# [18:10] <anne> prolly the most successful new element since a long time
# [18:10] <DanC> it's more controversial than the sort of thing that usually works well in a wiki
# [18:10] <DanC> the story of <canvas> might fit better into a blog item
# [18:10] <DanC> well, I'm off to lunch
# [18:10] <anne> besides that and Web Forms 2 I can't help you
# [18:11] <Lachy> maybe some of the new form controls?
# [18:11] <anne> when I "joined the web" HTML4 was there
# [18:11] <DanC> <img> and <form> are the new features that I was involved in.
# [18:11] <DanC> the cost wasn't so high back then
# [18:11] <DanC> most of the new features since then have been in CSS
# [18:11] * anne read back on some discussion on <img>
# [18:11] * DanC is away: lunch etc
# [18:12] * anne liked <a rel=embed href=image>fallback</a>
# [18:12] <anne> otoh, it overloads <a>, but from a compat perspective it's quite good
# [18:14] <anne> SVG is going modular
# [18:14] * Philip` totally fails at usefully visualising internal links in the spec (via http://canvex.lazyilluminati.com/misc/graph3c.png)
# [18:14] <anne> filters is first
# [18:14] <anne> http://www.w3.org/TR/2007/WD-SVGFilterReqs12-20070501/ http://www.w3.org/TR/2007/WD-SVGFilterPrimer12-20070501/ http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/
# [18:14] <anne> that's already three docs for one module
# [18:15] <anne> and a shitload of DOM interfaces too
# [18:15] <anne> whoa
# [18:15] <anne> http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#DOMInterfaces
# [18:16] <anne> cool, it has ImageData which is compatible with HTML5
# [18:16] <anne> now that's nice
# [18:16] <anne> (given that it works)
# [18:17] <anne> oh i see, those interfaces are basically tied to the elements so each element gets an interface
# [18:17] <anne> i like that too
# [18:18] <Philip`> Unfortunately the only implementation of ImageData I've seen (in Firefox) returns premultiplied colour components instead of the normal values you'd expect :-(
# [18:18] <Philip`> and I can't see anything explicitly saying that's wrong
# [18:18] <anne> you can get impl fixes
# [18:18] <anne> fixed*
# [18:18] <anne> or did you already raise issues?
# [18:20] <Philip`> I haven't yet, since I'm trying to work through other areas first [but not having enough time to actually get it done] and I expect I'll look into that stuff in more detail later
# [18:23] * Joins: h3h (bfults@66.162.32.234)
# [18:26] <anne> filter stuff is complicated though
# [18:26] * anne saves it for some other time
# [18:33] <anne> separaring how to parse the syntax from the HTML specification
# [18:33] <anne> now that's a good idea
# [18:33] * anne waits for a rain of +1 messages
# [18:34] <anne> actually, I'll wait for a volunteer
# [18:38] <gsnedders> +1
# [18:50] * Joins: dbaron (dbaron@63.245.220.242)
# [19:00] * Joins: zcorpan_ (zcorpan@84.216.42.62)
# [19:01] * Quits: zcorpan (zcorpan@84.216.40.239) (Ping timeout)
# [19:22] * Quits: htmlr (htmlr@203.217.80.229) (Quit: htmlr)
# [19:27] * Joins: mjs (mjs@17.255.99.9)
# [19:41] <zcorpan_> mjs: you wrote "I would appreciate it if XForms experts" without ending that sentence in http://www.w3.org/mid/54B421A9-89E2-4651-AA69-1268F169F2FB@apple.com
# [19:53] <mjs> zcorpan_: oops
# [19:53] <mjs> zcorpan_: will follow up
# [20:00] <mjs> anne, Hixie: I'd love it if one of you could review WF2 against the list of proposed forms architectural consistency requirements
# [20:04] <Hixie> is there a mail on that?
# [20:04] <Hixie> oh blimey, i have hundreds of mails
# [20:07] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:09] <mjs> Hixie: I sent the requirements w/ the subject "Architectural Consistency Requirements for Forms"
# [20:09] <Hixie> k
# [20:14] * Joins: dbaron (dbaron@63.245.220.242)
# [20:16] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [20:32] * Joins: hyatt (hyatt@17.255.99.164)
# [20:34] * Joins: briansuda (briansuda@130.208.155.117)
# [20:43] * Quits: kazuhito (kazuhito@222.151.148.169) (Quit: Quitting!)
# [21:05] * Joins: edas (edaspet@88.191.34.123)
# [21:09] * Quits: hyatt (hyatt@17.255.99.164) (Quit: hyatt)
# [21:33] <Philip`> mjs: "All browser implementations that I know of already [refuse to process the page] for non-well-formed XHTML" - Konqueror and Links both parse application/xhtml+xml documents with their normal HTML parser, so they happily continue past non-well-formed XHTML (and often parse well-formed XHTML incorrectly)
# [21:33] <Dashiva> Opera has a reparse as HTML button
# [21:35] <Hixie> and mobile browsers other than opera uniformly treat all XHTML as tag soup
# [21:39] <mjs> I think I mentioned mobile browsers
# [21:39] <mjs> didn't know about Konqueror
# [21:39] <Hixie> i didn't see your e-mail, was just commenting on the above
# [21:40] * Hixie is writing a long e-mail with wf2 examples for you
# [21:41] <mjs> I just thought Shane might be misunderstanding the situation if he thought there was madness to stop that would be stopped by IE doing something
# [21:42] <Philip`> (The current KDE4 Konqueror does the same - I'd assume XML parsing is just a low priority item that they haven't got around to adding yet)
# [21:42] <Philip`> (They have added <canvas>, though)
# [21:42] * Joins: hyatt (hyatt@17.255.99.164)
# [21:44] <mjs> I thought they had an XML parser
# [21:44] <mjs> I'd be surprised it they don't use it for application/xml at least
# [21:48] <Philip`> Version 3.5.5 doesn't do XML for application/xml, judging by e.g. http://hixie.ch/tests/adhoc/xml/parsing/001.xml
# [21:48] <Philip`> (I don't have the KDE4 version to test now)
# [21:49] <Philip`> Oh wait, one of the tests failed
# [21:49] <Philip`> but only once, and I can't make it fail again
# [21:54] <Philip`> It has "XML parsing error" on 008.xml, but it shows both lines (and applies the stylesheet) on 004.xml - I have no idea what it's doing...
# [21:56] <mjs> I asked one of the Konqueror developers and he confirms they use an HTML parser for application/xhtml+xml still, though they are looking to fix it
# [21:59] <zcorpan_> can anyone test http://hsivonen.iki.fi/doctype/test-quirks.php?doctype=%3C%21DOCTYPE+html%3E with konq?
# [21:59] * Joins: John_Boyer (boyerj@32.97.110.142)
# [21:59] <John_Boyer> rrsagent, make minutes
# [21:59] <RRSAgent> I have made the request to generate http://www.w3.org/2007/05/03-html-wg-minutes.html John_Boyer
# [21:59] <John_Boyer> rrsagent, make log public
# [21:59] <RRSAgent> I have made the request, John_Boyer
# [21:59] * Parts: John_Boyer (boyerj@32.97.110.142)
# [22:03] <Philip`> zcorpan_: With 3.5.5, everything apart from the "Mozilla and Opera 9 Test" is compatible with it being in standards mode and not almost-standards or quirks
# [22:03] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [22:04] <Philip`> (Things like "<!DOCTYPE html5>" make it quirks)
# [22:05] <Philip`> (Things like "<!DOCTYPEHTML>" and "<!DOCTYPE html PUBLIC "5">" are standards too)
# [22:06] <hasather> zcorpan_: somewhat related: http://bednarz.nl/+/sgml/doctype/switch
# [22:09] <zcorpan_> Philip`: you could perhaps send results to hsivonen so that he can add the missing part to the table
# [22:11] * Joins: dbaron (dbaron@63.245.220.242)
# [22:13] <schepers_> I've reconsidered my position about validity and well-formedness... I'm still not drinking the koolaid, but I do see the advantages of the "error handling" approach
# [22:14] <gavin> "drinking the koolaid" is a bit pejorative :)
# [22:14] <schepers_> I can see why you think that, but it's not intended that way
# [22:15] <schepers_> I (and many others) use it for things we really like
# [22:15] <gavin> ok
# [22:15] <schepers_> like, I say I've drunk the declarative koolaid, or the SVG koolaid
# [22:16] <Philip`> zcorpan_: Konqueror 3.5 seems to be totally different to what's in the table (I think it's doing standards + almost standards + quirks now) - I'll see if I can get data for a new column tonight
# [22:17] <Philip`> Oh whoops, I think I was looking at the tests in Opera instead, which'd affect things a little bit
# [22:17] * mjs sent some more mail about forms requirements
# [22:18] <zcorpan_> Philip`: ok
# [22:18] <Philip`> Ah, but it does indeed seem to do almost standards anyway
# [22:18] <schepers_> one thing I don't like about XML error handling is the halt+catch(fire) prescription
# [22:26] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:31] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [22:32] * Joins: Roger (roger@213.64.74.230)
# [22:40] <zcorpan_> hey Roger
# [22:40] <Roger> hey
# [22:40] <zcorpan_> are you coming to the next geekmeet?
# [22:40] <Roger> nope, won't be able to make it unfortunately
# [22:40] <Roger> would have been interesting ;)
# [22:40] <zcorpan_> ok
# [22:41] <zcorpan_> i hope it will be :)
# [22:41] <Roger> trying to catch up with today's public-html messages now...
# [22:51] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [22:53] <Hixie> well crap.
# [22:53] <Hixie> i just lost the entire e-mail that i was writing.
# [22:54] <mjs> :-(
# [22:56] <schepers_> ugh.
# [23:16] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [23:21] * Quits: Sander (svl@80.60.87.115) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:27] * Quits: briansuda (briansuda@130.208.155.117) (Quit: briansuda)
# [23:30] <mjs> I wonder how Dan Connolly and John Boyer both managed to singificantly misquote the Vision Document in the same way
# [23:32] <gavin> is that a rhetorical question? :)
# [23:33] <mjs> I'm honestly curious
# [23:33] <gavin> presumably because they have a common understanding that might not be codified in the vision document
# [23:33] <gavin> who produced the vision document, anyways?
# [23:34] <mjs> I kind of assumed the block quotes and quotation marks indicated a literal quote
# [23:34] <gavin> maybe they're quoting from a different vision document
# [23:34] <mjs> yet they both altered the wording in the exact same way
# [23:34] <mjs> Dan Connolly linked to the one I looked at, which didn't match his quote
# [23:38] <Philip`> Has that document ever been altered?
# [23:38] <DanC> oops. there are 2 very closely related vision documents; one public, one not. I assumed they were the same in this respect
# [23:39] <Philip`> There was at least one earlier revision similar to what was quoted - http://www.w3.org/2001/tag/2007/03/07-afternoon-minutes has 'TimBL edits to say "Instead, the charter calls for two equivalent serializations to be developed by the HTML WG, "'
# [23:40] <DanC> http://www.w3.org/2007/03/vision.html and http://www.w3.org/2007/03/html-forms-vision.html
# [23:40] <DanC> I thought they were the same except for stylesheet and some links
# [23:41] <Hixie> i love the subtle differences between those two versions
# [23:42] <DanC> you can see the thread where john and I composed the call for volunteers in www-archive (split between April and May, unfortunately)
# [23:42] <Hixie> public version: "This direction does not diminish the role of XML as the central architecture for markup on the Web and elswhere." secret version: (emphasised, even) "W3C is not abandoning XML."
# [23:44] <Hixie> similarly, public: "implementations will fall into line as necessary over time", secret: "everything else will fall into line over time"
# [23:44] <DanC> reviewing the CVS logs, the public one is derived from the unreleased one.
# [23:45] <Hixie> makes sense
# [23:45] <Hixie> i assume the unreleased one is just an earlier version
# [23:45] <Hixie> certainly the changes seem like improvements
# [23:46] * DanC read them both too many times to see the differences clearly
# [23:47] <Lachy> good morning
# [23:48] * Quits: hyatt (hyatt@17.255.99.164) (Quit: hyatt)
# [23:48] <DanC> oh my. mjs and JB quoting charters and process documents at each other. whee! that's my idea of fun. not.
# [23:48] <Lachy> I can't believe John Foliot totally missed the point of my questions :-(
# [23:49] <mjs> DanC: JB said his objection was a process one, so I think quoting charters and process documents it a wholly appropriate way to address it
# [23:49] <DanC> true, but still not fun.
# [23:50] <DanC> telling him his objection is somehow unfounded seems unlikely to cause him to withdraw it.
# [23:50] <mjs> I'd prefer if he'd limited his objection to technical merits, not process
# [23:50] <DanC> this isn't a technical question
# [23:50] <mjs> no, but I hope it influences the chairs to acknowledge it and move on
# [23:51] <mjs> rather than making a change to address an objection based on false premises
# [23:51] <Philip`> Lachy: "cite some *specific* use cases" sounded pretty clear to me, so I'm not sure why he answered the questions without doing that
# [23:51] <DanC> but it's much nicer if I don't have to make this decision. it's much nicer if he withdraws his objection because he feels comfortable working in the group after all.
# [23:52] <mjs> well, he's asking us to do something contrary to our charter (as far as I can tell), based on his claim that our charter requires it
# [23:52] <mjs> I am not sure how to change his mind about his request - I certainly tried
# [23:53] <mjs> most notably by capturing his technical requirements, assuring him that the Forms Task Force could refine them, and agreeing that we should aim to meet those requirements (subject to refine them)
# [23:55] <DanC> mjs, perhaps just letting him think a bit will allow him to withdraw. I see he wrote "I've seen enough willingness to collaborate in the past two days that it now seems an impasse is not the most likely outcome. " just earlier.
# [23:55] * Joins: hyatt (hyatt@17.255.99.164)
# [23:55] <mjs> well, my original suggestion of how to interpret the charter requirements wasn't meant to be an attack on him (although I figured he probably wouldn't agree)
# [23:56] <mjs> it's a sincere attempt to come up with a constructive course of action
# [23:56] <mjs> I sincerely think the Task Force coming up with a set of architectural consistency requirements that both groups follow is a good thing, and in line with our charter
# [23:57] * Hixie considers trying to write the long e-mail again
# Session Close: Fri May 04 00:00:00 2007

The end :)