<mjs> heycam: me too!

<mjs> John_Boyer: are you willing to answer my question?

<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?"

<John_Boyer> Sorry got distracted...

<mjs> are you less distracted now, or should I wait?

<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.

<John_Boyer> I am sure there are quite a few things I didn't get to off the cuff

<Zeros> John_Boyer, one would hope that Hixie and hyatt would be open to changes

<Hixie> certainly personally i am more than willing to change the spec to meet concrete technical requirements and use cases

<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

<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

<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

<mjs> John_Boyer: I actually haven't studied it enough to say right now if it does or not

<mjs> John_Boyer: also, if you remember other requirements, you could add them to the list

<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?

<John_Boyer> Yes, Maciej, this is the key issue. What is the statement of requirements and use cases that WF2 currently addresses?

<mjs> John_Boyer: does it matter to you what other requirements it may address besides yours?

<mjs> John_Boyer: if it addresses yours would you be satisfied?

<John_Boyer> What are the use cases/requirements that XForms addresses?

<John_Boyer> When the same requirement is being met, is there a reason to have it done by different syntax?

<John_Boyer> These are the things the task force is supposed to work out.

<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

<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.

<John_Boyer> by the task force.

<mjs> XForms syntax clearly does not satisfy these

<John_Boyer> agree

<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

<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

<John_Boyer> Well, I don't want to repeat that discussion. I obviously think the task force is responsible for forms.

<mjs> so your understanding of the charter is that the HTML Working Group can't define form features in the HTML specification?

<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.

<John_Boyer> So are the Forms WG members who join the same task force.

<Zeros> the xforms task force?

<hober> "are part of" or "are the part of"?

<mjs> is that symmetric? is the Forms WG also not allowed to define forms features in XForms outside the task force?

<John_Boyer> zeros: The joint forms task force

<Zeros> ah

<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

<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"

<mjs> that says to me that the Forms Task Force is responsible for ensuring the consistency, not writing any specs

<hober> mjs++

<mjs> writing a spec might be one way to do that, but perhaps not the best way, compared to stating the requirements

<Zeros> So we have the xforms wg, the forms wg, and wf2 over at whatwg?

<John_Boyer> consistency to the point of doc authors being able to transition...

<Zeros> that's some incredible redundancy

<John_Boyer> Trying to reduce that !

<John_Boyer> Want ONE task force.

<mjs> right, I'm hoping sufficient consistency can be defined in the form of requirements

<John_Boyer> Come together to fix problem of trifurcation.

<mjs> John_Boyer: is the Forms WG holding off on all editing and review of XForms documents until the task force is formed?

<mjs> John_Boyer: you're really not answering any of my questions

<mjs> I'm not sure why, since they are pretty simple yes-or-no questions

<John_Boyer> Questions are coming from multiple people faster than I can type

<mjs> does anyone mind if I restate my 2 questions for John and then give him a chance to answer clearly?

<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

<John_Boyer> we are holding off on all that until the "who" of it gets solved.

<John_Boyer> But we have other work to do in the meantime, just as theres lots to do on HTML besides forms I presume.

<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

<John_Boyer> That was one, Maciej, what was the one I missed?

<mjs> John_Boyer: I don't think that is a reasonable expectation

<John_Boyer> XForms 1.1 entered last call before the new working groups were even chartered. It's old work.

<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)

<John_Boyer> It's like the XFOrms 1.0 you already don't like.

<John_Boyer> I already answered that.

<Hixie> Web Forms 2 entered W3C WD status before the groups were chartered too, fwiw

<John_Boyer> I don't think so

<mjs> is your answer "yes" or "no" to that question?

<mjs> I didn't get that from your answer

<John_Boyer> mjs: right now my answer is I don't think so.

<Hixie> (http://www.w3.org/TR/web-forms-2/ was published on the REC track in August 2006)

<Hixie> (so it's "old work" just like XForms 1.1)

<John_Boyer> Yes, and that's what started the whole ball rolling on the new charters.

<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

<John_Boyer> Our charter says that we will deliver XForms 1.1

<John_Boyer> mjs: you haven't satisfied the "technical merits"

<John_Boyer> because the technical merits concern the process

<John_Boyer> not WF2

<John_Boyer> please, how many times do I have to day that?

<John_Boyer> I don't object to WF2

<John_Boyer> I don't object to WF2

<John_Boyer> I don't object to WF2

<John_Boyer> I don't object to WF2

<John_Boyer> I don't object to WF2

<mjs> what do you object to, then?

<mjs> if you don't object to it, how can you object to adopting it as a basis for review?

<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"

<John_Boyer> You were here in the earlier conversation where I already went through all of this.

<mjs> John_Boyer: your vote says "no", that is what makes it a Formal Objection

<mjs> actually I wasn't here

<mjs> someone did point me to the logs

<John_Boyer> Oh, please see the minutes.

<mjs> I can't access that URL

<mjs> "We're sorry but the link you tried to access is forbidden."

<John_Boyer> rrsgagent, make log public

<John_Boyer> mjs: please see the minutes for yesterday...

<John_Boyer> they are already public

<John_Boyer> looks like the day flipped during this conversation

<mjs> where can I find the minutes for yesterday, the ones you linked appear to only cover our conversation just now

<John_Boyer> Use the same URL as above, only change 03 to 02

<Hixie> http://krijnhoetmer.nl/irc-logs/

<Hixie> has more complete IRC logs

<John_Boyer> Anyway gotta run for now...

<Zeros> the log from that bot is interesting

<Zeros> aside from the warnings at the bottom of the page

<John_Boyer> Would be great to start with empty document and look at *what* is being attempted.

<Zeros> with respect to what?

<mjs> I still don't understand what you object to, and what your proposed alternative is

<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

<mjs> HTML WG reviewing it does not preclude Forms Task Force also reviewing it

<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?

<mjs> I don't think "start with an empty document" is a valid technical or process requirement

<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?

<mjs> I don't think asking the HTML WG to stop work on some area is a valid process requirement either

<mjs> the task force is chartered to ensure architectural consistency, it has no charter to start from scratch on a new language

<mjs> that might be one way of achieving architectural consistency, but it is surely not required to achieve it

<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

<mjs> revising an existing language is another equally valid way

<Hixie> XForms was the starting point for WF2, for what it's worth

<Hixie> it was even originally called XForms Basic

<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

<Hixie> (the XForms WG complained so I changed it)

<John_Boyer> the wg already had a thing called XForms basic

<mjs> it would be like adopting PDF as a basis for review

<John_Boyer> can't understand why you didn't just join the working group and get the changes made to XForms?

<Hixie> sure. my point is just that XForms was already adopted as a starting point, that's how we got to WF2.

<John_Boyer> Why do things look so different then?

<John_Boyer> Maybe creating a bit of a rosetta stone would help.

<John_Boyer> The repeats don't look much like each other

<Hixie> well, we have to make it compatible with the proposed design principles -- graceful fallback, legacy content handling, etc

<Hixie> that necessarily constrains what the language can look like

<John_Boyer> and it doesn't make sense to adopt a different mechanism when you are already have to add to the language anyway

<mjs> it does make sense if the new mechanism is better suited to graceful degradation and compatible handling

<Hixie> it is quite possible to add to HTML without breaking legacy content handling, and without sacrificing graceful degradation in legacy UAs

<Hixie> but such additions are very constrained in what syntax they can use

<mjs> I have to head out

<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"

<John_Boyer> then

<mjs> John_Boyer: thanks for having this conversation, it's by far the most useful XForms-related conversation I've ever had

<John_Boyer> down the pipe comes a blob of XML that represents the data the user worked on yesterday

<John_Boyer> how does the table get filled up?

<John_Boyer> with controls I mean?

<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)

<Hixie> this method, when invoked, casuse repetition blocks to be filled appropriately based on the data in that Document object

<Hixie> this is described here: http://www.whatwg.org/specs/web-forms/current-work/#seeding

<Hixie> and here: http://www.whatwg.org/specs/web-forms/current-work/#resetFromDataDOM

<mjs> John_Boyer: I'll probably send some email summarizing this discussion later tonight or tomorrow

<John_Boyer> ok

<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

<Hixie> well, "replacing the data" is the call to resetFromData() -- the table does indeed automatically regenerate itself as a result of that call

<John_Boyer> What if two tables are bound to parts of the same data?

<John_Boyer> do you have to reset them each manually?

<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)

<Hixie> just calling resetFromData() with the Document that contains the form's data will fill in all the relevant parts of that form

<John_Boyer> sorry, DanC and I are just working out details of task force call for participation

<John_Boyer> How does this play when you put a table inside a table?

<John_Boyer> If similar capabilities exist, I end up wondering why there are two such different tag sets

<John_Boyer> this is a net new feature

<John_Boyer> no old html 4 forms are going to contain this.

<Hixie> again, nested tables just work, assuming you declare them in the right order in the instance document

<John_Boyer> what does the data look like

<John_Boyer> when you submit it?

<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'

<Hixie> let's see

<Hixie> if you search for <formdata in the spec you'll find some examples

<Hixie> at the end of section 5.4

<John_Boyer> but xforms can also be delivered either to browser that understand it, or to todays browser with server-side support

<John_Boyer> so that doesn't seem to work as a justification

<Hixie> well with the repetition structures it's certainly true that the wf2 fallback isn't ideal

<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

<Hixie> with the other features, e.g. new controls, the fallback in wf2 doesn't require any server-side support at all

<John_Boyer> of pulling these two things together

<Hixie> i'd be very happy to participate in a task force that collected together the requirements for html5 forms

<John_Boyer> agree, xforms is also pretty much baked on the idea of "custom controls" too

<John_Boyer> it's not that hard actually

<Zeros> Hixie, speaking of wf2, the min/max attributes on <input type="file"> needs a requirement that the range cannot be smaller than 1

<John_Boyer> we could have used someone carryign the ball

<John_Boyer> and making it more a reality sooner

<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.

<Hixie> (and still are)

<John_Boyer> why, the html4 browser won't understand the html5 behavior.

<Hixie> but it will degrade in a graceful way

<Hixie> for example, if you ask for a number:

<Hixie> <input type=number ...>

<John_Boyer> We have people today who deliver JS libraries that translate pure XForms into what today's browseres understand

<Hixie> the HTML5 UA will know it's a number field, and will support that

<Zeros> John_Boyer, that's not accessible

<Hixie> but the HTML4 UAs will still actually display a text field

<Zeros> xforms actually works nicely as a server side description format for transformation into HTML+JS using XSL though

<Hixie> so effectively, the html4 browser _does_ understand the html5 behaviour, though in a degraded way

<John_Boyer> zeros, wcag 2?

<John_Boyer> hixie, that seems to be true of wf2 and xforms, so is there another reason for diffs

<Zeros> John_Boyer, WCAG, 508, you name it.

<Hixie> John_Boyer: it isn't true of xforms -- an xform document doesn't show form controls at all in an html4 browser.

<Hixie> xforms document, rather

<John_Boyer> hixie, it sounds like wf2 is optimizing a use case that is not very useful

<John_Boyer> an xf document can show actual controls in an html4 browser in numerous ways

<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.

<John_Boyer> I think we've had this conversation before

<Hixie> for example, visit this page in mozilla without the xforms plugin: http://www.mozilla.org/projects/xforms/samples/tax_form/TaxForm.xhtml

<Hixie> you don't see any form controls

<Hixie> but visit this WF2 form in that same browser: http://www.whatwg.org/demos/multiform-01/

<Hixie> and the form will actually work, even if it doesn't work as perfectly as it would in an HTML5 browser

<John_Boyer> I *know* we've had this conversation before.

<Hixie> that's quite possible. the requirements from browsers haven't changed since then.

<John_Boyer> The "XForm" is expressed with the xforms namespace

<John_Boyer> that's why the controls don't show

<Hixie> right

<Hixie> that's a problem

<John_Boyer> That has nothing to do with why your tag set differs

<John_Boyer> we've gone through a number of iterations already of how to provide xforms tags to html IN HTML namespace

<John_Boyer> that would satisfy the browser vendors

<John_Boyer> the controls would show up then

<John_Boyer> that's one of the bases of the so-called XForms transitional work

<Zeros> Isn't xforms xml?

<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

<John_Boyer> XForms is currently serialized as XML

<Zeros> John_Boyer, If it was in a html document would it require the xml syntax?

<John_Boyer> but tags should mean the same thing whether you serialize as xml or not

<John_Boyer> no

<John_Boyer> this is why face to face meetings are needed

<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

<John_Boyer> too bad we can't get 400 people in a room :-)

<Hixie> it is simply not true that <input> in XForms has legacy UA graceful degradation

<Zeros> the number isn't the problem

<Zeros> that's easy in a hotel

<Hixie> nor is it true that the <input> element in XForms supports legacy content

<Hixie> regardless of the namespace

<Hixie> sending the above document as text/html, i.e. as HTML, shows even more problems: http://damowmow.com/temp/TaxForm.html

<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.

<John_Boyer> water under the bridge though

<Hixie> later

<heycam> but out of it came some useful discussion (for once!)

<marcos> html/irish pub rules: no politics, no religion, no xforms discussions :P

xforms *is* a religion

<marcos> hehe

so is xml

strict html

puppies

and paris hilton.

<heycam> bow down before your well-formed canine overlords

<marcos> I do like puppies but not Paris'

<marcos> I wonder why Dominik Tomaszuk voted no both times in the survey

<marcos> maybe he wanted to be different

voted no to what

<heycam> she has puppies?

<marcos> she has one...

<marcos> I would not classify that dog as a dog though

<marcos> The thing she carries in her handbag is more closely related to a rat

<marcos> omg, puppy mill!

<marcos> I didn't know about puppy mills... that's wrong and sad :(

<anne> some more stuff on www-archive

<anne> http://lists.w3.org/Archives/Public/www-archive/2007May/

<anne> heh, this Gareth Hay is really quite upset

yup!

i do not understand the people who want html5 to not be backwards compatible

<htmlr> http://www.intertwingly.net/blog/2007/05/02/Different-Drummer

<Dashiva> Maybe we should get someone from xhtml2 to come by and advertise for their WG. Seems many people would be happier there.

<schepers> or maybe we should take into account feedback?

<Dashiva> Sure, but when the feedback is "we should make a clone of xhtml2" it feels a bit empty

<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

<anne> The HTML WG is about backwards compatibility schepers

<anne> I'm not sure how it can be about anything else

<anne> No backwards compatibility implies XHTML2

<schepers> I know you're not sure, anne, but I also don't think you're interested in bothering to resolve that uncertainty

<hsivonen> schepers: when people want mutually exclusive things the editors cannot please everyone at the same time

<hsivonen> schepers: that's why consensus doesn't work

<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

<anne> schepers, if you have a clear suggestion to resolve it, please bring it forward

<anne> schepers, I have been unable to do so

<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)

<schepers> anne, I've been thinking a lot about it

<hsivonen> schepers: I know. I'm just saying it won't work here unless some people change their minds.

<Dashiva> I would hope it means _valid_ formal objections, or that FO implies it

<hsivonen> schepers: obviously, if people have mutually exclusive opinions, consensus requires some people to change their mind

<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

<schepers> maybe you can make a stronger case why you're right, better than RTFM

<schepers> and do so politely

<schepers> (you=y'all)

<schepers> and the other side should do the same

<hsivonen> schepers: posts by the WHATWG regulars haven't been +1s but have cited reasons

<hsivonen> (in general)

<schepers> I stand by my comments

<anne> RTFM = Read The Fucking Mail?

schepers: i understand it, i just see no point

<schepers> RTFM as metaphor... the WHATWG spec

schepers: if html5 is not backwards compatible you'rej ust making xhtml2
... so what is the point of html5 then

there's no reason not to move to xml if the syntax is not going to be backwards-compatible

<schepers> I've been thinking of how we can reach a compromise

<hsivonen> schepers: do you find it reasonable to suggest that participants to this WG read the parts of the WHATWG drafts they object to?

<schepers> hsivonen: I find it reasonable for people who want something to be bought into make a case for it

<anne> schepers, what arguments have been unconvincing so far?

<hsivonen> I read that as a "no"

<schepers> you guys are just not listening to what I'm saying

<anne> No, we're reading it

<Dashiva> You aren't saying anything

it's really quite simple though. mozilla, opera and apple aren't going to implement an html5 that is not backwards compatible.

<schepers> ok, ignoring the peanut gallery for a minute, I'm trying to make a point...

<anne> what hyatt said

if the WG wants something browser vendors aren't actually willing to implement... well, they basically just have to give on this point.

is that unfair? maybe.

but that's how it is.

<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

i just see a bunch of people with no knowledge of what it means to have to ship real products

<schepers> in fact, I think that may be the core issue

asking every browser vendor to build in two complete html rendering modes

<hsivonen> I also see a bunch of people who obviously haven't shipped Web software

is insane

it's absolutely batshit insane

<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."

this isn't like quirks vs. strict

<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

<anne> note "existing Web browsers"

<schepers> I understand that the WHATWG spec makes a difference between what is required for authoring and for implementations

yeah, which i think is the reasonable line to draw

but asking browser vendors to build a completely new rendering mode

that parses completely differently

<schepers> but it doesn't provide an incentive to author valid, well-formed content

would really create a mess out of webkit's current html parser

schepers: well (and here's where i'm really going to display my heresy)

<schepers> maybe a good compromise would be to find a way to encourage valid, well-formed content

i don't think valid well-formed content matters

to your average person

they just want to cut/paste some code in, and have it work

if they miss a " here or a > there, who cares

it's not the end of the world

as long as everyone handles the error thesame way

that's HTML

if you want draconian, go with XML

you have the best of both worlds right now basically

you can pick the path that works for you

<Dashiva> I think part of the issue is that they want to pick for everyone else too

<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)

what is your proposal?

<schepers> I'll send it via email, I'm losing patience here

i think the spec can encourage valid well-formed content by stating that tags are bad practice

or by saying that something is not valid

<anne> there are not many technical solutions to the parsing problem

<schepers> night

<anne> the WHATWG people mentioned that more than once on the mailing list already

<anne> simply ignored

i guess what drives me really crazy is that this isn't really even about the language design

this is just about people wanting to force browser vendors to render with draconian error handling

<anne> (note that even for XML you're not required to show an error message)

there's also the problem that i don't want any versioning in webkit for html5

<anne> (you're allowed to render up to where it went wrong)

i don't want to have to put a doctype at the top of my file just to use <video>

or to use a new web form control

the reality is that we're all going to implement this years before msft

and while we're building it, it is simply practical to allow the new features to work from any html file

<schepers> nope...

<hsivonen> conformance is nowhere near as important as the people who want browsers to give incentive by being Draconian make it appear

<hsivonen> and I'm the conformance checking guy

<hsivonen> document conformance that is

<hsivonen> given the legacy Web that we have

i think html5 needs to be able to creep virally into existing documents

stuff like <video> needs to be able to sneak in without forcing an author to redesign the entire surrounding page

<anne> anything else would be a pain to implement too

<anne> certainly not worth the cost

<anne> especially given that the benefits are not really clear

<sbuluf> david, but isn't the case that microsoft decides?

<schepers> so, hyatt, before I hit the sack... how does your perspective differ from Hixie's?

in which area?

my perspective on versioning was pretty different

more in line with chris wilson's

<sbuluf> david, if they do not implement something, or don't do it for years...then would people use it?

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

<schepers> you agree with him on wf2, too, right?

hmm?

what about wf2?

<schepers> I thought I saw you say earlier that you also wanted to adopt wf2 pretty much unchanged, is that right?

do you mean the whole xforms vs. wf2 cage match?

<schepers> right

no i don't think my perspective is the same

i was on the xforms wg for a while

when i worked at netscape

<schepers> that doesn't say much about your current perspective

<schepers> Hixie claims to really like XForms, too, for that matter

my current perspective is that i would actually need to review both specs again more closely

<schepers> (I'm not disputing that claim)

i haven't commented in that debate at all

<schepers> that's why I asked

mainly because i need to be a bit better informed

<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

i think i'd put it this way then:

if xforms was the republican party

and web forms was the democratic party

i'd be a moderate sitting right in the middle

:)

it's not an area i feel very strongly about

i.e., if more xforms features crept into wf2 that would not bother me

<schepers> but neither would you promote it?

xforms has plenty of advocates. i don't think i need to

sebastian, boyer, raggett, t.v. raman

xforms is well-represented here.

i'd try to be impartial is what i'm saying

schepers: i try to be very impartial

but i can't help but have strong opinions on the backwards compat issue

since from a purely technical perspective that would be hellish to implement

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

and we'd break

because somebody got confused and thought they should put it up there

<anne> Editors are not the chairs, nor can they make descisions the majority of the group will disagree with

<anne> They're just doing all the hard work while you read e-mail, or something

but yes, i'm not an ian hickson clone

i have my own opinions

:)

<schepers> I don't doubt that

heck maciej and i got into a nice little argument on the list about versioning

and we work for the same company :)

i have really only seen two big "debates" raging on this list so far

and they basically boil down to xforms vs. wf2

and xhtml vs. html

it is hard for any browser vendor to come down on the side of xhtml or compatibility breaks

because we have to shoulder that cost

<sbuluf> the cost of what? lawsuits?

no implementation

<schepers> development, I'd guess

having to create a brand new html parser/tokenizer

being draconian is not something we could share with the existing code

people have no idea what a nightmare a real html parser/tokenizer is

(or for that matter what a real css parser has to deal with)

<schepers> anne, didn't you write one in an afternoon?

<sbuluf> isn't a strict one easier?

sbuluf: to some degree yes

there are lots of obscure edges though

document.write makes things very compliated

<sbuluf> what percentage would you say (roughly)?

since scripts can document.write more elements and other scripts

and so on

<anne> schepers, our HTML parser took a few weeks (though not fulltime development at all)

i'm not sure anyone has ever really specified the exact "correct" behavior there either

a few weeks to write followed by a million little bug fixes presumably

<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)

:)

script execution is huge

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"

<anne> yes, we're still fixing bugs :)

<schepers> hyatt: I don't understand your stance on versioning, if you don't want different rendering modes

in a way that's how the whatwg stuff came about

to try to actually figure out what the behavior is supposed to be

schepers: my stance was that the spec should not dictate rendering modes

other than to say that the doctype would mean you are an html5 document

like the spec would say "this doctype identifies html5"

<sbuluf> david, but i was asking what percentage a strict parser would be, compared to a non strict one. or am i missing something?

but it would not say "if that doctype is not there, user agents can't treat the doc as html5"

sbuluf: i'm saying i can't even tell you because often we don't even know which parts are "strict"

nobody has even defined what a strict parser would be

<sbuluf> david, in say xhtl?

could we be strict about open/close tags, balanced quotes, etc.?

yeah pretty easily

<schepers> isn't the point of the WHATWG work that it shouldn't matter what "version" of HTML is... they all render the same?

schepers: not quite

<anne> sbuluf, there's not much difference in my experience

the point is that html5 should degrade gracefully in browsers that can't handle it

it can do that even with a subset of the elements if well defined

<sbuluf> anne, thanks.

<anne> sbuluf, error handling in tokenizing / parsing doesn't actually require extra code

residual style does

<anne> yes

that's the big error handling problem

<anne> that's the exception, but you wouldn't have to do that for XML with error handling

right

<sbuluf> residual atyle?

<sbuluf> (david, thank you too, btw)

http://ln.hixie.ch/?start=1037910467&count=1

the "tag soup" problem

<schepers> but you're also advocating bleeding video (presumably other elements) into other (non HTML5.0) documents.. so how does a version matter?

schepers: i have no idea if this is part of the html4 spec or not, i'd have to go research

but basically existing browsers all parse tags they don't understand

and still put them in the document tree

<schepers> sure

so if you design the new elements to degrade

you can use html5 elements safely

but yes, i as an alternative browser vendor, do not want to have an html5 mode

<anne> the think the point is that he's ok with browsers having an html5 mode and that the spec should not forbid that

right

i think it's totally ok if a browser *does* decide they won't render html5 unless the doctype is there

<schepers> I get that, but I don't understand what version="5.0" would *do* in your scenario...

some people were trying to say that a browser should not do that

<schepers> ahhhhh

<schepers> ok

i basically was defending microsoft's position

because i do have a funny story about that

safari 2 introduced a custom form control

to do apple's search field

the rounded one with the magnifying glass

we used <input type=search>

and were very proud of ourselves because it would degrade to text fields in other browsers

until of course we hit a real-world web site that accidentally said type=search instead of class=search

so adding new attributes/elements to the language can potentially break things

so i am very sympathetic to microsoft's position

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

if msft want to opt-in to html5 then that is their right

wans

argh

wants

can't type.

<anne> http://diveintomark.org/archives/2007/05/02/silly-season

<schepers> ok, that clears it up, thanks

anne: i saw that

schepers: hixie and mjs were basically (i think) arguing against versioning at all

<Lachy> would it have really been a problem if an author accidentially used type=search, instead of class=search?

Lachy: it looked pretty ugly

:)

but yes, it was a minor league misrendering

you could imagine a more dramatic one

the sad reality is sites invent tag names all the time

and use them as delimiters and placeholders

but the new features are not where msft would have to worry

it's stuff like changing their parsing model to be like web apps

if they solved the residual style / tag soup problem as per the spec

then sites would break guaranteed

<Lachy> how?

sites rely on IE's precise error recovery

it's sad but true

we have lots of bugs on this still

<Lachy> I just can't see how any site could rely on a non-tree structure

it's sad

pathetic even

sites pathologically nest without knowing it

the web apps spec encourages pathological nesting in certain scenarios

<schepers> mashups get even worse

and the residual style algorithm in the web apps spec can turn into O(n^2) in the depth of nesting and blow out

<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

<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.â€"

<anne> comments are priceless too

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

we have things in the webkit engine we couldn't change

fortunately we're much less constrained

people also forget that in the case of webkit and trident

<sbuluf> i thought microsoft given reason, however, was not cost of implementing, but lawsuits

we are used for many apps on the system

and changes don't just break the web

they can break apps in your os

that's a big deal

for example for webkit, the behavior of css2.1's inline-block is actually hard for us to change

because it's so heavily used in OS X

even though it's non-existent on the Web

so we're even constrained in crazy ways

fix a bug in display:compact, break XCode, wtf.

basically i just don't think the spec should dictate to the vendor how they should opt in to html5

<xover> Your arguments seem to be in the opposite direction of your conclusion?

my argument is that IE should be allowed to opt in to HTML5 via a doctype

and they should be free to ignore HTML5 tags/features if that doctype isn't there

<Lachy> yeah, I'm ok with them opting in with the DOCTYPE

or via some rules they define

<Lachy> it's not ideal, but I can live with it

i don't plan to do that with webkit

we'll just happily support the html5 features in all html

<xover> Oh, you mean the opt-in should be specified, but not mandatory? i.e. it's a MAY not a SHOULD or MUST?

<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

yeah exactly

Lachy: i think that would suck yes

<xover> AH, that makes sense then. Sorry to be so dense. :-)

Lachy: but in the end there's nothing the WG can do about that

xover: np :)

Lachy: it's a moot point since we'll all be writing XAML for silverlight in 5 years anyway

;)

<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

the safest thing for them is for all existing web pages to render as before

it's an extremely conservative position, but with 80% market share and a whole OS that uses their engine everywhere, it's understandable

<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)?

<xover> And doesn't it then follow that you actually need explicit versioning that can distinguish e.g. 4 from 5 from 6?

xover: well, ignoring the details of error recovery and parsing and stuff like that

the new tags/features are designed to degrade gracefully anyway

and specifically tested in WInIE to make sure they do so

this is the spec's way to deal with this problem somewhat

xover: but yes 6 may need an opt-in from msft too

that's why i argued that we should say "5.0"

and be clear about it

in case we do have a 5.1 and msft needs to opt in

etc.

<Lachy> 6 shouldn't require an opt-in, because the parsing requirements shouldn't be changed at all, except to handle the new elements

<xover> Ok, but do I then understand that you are in favor of versionning? Or would that be to put your position too simply?

<Lachy> and they mostly want the opt-in to work around the CSS and DOM limitations anyway

yeah it's funny, css/dom/js all create much bigger headaches

html is actually pretty minor league compared to those

<sbuluf> even considering tag soup?

<Lachy> yes, it's the CSS issues that can significantly break a sites rendering

<xover> hyatt: "No comment" on my questions above (inbetween Lachy)?

<sbuluf> i see.

<anne> sbuluf, parsing is not big of an issue

<anne> when people talk about "tag soup" they don't really talk about parsing I think

<anne> they mean rendering differences

<anne> because that's what they see

<anne> and rendering differences is CSS

<sbuluf> anne, i think i see, thanks.

which question?

<xover> «Ok, but do I then understand that you are in favor of versionning? Or would that be to put your position too simply?»

i am in favor of identifying the version

so that someone who wants to do something with it can

so, yes, i guess you'd say i'm in favor of versioning.

<sbuluf> (unless that third S was not a typo9

<xover> Hmm. Thank you.

<xover> On a side note, I actually find that quite reassuring.

<sbuluf> philip, oops! (b/w small old monitor here, thanks.)

schepers: but anyway my long-winded point was that i don't always agree with hixie :)

<xover> Heresy!

<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

<sbuluf> probably ignorance on my part

<Lachy> lol, another no vote: "I would prefer 5.01"

<Dashiva> That's a valid technical argument... I think...

<Lachy> there's no justification, it's just based on personal preference

<Lachy> it's not a technical argument at all

<Dashiva> Maybe it's to put a w3c stamp on the version number, since whatwg stole the plain 5? :)

<Lachy> the WHATWG didn't steal HTML5, ti's what the community started widely using, and so it was adopted

no vote where

<Lachy> http://www.w3.org/2002/09/wbs/40318/htmlbg/results

is there some voting page somewhere i should be looking at? :)

82 to 2!

hahahaha

that is what i call consensus

<Dashiva> Has anyone tried contacting the guy who put no without justification?

<Lachy> one of them is Boyer who cites bogus reasons, and the other has no justification

<Lachy> don't know

<Lachy> probably not

<Lachy> but since providing justification was a requirement, his vote will be ignored completely

<anne> John Boyer was contacted, www-archive

hahah on the question of whether hixie and i should be editors

"Would prefer just Hixie, but this appears to be the next best thing.

"

" 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)."

<sbuluf> i think it should be html 5.2, for historical reasons

i wonder if that is my mailer?

yeah i guess it is

mail.app puts your caret at the top

lots of other apps put the caret at the bottom

<Lachy> yeah, hyatt, don't top post!

<Dashiva> Bad app!

i assume that is what he means

i also write responses in like 5 mins and don't proofread them

which i guess is bad

<Dashiva> Also that your post is separated from the quoted context

but otherwise i'd never get anything sent

<Dashiva> Non-conformant English will not be displayed

lol

then sees something to respond to

dashes off a response

then resumes coding

maciej gives much better responses than i do

he actually sits there and writes them all up

but then again it's consuming like his whole day!

my poorly-constructed ramblings have their place. :)

<anne> it's called "manager" :)

<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

<Lachy> They seem to be jumping to a solution, without actually clearly defining what the problem is

<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"

<anne> maybe they're thinking in popular software paradigms

<Lachy> like what?

css3 is modular

<anne> modular approaches

look how thats turned out

kind of a mixed bag

<anne> hyatt, yeah, case in point :)

<anne> XHTML Modularization would be another one

<Lachy> CSS3 is at least split by the features, not conformance criteria

but a lot of that has to do with the css wg focusing so much on css2.1

<anne> you basically need a few people to do a lot of work

<anne> otherwise it will never happen properly

we've nearly fully implemented css3 background/border

would love to see that move forward

<Lachy> awesome

i think the only properties we haven't done

are the background-break, border-break ones

<Lachy> have any other UAs implemented it?

<Lachy> or started?

but we've done multiple backgrounds, border-radius, box-shadow, background-origin, background-clip, and background-size

<anne> border-image too

<anne> right?

yeah we've done border-image too

yeah i guess we should beef up selectors

i'm so anti-selector-proliferation

since i find so many of the new ones to be kind of questionable

i hate selectors that can't resolve properly on a forward incremental parse

like: last-child

you risk showing content in the wrong state if the page loads incrementally

<Lachy> yeah, how do you work around that?

you don't

<anne> the only workaround is not doing progressive rendering at all, which is silly

you just hope you're not on one of those unlucky boundaries when you decide to paint :)

<anne> but :last-child is useful

sure

i'm just grousing

our engine resolves style as it goes

so this is a weird case where you have to guess wrong and then backtrack

<anne> if :matches($ > foo) or whatever the latest proposal is goes in we'll have bigger issues

is that the parent selector?

<anne> yeah

yeah no way

<anne> heh

i won't implement that

i don't think there's even a good use case for it

<anne> the use case is lack of better elements

<anne> like styling <img> when it's the sole child of <p>

<Lachy> many of the use cases for parent selectors could probably be handled by ::outside or XBL

<anne> -> <figure>

it's called the class attribute.

;)

<anne> hehe

i can't speak for opera

but for both mozilla and safari

<anne> I believe some people rather use lots of complicated selectors than resorting to class or ID

class selector = far and away the fastest way to match

(id/.tag too of course)

<anne> I suppose that's the case for us as well, otherwise we'd be having performance issues

anyone writing a page that they want to be really fast and efficient should just use class

in fact in safari we even optimize if the page has no descendant selectors

since we know we don't have to crawl around in a subtree when ancestors change

which can be the difference between using 50% cpu and using 2% cpu

<Lachy> how often would you get CSS that doesn't use any decendant selectors?

especially when sites (I'm looking at you orbitz.com) are buggy and fire JS timeouts every 10ms in an infinite chain unintentionally

<anne> Lachy, lots of people simple use tag / .class / #id

<anne> simply*

yeah lots of people don't use them

which is good

<anne> as opposed to using a more complicated selector they would use an extra class

people have a tendency to write selectors with more info than they need too

i love it when i see stuff like this:

div > img.photo

when all they needed was .photo

stuff like that

it's really common to see people write tagname.classname

when all having the extra tagname there does is force the browser to do two checks instead of 1

<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)

<anne> oh, you didn't mean the CSS WG?

<sbuluf> very flexible yes. but...what about the costs?

unintended consequences are the subject of lots of bugs unfortunately

especially with the proliferation of css hacks

people will use advanced stuff that only works in one browser

and then break when things change

a great example is yahoo

they broke safari

because they were identifying opera by looking for media queries

when we implemented media queries suddenly they decided we were opera

so we broke

ridiculous stuff like that

css hacks are just awful

<anne> it's annoying browser checks are required

it is

but as long as we're all buggy it's not surprising. :)

ugh 4am here i should not be awake

night

<sbuluf> (i wasn't even thinking about hacks. just much more basic stuff)

<anne> people just copy and paste

<anne> and it all sort of works

<anne> in an "ugly" but convenient way

<sbuluf> copy and paste...code? templates?

<anne> everything

<sbuluf> later

<Lachy> woah, I'm just shocked Jukka Korpela's most recent post. That's not something I really expected to hear from him

<anne> heh, he's arguing for XHTML2

<anne> which he also dislikes

<Lachy> I know

<anne> I wonder if he realizes that the problems he's enumerating also apply to DOM, CSS, etc.

<anne> XML attribute-value normalization is silly

<anne> it basically requires a lot of extra characters for the common use case

<Lachy> I'm not familiar with how it works

<anne> If you want a newline, you need to use a character reference

<Lachy> isn't in the same in HTML?

<anne> HTML preserves all characters

<anne> implementations do, anyway

<Lachy> Firefox doesn't

<Lachy> I think Opera does

<anne> HTML5 does

<Lachy> yeah, IE and Opera preserve new lines

<hsivonen> Lachy: Firefox does for at least the attributes where it matters in practice (in text/html)

<hsivonen> Lachy: Jukka Korpela in general has a pretty strong view of what specs are legitimate standards

<hsivonen> Lachy: (in the direction of emphasizing that ISO can issue standards and the W3C can issue RECs)

<hsivonen> Lachy: (hence, I am not surprised that he doesn't appreciate CSS3 modules that aren't RECs)

<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

<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

<Lachy> I know he's repeatedly stated how XHTML 1.1 was an exercise in futility, and actively encourages the use of HTML4

<anne> http://lists.w3.org/Archives/Public/public-forms/2007May/att-0012/20070502.html#topic8

<anne> Do you need to officially sign up somewhere?

<anne> If we really need a task force, I think I want to be in it

<Lachy> I'm not entirely happy about working with the XForms group, but yeah, we definiately need to be involved.

<anne> One of their members does the minutes

<anne> I suppose you could request some enhancements from krijnh

<anne> weird, my e-mail got through

<anne> did you cc public-html?

<Lachy> either resend it there or to www-archive

<anne> so maybe that's why my messages got through

<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)

<anne> that's another option, yes

<Lachy> www-html should be made opened up to everyone without subscription, like www-validator is

<Lachy> hmm. weird. You could email sysreq@w3.org and ask them for assistance

<olivier> Lachy: I am not sure why www-html is still using that old moderation system

<olivier> I'll ask

<olivier> AFAICT it should have the same setup as e.g www-validator

<Lachy> good examples and explanation, except that the last one is non-conforming as well

<Lachy> <b> can't contain <script>, which it would when script is enabled.

<anne> your last example is in error

<anne> i think

<anne> but that doesn't really matter

<Lachy> oh, sorry, my mistake :-)

<anne> maybe it should require <script> independence

<anne> nah, nm

<anne> over engineering + obvious flaws

<Lachy> not sure what you meant by script independence

<anne> when an individual script is executed (but not the others) the document should be conforming

<anne> damn, Metroid Prime 3 isn't out yet?!

<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

<anne> guess that means I could start finishing some books

<Lachy> what's Metroid Prime 3?

<anne> http://en.wikipedia.org/wiki/Metroid_Prime_3:_Corruption

<Lachy> that's why there's the note about the halting problem in the spec

<anne> the UA can check those during runtime

<anne> in theory

<Lachy> yeah, taking checking a snapshot of the DOM is always possible

<anne> not all variants, but certainly the code path executed

<anne> parse errors can be detected by a UA as well during runtime

<Lachy> the parser would emit parse errors as it parses anyway

<anne> but only for the applicable code path

<anne> with applicable code path I meant that user interactions or script nonsense could execute different functions that do different things

<anne> so it's not likely you check all of the script

<anne> i'm not sure how much of a performance hit reporting the parse errors in some console is

<anne> which i suppose, is the halting problem :)

<anne> presentational markup

<anne> i think i'll just go silent for now

<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

<hsivonen> Philip`: it doesn't follow though, that it would make sense performance-wise to run it all the time

<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

<Lachy> .. one that checks on request, of course

<hsivonen> Lachy: yeah, worth doing

<zcorpan> when gecko implements an html5 parser it could probably easily log html parse errors to the error console

<Lachy> that would be nice

<Lachy> I'm still waiting for Opera to start logging errors to its console

<hsivonen> Lachy: I suggest starting with figuring out how to run the Etna RELAX NG engine inside a Firefox buil

<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

<zcorpan> i don't understand dave r's arguments for modularizing the spec at all

<Dashiva> Spec big. Confuse Thog. Thog head hurt.

<zcorpan> how is that different from "many specs"

<zcorpan> i don't see how it would reduce confusion at all

<zcorpan> or help writing test cases

<zcorpan> or anything

<zcorpan> all i see is that it would be more work for the editors

<zcorpan> and the whole thing not being published as a rec doesn't mean it won't be adopted

<Dashiva> As I understand it, they consider everything outside conformant document requirements to be irrelevant

<zcorpan> they are irrelevant to someone who won't implement anything

<zcorpan> that's why i'm working on this style sheet

<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)

<zcorpan> http://lists.w3.org/Archives/Public/public-html/2007JanMar/0096.html

<anne> you know, after debating a while on presentational markup it's no longer clear to me what the point of doing that was

<anne> and the point was to get agreement on design principles

<anne> but that seems entirely lost

<hsivonen> it seems that Philip Taylor not only wants to ignore browser vendors but wysiwyg editor vendors, too

<hsivonen> I wonder what enforcement mechanism he has in mind to get his vision implemented

<anne> A hammer

<anne> Actually, that will just make me run away

<anne> Maybe a cage and a hammer

<hsivonen> how do I address lists.w3.org messages by message id?

<anne> x-archive-at header in the e-mail

<anne> or

<anne> copy the id mentioned on the site

<anne> and place it after www.w3.org/mid/

<mjs> catch you guys later

<hsivonen> anne: thanks

<anne> mjs, bye!

<mjs> hopefully an hour on the train will be enough time to catch up on htmlwg flamage

<anne> hsivonen, I'm actually not sure it's the better URL

<mjs> I also have to post something about forms

<anne> mjs, :)

<anne> hsivonen, but it seems to be

<hsivonen> anne: I used the URL from the header

<hsivonen> one of the practical things I was unaware of

<anne> heh

<anne> the access people think <i> means inaccessible

<anne> bet they never talked to TV Raman

<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.

<anne> i'm talking in multiples again

<anne> it was a single person

<anne> sorry

<anne> DanC, I think you should guide the discussions more

<DanC> I'm maxed out

<anne> DanC, at least try to indicate the scope a bit better

<anne> because currently it seems like we can still go down the XHTML2 route

<anne> which I don't think is what the charter wants, nor we

<DanC> I'm not going to repeat myself. that doesn't set a good example.

<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.

<anne> I don't see how it's worth everyone's time

<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.

<anne> there's lots of people on the list, that's a lot of money

<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

<DanC> exactly, Lachy . We're close on one.

<anne> meanwhile WHATWG has specced <video>, <audio> and lots of other things

<DanC> "I don't see how it's worth everyone's time" <- "it" refers to what? surely backing off from discussion costs zero.

<Lachy> DanC, do you expect John Boyer's formal objection to have any serious impact upon the adoption of HTML5?

<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.

<Lachy> people should have already started reviewing it.

<Lachy> how can people vote yes or no on something they've never reviewed, at least a high level review

<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.

<Lachy> a lot of people are just objecting to things they just don't understand, which is a problem

<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."

<Lachy> I don't agree with requiring test cases for everything

<anne> people should cite sound technical arguments

<DanC> I'm interested in other ideas to address your "people are just objecting to things they just don't understand" concern.

<anne> dunno, how do you usually deal with non-experts in a group?

<DanC> I make them focus on test cases.

<anne> fair enough

<DanC> well, story telling (use cases) and test cases.

<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

<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

<Lachy> I'm just not sure how to get the group to do that

<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.

<DanC> likewise "your message doesn't cite a section of the spec"

<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

<Lachy> i.e. I think we should add a <table3> element, here's a test case!

<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.

<Lachy> asking them to cite specific sections of the spec is good

<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

<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]."

<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

<anne> books

<anne> classes

<anne> tutorials

<anne> using it in sites

<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

<DanC> I'd like people to appreciate that the spec writing is a tiny fraction of the cost.

<DanC> and that having a feature in a W3C Recommendation is rarely enough, on its own, to get something deployed

<anne> also considering we're doing standards, not innovation

<anne> we're specifying features multiple people want to implement interoperably

<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

<anne> <canvas>?

<DanC> using that example would surely get plenty of attention

<anne> prolly the most successful new element since a long time

<DanC> it's more controversial than the sort of thing that usually works well in a wiki

<DanC> the story of <canvas> might fit better into a blog item

<DanC> well, I'm off to lunch

<anne> besides that and Web Forms 2 I can't help you

<Lachy> maybe some of the new form controls?

<anne> when I "joined the web" HTML4 was there

<DanC> <img> and <form> are the new features that I was involved in.

<DanC> the cost wasn't so high back then

<DanC> most of the new features since then have been in CSS

<anne> otoh, it overloads <a>, but from a compat perspective it's quite good

<anne> SVG is going modular

<anne> filters is first

<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/

<anne> that's already three docs for one module

<anne> and a shitload of DOM interfaces too

<anne> whoa

<anne> http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#DOMInterfaces

<anne> cool, it has ImageData which is compatible with HTML5

<anne> now that's nice

<anne> (given that it works)

<anne> oh i see, those interfaces are basically tied to the elements so each element gets an interface

<anne> i like that too

<anne> you can get impl fixes

<anne> fixed*

<anne> or did you already raise issues?

<anne> filter stuff is complicated though

<anne> separaring how to parse the syntax from the HTML specification

<anne> now that's a good idea

<anne> actually, I'll wait for a volunteer

<gsnedders> +1

<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

<mjs> zcorpan_: oops

<mjs> zcorpan_: will follow up

<mjs> anne, Hixie: I'd love it if one of you could review WF2 against the list of proposed forms architectural consistency requirements

<Hixie> is there a mail on that?

<Hixie> oh blimey, i have hundreds of mails

<mjs> Hixie: I sent the requirements w/ the subject "Architectural Consistency Requirements for Forms"

<Hixie> k

<Dashiva> Opera has a reparse as HTML button

<Hixie> and mobile browsers other than opera uniformly treat all XHTML as tag soup

<mjs> I think I mentioned mobile browsers

<mjs> didn't know about Konqueror

<Hixie> i didn't see your e-mail, was just commenting on the above

<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

<mjs> I thought they had an XML parser

<mjs> I'd be surprised it they don't use it for application/xml at least

<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

<zcorpan_> can anyone test http://hsivonen.iki.fi/doctype/test-quirks.php?doctype=%3C%21DOCTYPE+html%3E with konq?

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.97)

Succeeded: s/hink/think/
Succeeded: s/diff/diffs/
Succeeded: s/are actually/aren't actually/
No ScribeNick specified.  Guessing ScribeNick: hyatt
Inferring Scribes: hyatt

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: DanC Dashiva Hixie John_Boyer Lachy MrNaz ROBOd Sander Shunsuke Zeros Zoffix anne billmason briansuda dbaron edas gavin_ gsnedders h3h hasather heycam hober hsivonen htmlr hyatt kazuhito loic marcos mjs mw22 mw22_ olivier sbuluf schepers schepers_ tH xover zcorpan zcorpan_ zdenko
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2007/05/03-html-wg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)