SV_MEETING_TITLE -- 2 May 2007

<mjs> so much scrollback to read

<Hixie> i'm really starting to think that john boyer isn't discussing the form issues in good faith

<schepers> why do you say that?

<Hixie> because he keeps asking what's wrong with xforms, but always ignores the replies, and never response to questions about what's wrong with web forms 2

<Hixie> furthermore, he repeatedly has stated incorrect facts about web forms 2

<Hixie> despite having been corrected multiple times

<schepers> he may not have understood

<Hixie> then he should say so

<schepers> you don't always know when you've misunderstood something :)

<schepers> but he may be looking at it with XForms-colored glasses

<schepers> or, as you say, he may be operating from vested interests (as are the browser vendors)

<Hixie> i have no objection to him operating with vested interests. But there's no point having a discussion if one of the people in the discussion isn't actually interested in using logical, fact-based argumentation.

<schepers> fair enough

<Hixie> mjs: when you do the line count stuff, you have to add up html4 + dom2 html + xhtml1

<Hixie> vs wf2 + wa1

<zcorpan> html4 refers to sgml for parsing, so...

<Hixie> as it's important not to forget xhtml1 :-)

<Hixie> hm

<Hixie> i guess you could indeed argue that you should also include sgml

<zcorpan> hmm, html4 has many normative references

<zcorpan> esp [HTML40] surprised me for being normative

<Hixie> html4?

<zcorpan> yes. http://www.w3.org/TR/html401/references.html

<Hixie> weicd

<Hixie> weird even

<xover> Hixie: You can and should include SGML.

<Hixie> in the count of lines that html5 is replacing?

<xover> yes

<Hixie> that's what, 500 pages?

<xover> And this is the biggest fundamental problem with html4 IMO; the lack of public (web) availability of the ISO 8879 spec.

<xover> Summjat like that, yeah.

<Hixie> so html5 is like a third of the size of the specs its replacing

<Hixie> wow

<xover> Quite likely, yes.

<xover> But note that that's not /necessarily/ a compliment.

<Hixie> given how much more detailed html5 is, i'll take it as one :-)

<Zeros> SGML is quite a bit more complex than html5

<Zeros> If you bundled all the previous CSS and DOM specs and the HTML5 spec that'd be pretty dense too

<Zeros> hmm. call it "Web Platform Specification" and charge $99 per copy and you have ISO

<schepers> that size comparison is not quite fair

<schepers> the mode for those specs was to reference other specs, to build on technologies

<schepers> you are simply taking all the relevant parts and putting them in one place

<Hixie> yeah, sgml is equivalent to xml

<Hixie> not xml+dom+css+...

<schepers> not that that's bad

<xover> I sincerely hope HTML5 tries to stand on various proverbial shoulders here!

<Zeros> Hixie, sgml defines quite a lot more than xml

<Hixie> not really

<Zeros> I was talking size though

<schepers> I'm just saying it's not a true comparison

<xover> schepers: No such comparison could be claimed to be "accurate". But I think, put in context, it can be an _apt_ comparison.

<Zeros> Hixie, if that were true then there'd be no need for xml, we'd just use sgml

<schepers> apt to what?

<schepers> I mean, what are you claiming it says?

<Hixie> Zeros: sgml defines a syntax. xml defines a syntax. it just so happens the sgml syntax is way more expressive.

<Hixie> Zeros: they're still equivalent technologies

<Zeros> Hixie, Um, equivalent in the way that csv is the same as xml I guess.

<Zeros> one is just more expressive

<Hixie> right

<Zeros> That wasn't the parallel I was trying to make though

<xover> schepers: It illustrates, for instance, the point that HTML5 â€” whatever else one may think about it â€” does go to great lengths to specify parsing rules that HTML4 handwaves somewhat to SGML.

<xover> Which, btw, is an argument both pro and con the HTML5 approach in my book.

<schepers> huh? how does the length of a spec have any bearing on that, xover?

<xover> Strictly speaking it doesn't; it "illustrates" it, not "proves" it.

<xover> Of course, the mere weight of lines is one of the reasons I'm still on the fence.

<schepers> I didn't say anything about "proof"... anyway, nm, it just struck me as a silly exercise... carry on

<xover> Then we're in agreement. :-)

<schepers> I doubt that :)

<xover> Or perhaps "instructuve" would be more appropriate.

<Zeros> hmm, html5 is 211 pages

<Zeros> not including web forms

<Zeros> and its not done yet. Doesn't seem that much smaller

<Hixie> it's not far from done

<Hixie> other than the rendering section, i'd be surprised if we added more than 50 pages

<Hixie> the rendering section might be 50 to 100 pages of its own

<Hixie> we have to add wf2, though

<Hixie> but don't forget that it replaces sgml, html4, dom2 html, and xhtml1, all at once

<Hixie> which together probably add up to 2000 pages or more

<Zeros> part of that is related to whitespace

<Zeros> HTML5 is very very dense

<Zeros> I think the HTML4 spec is much easier to read too honestly

<Hixie> it would be easy to make the html5 spec easier to read if it failed to say anything like html4 does...

<Zeros> that's no reason for it to be so dense

<Zeros> http://www.w3.org/TR/html401/struct/links.html#h-12.2 => http://www.whatwg.org/specs/web-apps/current-work/#the-a

<Zeros> The definition of the attributes is clearly defined in a nice list there. Separated and easy to approach. You have it buried in paragraphs of text.

<Hixie> the list of attributes in the html4 spec says almost nothing normative

<Hixie> we can certainly add more (informative) text to the spec at some point when it's stable

<Hixie> but that's not spec material

<Hixie> and the html5 spec has a little contents list for jumping to the attribute definitions, if you actually want that

<Zeros> It's not just that. The organization of the spec is dense

<Zeros> If you don't know what you're looking for the HTML5 spec requires a lot more reading to find anything useful.

<Hixie> that's because there simply isn't anything useful _in_ the html4 spec

<Hixie> so if you want to find something useful in teh html4 spec, you can immediately know it's not there without looking

<Zeros> hah

<Zeros> you're way too biased

<Zeros> and much too close to the HTML5 spec to see how dense it really is. The person writing it understands it clearly. Of course it makes sense to you.

<Hixie> well, i'd be happy to rearrange the html5 spec to be easier to read, if you have any concrete suggestions

<Zeros> Hixie, break out the attributes into lists with nice headers. Starting the definition inline and making it red requires more scanning.

<Zeros> hmm, the Media Query [MQ] links don't work in Safari

<Hixie> the [...] links don't work at all, i haven't done the references section yet

<Hixie> the attributes wouldn't work that way

<Hixie> e.g. the link attributes are defined in an entirely different section

<Hixie> and some of the attributes have multiple definitions depending on the other attributes

<Hixie> generally i don't like keying things from attributes, because the attributes aren't what matter

<Zeros> Right now trying to find information about an attribute is a lot of work

<Zeros> Where do you define that an attribute is optional unless it says "required" next to it?

<Hixie> attributes are optional or required based on what it says next to their definition

<Hixie> the (required)/(optional) stuff is old and will all be removed

<Hixie> because it's often wrong

<Hixie> usually an attribute is required if something else applies

<Hixie> e.g. "one of these attributes must be present"

<Zeros> That's not very approachable to have to dig through a paragraph of prose to figure out if something is required or not

<Hixie> i don't really know how else to do it

<Hixie> attributes aren't just optional or required

<Zeros> Some are defined that way. It says the src attribute is required

<Zeros> You also jump around in the prose which makes it hard to find what you're looking for. It goes from talking about the src attribute, to talking about alt, to talking about the src attribute again

requiring src doesn't always make sense for <embed>, if type is already present for instance

<Hixie> <img src>?

<Zeros> yes, not embed

(same for data and type on <object>)

<Hixie> yeah, <img src> might be required. that's one of the few ones.

<Hixie> but why would anyone need to know that src= was required?

<Hixie> it's not like they're going to use it without

<Hixie> the element is pretty useless without

<Zeros> that's a pretty big assumption to make

<Hixie> is it?

<Hixie> doesn't seem so to me

<Zeros> <img id="foo"> lets set it with JS later

<Hixie> that's a good arguemnt for not making src= required

<Zeros> yes

<Zeros> its a good argument for being explicit

<Hixie> explicit about what?

<Hixie> you just argued it shouldn't be required

<Zeros> About if something is required or not and when

<Hixie> well, it _is_ explicit

<Hixie> it's just not in note form anywhere

<Hixie> the problem with note form is that for more attributes you'd have to say "see prose"

<Hixie> because the rule would be complicated

<Zeros> It says its required right now, yes.

<Hixie> anyway, i gotta go home

Zeros, wat are you arguing for?

<Zeros> I'm not taking about img specifically though, I'm talking about the spec itself

<Hixie> i recommend sending concrete suggestions to whatwg@whatwg.org

<Zeros> the usemap attribute is defined in the middle of a paragraph

<Hixie> so that i can fix the spec

<Zeros> ok

<Zeros> anne, organizing the spec better

<Hixie> but before i go i'll just reiterate that i don't really consider attributes important

<Hixie> i think that considering the spec to be a description of elements and attributes is one thing that made html4 as bad as it is

<Hixie> (as opposed to making it a description of a language that happens to have elements and attributes)

<Zeros> There needs to be some middle ground

<Hixie> i'm not even really convinced that having sections per element is a good way of doing it

<Hixie> e.g. <Legend> doesn't really work having its own section

<Hixie> it should be defined in the <details> section and the <fieldset> section

<krijnh> (Sorry for not updating the logs yesterday - my connection dropped)

<Hixie> anyway really gotta go

<Zeros> later

Dmitry Turin seems to want declarative features as well... it's funny how he seems to ignore all main threads and just does a bunch of fature requests

<Zeros> Be nice if we could get past finalizing editors, adopting the spec and other matters first

It would be nice if the design principles were settled upfront

Would've saved us all quite some time

And if people read the spec and don't assume that browser vendors are evil

<Zeros> there is some reason to be apprehensive with respect to browser vendors

<Zeros> evil, no. Business, yes.

I'm not sure how you can do much innovation without business involved

(not that this is about innovation)

<hsivonen> come morning and we have a formal objection from John Boyer

<hsivonen> and unlike Gareth Hay, he objects to the choice of editors as well

heh

pointer to the survey?

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

"Regarding the Forms component of HTML 5, the HTML and Forms working groups are chartered to work together on forms that align with XForms."

lol

we're not

<Lachy> there is no way I would be happy with having someone from the XForms working group be an editor for WF2 for the reason John Boyer stated. Editors should be chosen on their own merits, not their association with other groups

hmm, Julian Reschke seems to confuse the Atom MIME type with what's being used for Atom

oh well

<hsivonen> Lachy: what if Hixie joins the forms WG?-)

<Lachy> that would be fine, he has been chosen based on his own merits

<hsivonen> Microsoft hasn't, either

<Lachy> we can fairly safely assume that Opera will vote yes

<Lachy> I'm not quite so sure about MS, but given Chris' earlier response on the list, whcih was fiarly positve, they'll most likely vote yes to

when does the voting close?

<Lachy> Friday night, Boson time

oh ok

I'll check with lbolstad tomorrow then, no rush

<Lachy> I'm trying to think of a few examples of non-backwards compatible changes to help explain the difference between back compat and graceful degradation. Any suggestions?

<Lachy> I have one: renaming <script> to <handler>

<Lachy> (borrowed from XHTML2)

<Lachy> ah, redefining the <label> element would be another good one :-)

<beowulf> gareth hay's recent email is annoying

<beowulf> i'm a newcomer, i've asked for explanation of a lot of things, browser vendor types have been very courteous in dealing with my ignorance and on the other side of the fence i've been flat ignored twice

<hyatt> honestly i don't even know what we're arguing about any more

<Lachy> beowulf, you'll find that's because they don't actually have any technical arguments to back themselves up, just more moral-based, or fallacious arguments

<beowulf> Lachy: that appears to be true

<hyatt> i don't understand the aversion to defining error handling behavior

<Lachy> the problem is trying to get them to realise that, without getting to impatient and angry with them

<hyatt> i haven't gotten impatient/angry at all

<hyatt> but i also feel like i'm just talking to people who don't really pay attention to logic

<Lachy> hyatt, I didn't say you did

<hyatt> i feel like i'm talking about religion or politics

<hyatt> with some die hard believers

<hyatt> in a certain way of doing things

<beowulf> yup

<Lachy> +1

<Lachy> :-)

<hyatt> whereas i just want to have my browser that i work on actually render web pages

<hyatt> and if that means defining error recovery to be like winie to help me do that, whats the harm

<beowulf> i need your browser to render pages, inaccurate ones, badly written ones. I wrote some of them.

<hsivonen> hyatt: it seems to me that some people have totally failed to realize the importance of legacy content in browser competetition. for some reason, the significance of legacy content is understood much better by those who discuss word processor formats.

<hyatt> i think the point of confusion

<hyatt> may just be that people think that we want this error handling to somehow imply these bad documents are ok

<hyatt> they're not ok

<hyatt> they're still bad content

<hyatt> but why not define how to handle bad content

<hyatt> css does

<hyatt> why shouldn't html

<Lachy> anne's last email was a good one! :-)

<Lachy> now to read Gareth's reponse...

<hyatt> honestly i'd even be ok with making an html5 spec that was pure for the w3c

<hyatt> and just overlaying in the whatwg stuff

<hyatt> in the whatwg's doc

<hyatt> but all that would do is cause everyone to view the whatwg's one as the official doc

<hyatt> and the w3c one as the lame subset

<Lachy> that would basically make the W3C's spec irrelevant

<hyatt> would just further cement the whatwg's status as the true designers of html5

<Lachy> I would rather suggest that certain objecters move over to the XHTML2 WG, who share many of the same opinions with them.

<hyatt> this is such a weird situation

<hyatt> having two groups both doing html5 at the same time

it's not clear yet what the HTML WG will be doing...

<hyatt> wasting time in email apparently

<hyatt> instead of working

yeah

not sure who's to blame

<hyatt> i may just stop responding

prolly the W3C for not getting the charter right

<hyatt> majority clearly supports whatwg's position

<hyatt> so no real need to continue to argue

and maybe the browser vendors for not demanding a more accurate charter

you got a point there

<hyatt> maybe so... we complained a lot about the first charter though

<hyatt> (apple did i mean)

<Dashiva> That last post from html60 seems to be eerily close to xforms. I wonder if they'll join forces :)

<krijnh> Ping

<hyatt> html60?

<hyatt> anne: i especially don't get the html5 should break backwards compat argument

<Dashiva> Dmitry Turin

<hyatt> anne: thats what xhtml does so there would be no point to html5

yeah

I suppose people think HTML5 will actually get implemented so they try to force XHTML2 design into HTML5 without realizing that it doesn't help

whoa

was I inpolite or something?

<hsivonen> Gareth Hay withdrew his formal objection

<hsivonen> IBM's formal objection is still standing

<hsivonen> "one of the XForms opponents even asked recently how a particular simple WF2 form would be written in XForms, so the objections are not even based on firm knowledge of XForms but rather on having developed WF2" -- John Boyer

<Lachy> that just indicates that XForms doesn't leverage existing skillsets, which is a problem

<hsivonen> Lachy: that's a good point to make on the list

<Lachy> do you know where I can find the email he's referring to, and his to response to it?

<hsivonen> Lachy: my guess is that he is referring to mjs but he didn't properly respond to mjs. (presumably he didn't have a logical and technical refutation to mjs' points)

<Lachy> ok, I'll search their emails

<Lachy> ooh, so is Gareth leaving the group?

<Lachy> "Fine. I think today will be my last day on the list. "

<hsivonen> so it seems

<Lachy> I should explain to him that his arguments were dismissed on technical, logical and practical grounds, and that he should not take it to heart.

<Lachy> he says he's a newcomer, and so he needs to understand that there are a lot of people with significantly more experience than him, but that doesn't mean his feedback isn't welcome

<Lachy> he just needs to be prepared think about issues, listen to others and learn.

he already said he was clearly wrong...

Which objections against XForms?

I have enough knowledge of XForms to know that it isn't based on HTML4 and isn't based at all on HTML4 or the XML version of HTML4 forms.

<hsivonen> Lachy: actually, I think John Boyer was referring to Anne--not mjs

I think so too

But I was more asking because I know it to be more complex

because of the separation between controls and data and such

<gsnedders> in parts it seems as if Gareth hasn't read the charter (which you have to say you've read to join the WG)

<hsivonen> in particular, with the concepts of marginal benefit, opportunity cost and the basics of Game Theory

<gsnedders> no. implement every standard ever written :P

<Dashiva> Too bad just watching 'a beautiful mind' doesn't give enough info about Nash equilibria

<Lachy> http://www.theregister.co.uk/2007/05/01/internet_explorer_standards/

<beowulf> hsivonen: urls? :)

<hsivonen> beowulf: in Wikipedia :-)

<beowulf> i have to work for knowledge?? i did not sign up for this! spoon feed me!

<hsivonen> http://en.wikipedia.org/wiki/Marginal_benefit http://en.wikipedia.org/wiki/Opportunity_cost http://en.wikipedia.org/wiki/Game_theory

<beowulf> hsivonen: gosh thanks, i was only joking about spoon feeding

<beowulf> on gareth hay's point about making the web better and html5 not doing that, aiui a better web is one that conforms to the w3c standards (largely) this is manifested by people running their site through the w3c validator and proving it's valid, no-one ever links to the actual standard always to the validator

<beowulf> so make a validator that complies with the 'good and proper' recommendations in html5

<hsivonen> beowulf: working on it ;-)

<beowulf> hsivonen: cool, i saw that :)

<beowulf> but is that not correct, no-one ever points to the actual spec to say they are valid, always to the validator results?

<hsivonen> beowulf: yeah, people tend to point to the validator. which is why it important to have a conformance checker instead of a mere validator

<beowulf> well, from my now developing point of view i don't think there's any need for two specs, just one from which a 'good and proper html' conformance checker can be built

HTML5 already has "two specs"

they are just intertwined

see for instance the syntax section

(which actually has two separate sections, not a good example...)

<hsivonen> anne: we need better marketing of the nature of the spec on this point

<beowulf> cool, i was referring to my suggestion from yesterday that two versions of the html5 spec might help gareth ad tina

<gsnedders> I read that as "gareth to tina"

<hsivonen> beowulf: zcorpan wrote a style sheet to that effect

<beowulf> gsnedders: apologies :)

<gsnedders> beowulf: I'd normally correct such things in my head, but not today :)

<beowulf> if i focus on just one channel maybe my typing will improve :)

<Lachy> wow, the commenters on that article on The Register just don't seem to grasp the issue

<beowulf> right, now for the dumbass questions, what's the difference between a conformance checker and a validator?

<Lachy> see the link I posted above

<hsivonen> beowulf: a conformance checker checks for violations of the machine-checkable conformance criteria. a validator checks if the document is valid according to a schema

<hsivonen> beowulf: if the schema does not capture all the machine-checkable conformance criteria, there is a difference

<hsivonen> beowulf: (in practice schemas don't)

<beowulf> hsivonen: thank you

<gsnedders> Lachy: I like how one of the comments says that MS only implement standards they are involved in creating. There are plenty of standards that they were involved in that they don't implement (either at all, or properly).

<Lachy> which comment # was that?

<gsnedders> 4

<gsnedders> "Tom"

<beowulf> zcorpan: that stylesheet is great

<gsnedders> quite of lot of the commentors seem to think it's possible to just write a standards compliant browser overnight.

<zcorpan> beowulf: thanks

<hsivonen> gsnedders: which is why the IETF "consensus *and running code*" is better than mere "consensus"

<gsnedders> hsivonen: agreed.

<hsivonen> actually, IETF is "*rough* consensus and running code"

<gsnedders> the fact that HTML5 has multiple people already implementing the parsing section, and looking over with it with fine-toothcomb, undoubtedly helps

<zcorpan> perhaps we should do this at ietf instead?

one reason not to do that is their text/plain specs

<gsnedders> originally the HTML WG was at IETF, IIRC

yeah

<gsnedders> (not that I was involved with the web then, obviously :))

zcorpan, did you ever get around filing bugs on us regarding XHTML and CSS?

<gsnedders> can I kill the computing exam? Mb != MiB!

<hsivonen> anne: it would be fun to see if the anti-irc, anti-mailinglist, pro-campfire, pro-forum people would find the IETF spec format old school ;-)

<zcorpan> anne: no not yet

<zcorpan> spec violation? not yet ;)

<zcorpan> anne: #263168

<zcorpan> what component is this in mozilla? Core->Style System (CSS) ?

likely

<Lachy> who is Dominik Tomaszuk and I wonder why he voted no? He didn't provide any reasons.

<zcorpan> two "no"s now? wow

seems that we voted

<Dashiva> Two form nos from Boyer and two void nos from Tomaszuk...

<hsivonen> is it just me or does the International Webmasters Association look more Italian than International?

<hsivonen> what does it do?

<beowulf> carries out clandestine operations on the web

<beowulf> assasinations, that sort of thing

<hsivonen> looks like they certify Web professionals

<hsivonen> http://www.iwanet.org/

<beowulf> oh. that's much less interesting.

<Lachy> ooh, thers another XHTML2 telcon starting in a few minutes

<hsivonen> Lachy: will you attend?

<Lachy> in IRC only

<Lachy> probably just watch

yay, people did studies for headers=

I suppose headers= is easier to implement

however, the use cases are addressed with scope and implicit header finding algorithms as well

maybe headers= should just be supported in the processing algorithm

<Lachy> hey, Tina did join the XHTML2 WG :-)

<Lachy> they ignored my questions. oh well.

<Dashiva> Isn't that what xhtml2 has become famous for?

<Lachy> yeah, but it's fun to play with them a little

<Lachy> oh, steven wrote "Lachy, as chair, I have to tell you that you are not a member of the WG, and therefore we are obliged not to take your comments into account during WG meeting. You are free however to send comments to the list."

<krijnh> :)

<Lachy> yeah

how would an author view of the spec help people reading it?

i mean, why would they start reading the spec?

<zcorpan> perhaps it would help people who do read it understand it better

sure

<Preston> Is there are better way to get a clearer grasp of the HTML5 spec with a minimal time investment?

read the introductory parts and what you're interested in

just reading section 1 would probably help a lot

<xover> Actually, it would help a lot if the WHATWGers would point to specific parts of their spec when talking about its properties, what the spec does and does not do, and what the "intentions" of something is.

I think we point to the spec now and then

<xover> I'm sure you do.

saying things that are not at the other end of the pointer seems weird to me

because it might give an incorrect view

<Lachy> when we discuss specific issues, we usually do point to the relevant sections

Anyway, at this point it's not really relevant to discuss specific sections anyway I think

More about finding out whether we want to do something or not... it seems.

<gavin> gsnedders: I'm pretty sure that Jeff was being sarcastic!

<gsnedders> gavin: didn't come across :)

<gavin> the application/eckshtml didn't trigger your sarcasm meter? :)

<gsnedders> gavin: I'd've sent it anyway replying to some other email

<gsnedders> gavin: too many people seem to be forgetting what we're chartered to do

<gsnedders> gavin: and I've seen all too many people posting seemingly silly things while meaning them

<gsnedders> :)

<gsnedders> something along the lines of the majority of other HTML reference documents

<gsnedders> (link?)

<gsnedders> I like the general layout of the <http://w3schools.com/tags/default.asp>, though I think there really should be a better ToC, as well as better description :P

<gsnedders> though of course there are a billion ways to do it

<gsnedders> but there again, we proper should have some ultra-basic document, as a proper guide.

<gsnedders> starting with the reader knowing no HTML

<gsnedders> *probably

<gsnedders> (or any other non-spoken language)

<mjs> it's becoming impossible to keep up with public-html

<hober> It's quite a firehose, yes

<h3h> it's actually pretty easy to keep up if you just ignore the babbling in the same 10 threads

lol, people are suggesting new MIME types

<gavin> well, I think only one person was

right

<gavin> dbaron suggested it was the only way to transition to draconian error handling, and then someone said "hey good idea!" not realizing that it wasn't what dbaron was proposing

<gavin> and then Jeff posted his sarcastic reply to that

<dbaron> sarcasm doesn't work in email

<hober> We all know how well the switch to draconian error handling coupled with a new media type went last time!

heh, html60 would do good to actually read specs first...

<ol start=> and <li value=> ..

<h3h> somehow I expected more than random IRC trolling-style discussion from this list

<h3h> it's just a pile of FUD, ad homs and misinterpretations

the problem is that everything seems to be up in the air and that key people (the chairs) are not making clear what is in scope and out of scope

but maybe everything should be discussed first, dunno

at the rate this is going WHATWG will have HTML6 done by the time we publish some heavily compromised design principles

<DanC> any CSS WG members about? I'm learning about this "overlapping table cells" issue http://www.w3.org/Style/Group/css2-src/issues/issues-4.html#issue-3 , where evidently the CSS WG made a decision over the objection of Anne

I'm a CSS member

Not sure if that helps here :)

<DanC> yes, you're on record as objecting. Evidently Hixie, Glazman, and Hyatt are also members.

<DanC> I'm trying to figure out their role in this decision.

The larger issue is that table layout is not defined at all

The minor issue this is about is that table layout for HTML and XHMTL is supposedly to be done different (per the CSS 2.1 spec)

And then there's the member only issue about CSS not moving to CR for reason X

<zcorpan> defining tables is something i might look into in due course

<DanC> oh phpht. /Style/Group/

zcorpan, good luck!

<zcorpan> anne: thanks :)

<DanC> "The CSS WG decided to _not_ change the spec based on Anne van Kesteren's comment" http://lists.w3.org/Archives/Public/www-style/2007Apr/0047.html . That's public. Which CSS WG members were involved in that decision/

<DanC> ?

<DanC> one of our databases lists Hixie, Hyatt, and Glazman as CSS WB members; I wonder if they were aware.

dunno

<DanC> how does the CSS WG make decisions?

<DanC> it seems to me that you'd know which WG members you were talking with. the group isn't _that_ big.

I believe during telcons and meetings

I attend neither

usually

<mjs> DanC: I can't imagine Hixie or Hyatt agreeing with those decisions

<gavin> was "WB" above a typo for "WG"?

<mjs> but I don't think they attend most of the f2fs or telecons

gavin, yes

<hsivonen> anne: does that mean the the CSS WG chose to blatantly disregard the way Presto, Gecko and WebKit interoperate with overlapping table cells? (and Trident, too, in text/html)?

hsivonen, yes, as seen in Hixie's twitter logs sometimes issues are disregarded because a page is using scripting...

<hsivonen> anne: sad, sad

<hsivonen> anne: I used to think the CSS WG was the WG that put the W in the WG at the W3C

I think it was mostly Hixie

<hsivonen> anne: did they find two fringe implementations that actually implement what the spec says about cell that would overlap in real browsers?

Hixie since moved on to fry bigger fish

hsivonen, I believe so, but not particularly convincing implementations iirc

The Adobe Mars project and XHTML Print profile implementations?

<hsivonen> I feel guilty about procrastinating with filing my research on this issue in the CSS 2.1 issue tracker

x-wing

<gsnedders> Philip`: (that Ruby guide is really rather good)

<hober> hsivonen: :)

<mjs> John Boyer's Formal Objection doesn't appear to "cite technical arguments"

that's ok

makes it ignorable

<Hixie> nor does the other one

<mjs> the other one doesn't even have a comment

we have two again?

<mjs> John Boyer and Dominik Tomaszuk

oh ok

<gsnedders> the Forms WG seems to be chartered to draw on WF2 for XForms Transitional

<gsnedders> therefore, it makes as much sense to start from WF2 as it does from XForms Transitional

<mjs> It doesn't really make sense to identify XForms as a starting point, since XForms is not part of HTML, nor is it intended to be

<mjs> it's like saying the HTML WG should adopt SVG as a basis for review

<schepers> are you trying to draw me in here? ;)

<John_Boyer> anybody know the link for the rrsagent minutes of this conversation?

John_Boyer, see the topic

John_Boyer, much better logs than RRSAgent

<gavin> RRSAgent: pointer?

all this nonsense about multiple specs and such

<John_Boyer> Too bad mjs just left...

<John_Boyer> He claimed that my objection is ignorable because it doesn't cite technical args

<John_Boyer> sure it does

<John_Boyer> the question for vote was one of process, not technical

<John_Boyer> so my answer was technical regarding the process

except that your conclusions from the charter are wrong, afaict

<John_Boyer> We spent 9 months negotiating the conclusions I have from the charters with the director and CEO of the W3C

<John_Boyer> how can they be wrong???

the HTML WG charter says nothing about aligning with XForms

<John_Boyer> Did noone in this group see the vision document

it says something about architectural consistency

the vision document is non-binding

<John_Boyer> nor timbls blog for that mattter?

and is not the charter

<John_Boyer> the vision document provides further clarification of the charters

timbl's blog is interesting, though not the charter

the vision document is quite silly imo

<John_Boyer> Observe that the ONLY thing the HTML charter does say about forms is that the HTML WG will work with the Forms WG

<John_Boyer> Fine, then go back to the director

<John_Boyer> and get rechartered

<John_Boyer> again

no, it's non binding

<John_Boyer> Yes the charter is binding

only the charter is binding

<John_Boyer> and it says we have to work together

well, sort of, yes

not about aligning with XForms though

<John_Boyer> Right, the not-working-together working together solution

I think so far we've been pretty willing to cooperate investing time in reviewing XForms Transitional and pointing out flaws, etc.

<John_Boyer> We've had all these discussions already with myself and your chairs

<John_Boyer> quite unclear why they aren't taking a leadership role in clarifying what we'resupposed to be doing

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

<John_Boyer> Yes, thanks

<gsnedders> that's all the charter says on the matter

<John_Boyer> yes

<John_Boyer> and what it DOESNT say is "and you can go off and deliver your own separate technology for forms too"

<gsnedders> it doesn't say we can't

<John_Boyer> where does it say you can do WF2 in your charter?

<gavin> it doesn't say a lot of things

Web Forms 2 is architectural consistent with XForms

<John_Boyer> You're not chartered to

John_Boyer, it mentions new controls under deliverables

<John_Boyer> ok

John_Boyer, the charter is quite explicit, I think

Anyway, you still haven't negated my original point about your argument

<gsnedders> the Forms WG charter (which you chair) says you will work in a task force _jointly with the HTML WG_

<John_Boyer> Still, I joined this conversation to defend the objection, which is that it cites technical issues related to the process-oriented question being voted on

<John_Boyer> Yes

<John_Boyer> Our charter is very clear about developing a new "hybrid" that is heavily influenced by WF2 while also allowing us to map the features onto XForms architecture

Frankly, at 11PM I hardly care about this

<gsnedders> the forms WG charter also says you will draw on the WF2 work. This means there are two options for startings points: 1. The (X)HTML Web Forms 2, or 2. XForms

I'd love to see a more concrete proposal than talk about architecture, but I suppose that may be hard to extract out of the XForms WG

<gsnedders> both seem reasonable starting points

<John_Boyer> or 3 is a new document which draw on both

<John_Boyer> that's what I argued we should be doing

<John_Boyer> in the objection

<hober> I assumed that the Forms WG would start with their document, the HTML WG would start with its document, and then the TF would work toward architectural compatibility. So I don't see what the problem with the HTML WG starting with WF2 is.

I have an identical interpretation of the charter

<John_Boyer> It preempts the whole process that the *joint task force* should go through

thanks hober

<John_Boyer> forms is a joint project

No it's not

forms architecture is

whatever that means

<John_Boyer> I just told you what it means

<gsnedders> "It is a goal that this work, which will be conducted in a task force jointly with the HTML WG, draw on the Web Forms 2 work (which moves from the Web Application Formats Working Group to the HTML Working Group) and be integrated into the XForms architecture (following design principles such as the separation of presentation from content)."

<John_Boyer> Please stop ignoring the requirement we have from the W3C AC to work together

<gsnedders> Forms WG Charter

I don't share your interpretation in that case

<John_Boyer> that's the problem

<John_Boyer> and the reason for my objection

<John_Boyer> your chairs are supposed to be making this clear to you

<gsnedders> I have the same interpretation as John_Boyer

<hober> I think the HTML WG's charter is reasonably clear on this point...

<gsnedders> I, however, think WF2 should be used as the starting point.

<John_Boyer> I just want a process that makes it easy to say "whatever is in this document is mappable to an XForms construct" and "if possible, it is equal to or very similar to what WF2 already says"

lol

<John_Boyer> The onus is different

<gsnedders> and if it is the be equal or similar to WF2, I think WF2 is the logical starting point

HTML4 + DOM2HTML is the starting point

WF2 is compatible with that

XForms, so far, is not

<gsnedders> the problem really is the HTML WG Charter and the Forms WG Charter say different things about how they should work together

WF2 is compatible with the XForms architecture, as explained in WF2

<hsivonen> John_Boyer: did I read correctly that you don't want this WG to publish Web Forms 2.0 as part of out REC?

<John_Boyer> yes

<hsivonen> John_Boyer: do you have a technical reason why Web Forms 2.0 would be bad to publish as part of our REC?

<John_Boyer> I think you want to preempt the detailed technical work that needs to be done

<John_Boyer> We are chartered to produce a forms technology that is based on XForms and WF2.

<hsivonen> John_Boyer: no, I am trying to come to an understanding on why you object to Web Forms 2.0.

<hsivonen> John_Boyer: people who have worked on Web Forms 2.0 send feedback on Raggett's XForms Transitional

<hsivonen> John_Boyer: why are you dodging technical debate about Web Forms 2.0?

<John_Boyer> It's a huge document that I don't want to swallow wholesale like a foreign organism without consideration of the features

<gsnedders> John_Boyer: "we" being the forms WG?

<John_Boyer> I prefer positive addition of features to a document rather than throwing in everything, having everyone come to some wrong conclusions, then have to claw back things as we find they have problems

<John_Boyer> People who sent feedback on XF transitional continue not to recognize it's a joint process that is just getting started

<hsivonen> John_Boyer: from the point of view of HTML, XForms is the spec that throws away everything up front

<John_Boyer> so they sent it to public-html without cc to publid-forms

<hober> hsivonen++

<John_Boyer> that's why it's not the starting point either

<hsivonen> John_Boyer: is the requirement to base technology on both WF 2.0 and XForms based on a technical argument?

<gsnedders> anyhow, I've got four exams tomorrow. g'nite.

<John_Boyer> it is a charter requirement

<gsnedders> hsivonen: the Forms WG charter

<John_Boyer> both

<hsivonen> a charter is not a technical argument

<John_Boyer> html and forms

<John_Boyer> asking what document to start with is not a technical question

<John_Boyer> having a vote on that was inappropriate

<John_Boyer> or at least

<hober> I still don't follow how each WG starting with its own document and then working together in the TF toward architectural compatibility is in any way a bad thing.

<gsnedders> John_Boyer: the HTML WG Charter doesn't say it has to be based on both. It says it needs to be artichturally consistent.

<John_Boyer> if it was appropriate

<John_Boyer> then the answers need to be technical in the context of the process question

<John_Boyer> this is a new group that is different than the past

<John_Boyer> so the W3C process rules need some bend in them

<John_Boyer> please don't hide behind them when it is convenient and ignore them when it is convenient

<hsivonen> John_Boyer: Web Forms 2.0 has technical properties. so has XForms. the choice of stating point could, therefore, be made on their technical merit

<hsivonen> John_Boyer: (I'm including network effects here in technical merit--not just pure technology value)

<John_Boyer> and the third option, required by the charters is to "start" with both and create a new form tech

<hsivonen> John_Boyer: I haven't appealed to the W3C process at all here

<John_Boyer> that's what my "objection" actually says

<hober> Right, you guys start with XForms, we start with WF2, and then (after many moons of wrangling) meet in the middle somewhere.

<John_Boyer> That's not a "work together" process option

<John_Boyer> that's a "not working in good faith of the charters" option

<hober> It's exactly a work together option -- work together to acheive architectural compatibility, like our charter requires.

<hsivonen> John_Boyer: no offense, but let's do a third thing in order to avoid choosing from the two sounds like a political argument--not a technical argument

<hober> I think it's precisely in good faith with the HTML WG charter

<hober> I can't speak to the Forms charter as I haven't read it

<John_Boyer> Hmm. How about instead, we work together in good faith to create a forms technology that takes the best of XForms and WF2?

<hober> That's exactly what I'm saying.

<John_Boyer> Right, so the "start" of that document is the empty document

<gavin> I don't see how "work together" precludes using one of two documents as a starting point

<hober> Well, *that* document is the one that describes the architectural compatibility of the XForms WG artifacts and the HTML WG artifcats

<hsivonen> John_Boyer: so far, whenever people who have worked on Web Forms 2.0 have asked the XForms folks, what "best of XForms" they'd like to bring that Web Forms 2.0 lacks, the discussion veers to charters instead of technical features

<hsivonen> John_Boyer: which is why discussion is hard

<hober> And yes, that document is currently empty so far as I know

<John_Boyer> Discussion is hard because the task force is not formed and committed to doing the work.

<John_Boyer> My role is not to single-handedly do all the work

<John_Boyer> for all of you because I can't

<hober> What a strange thing to say.

<John_Boyer> My job is to make sure the right people start getting together and working together and agreeing on how they're going to start

<John_Boyer> and what they're going to produce

<John_Boyer> The push now from both WGs *should* be to get this forms task force started and let them run so the rest of the WGs can focus on the rest of their business

<John_Boyer> that push should go to the chairs

<John_Boyer> and this whole business of preempting what the task force is supposed to do should stop

<John_Boyer> I have to go now. Please send email to list...

<hober> I don't think anyone's trying to preempt what the TF is supposed to do

<John_Boyer> that's exactly what this vote is about.

<hober> No, it's not.

<John_Boyer> The vote asks us to start out by constraining what the TF is supposed to do.

<John_Boyer> What is the purpose of the proposal?

<gavin> Where does it mention any type of constraint?

<John_Boyer> Why are we rushing to some conclusion...

<hober> No, the vote asks the HTML WG to start with WF2

<gavin> It mentions a starting point, and editors, and a name

<hober> How is a start a conclusion?

<John_Boyer> OK, back to the charters.

<John_Boyer> Going in circles here

<hober> I stand by my interpretation of the HTML WG charter.

<John_Boyer> HTML WG is not chartered to go off by itself and build forms tech

<hsivonen> John_Boyer: it doesn't preclude the forms WG finally saying what they find is technically wrong about WF 2.0 so that this WG could fix WF 2.0 accordingly

<gavin> You just claimed that the vote is constraining future work, I think it'd be a good idea to explain that statement before changing the subject again.

<hober> It's chartered to pursue, via the joint TF, architectural compatibility with whatever the Forms WG does.

<John_Boyer> gavin, perhaps the vote is very poorly worded. But it is already obvious that WF2 is supposed to be taken as serious input to the new forms tech (see Forms WG charter). So...

<hober> Why *shouldn't* WF2 be taken as serious input????

<gavin> I think it's quite explicitly stated in the proposal and the vote that it's about a starting point, not a conclusion.

<hsivonen> John_Boyer: are you sayig that WF2 shouldn't be taken as serious input?

<hober> It's the product of years of hard work...

<John_Boyer> Didn't say it shouldn't

<John_Boyer> just finishing the answer now...

<John_Boyer> So, since it is obvious that WF2 is input to the new forms tech, what is the point of the proposal and vote? My interpretation of the question is that the proposer wants to use WF2 as the first version of the spec

<John_Boyer> I am advocating using empty document as the start of the new forms spec

<schepers> I think that a compromise can be made

<hober> Ahh

<hober> I think I see the misunderstanding now

<hober> The vote is about what the HTMLWG's starting point is

<schepers> John_Boyer: I agree with you that the work should be done in unison and in good faith

<hober> And you're interpreting that to mean something about the starting poing of the TF

<John_Boyer> There is not supposed to be a difference between starting point for HTML WG and starting point for the task force

<John_Boyer> The HTML WG component of the task force IS the set of people who should be participating in the forms work

<hober> This gets right back to my point re: each WG having their own documents, and the TF ensuring they become & remain architecturally compatible

<John_Boyer> and they should be starting with an empty document

<hsivonen> John_Boyer: do you believe the full HTML WG should not be participating in forms work?

<John_Boyer> That's the point I'm saying you are mistaken about

<John_Boyer> that's not the intent of the charters

<gavin> It might help make things clearer if you posted to the list with the reasons you think starting with a blank document is a better choice than starting with WF2

<schepers> but I also recognize that the vote for using WHATWG as a starting point is subject to heavy revision if necessary... that's not strongly stated in the poll, but it is there

<hober> I think my interpretation of the HTMLWG charter is a fair and reasonable one on this point, but, as I said before, I haven't read the other charter

<hober> It's entirely possible that the charters themselves are different on this point.

<hsivonen> John_Boyer: btw, the design goals of this WG imply that we couldn't start with and empty spec. we should start with what is implemented in major browsers anyway

<John_Boyer> That's part of the problem. The HTML charter requires liaison with another WG on a significant component of work, so it is necessary to read that WG charter as part of the interpretation of how the work is to be done

<John_Boyer> That's still empty document, followed by design requirements that say things like "need to support old-style forms"

<John_Boyer> Like, I so really really have to go now though

<John_Boyer> I hope it is at least a bit clearer where my feedback is coming from.

<hober> I think it is, yes, thanks

<schepers> looks like sometime late last night...

<billmason> It's in a charter somewhere, probably.

<schepers> man, this crowd can be pretty snide...

<hsivonen> schepers: what was snide?

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

<hsivonen> schepers: it is perfectly reasonable to ask for technical detail when someone objects to the WHATWG work. how else could it we fixed?

<schepers> hsivonen: do you really think that's what I'm talking about?

<hsivonen> schepers: I don't know. What are you talking about?

<schepers> it's not... I'm talking about the tone of the discussions

<hsivonen> mjs: you missed a discussion about forms and charter

<Hixie> at the risk of being called snide, "avoided" might be a better word

<schepers> Hixie: you're snide!

<schepers> (not that I actually think that was snide)

<mjs> hsivonen: summary?

<mjs> or should I read the logs?

<hober> Reading the log shouldn't be too bad

<schepers> boyer made minutes here: http://www.w3.org/2007/05/02-html-wg-minutes.html

<mjs> I still have 40 unread public-html emails so I'd find a summary helpful, but of course no obligation

<hsivonen> mjs: http://krijnhoetmer.nl/irc-logs/html-wg/20070502#l-381

<hsivonen> mjs: John Boyer objected to adopting WF 2.0 as a starting point citing charters

<hsivonen> mjs: also objected to this wg developing forms tech on its own

<hober> Basically, he objects to the following interpretation of the HTML WG charter

<mjs> so he cited political arguments in lieu of technical ones to support his Formal Objection?

<hsivonen> mjs: in summary, yes

<gavin> technical arguments about the process was the way he put it I think

<gavin> since the question at hand was a process question and not a technical one

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

<gavin> as I understand it, he is opposed to using WF2 as a base

<gavin> so it makes sense for him to formally object

<gavin> what's not clear are the reasons why he objects

<schepers> it does seem in bad faith to interpret the charter that way, to me

<gavin> (not clear to me)

<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

<hober> or something like that; it wasn't entirely clear

<schepers> I think that's a fair summary

<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

<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

<mjs> so the XForms REC would be resciended under his proposal?

<Hixie> and so as i see it there are three ways forward:

<mjs> or does he require only the HTML WG to drop existing forms features pending TF results?

<Hixie> 1. ignore the majority, honour the earlier agreement with xforms, and push xforms through this wg

<hober> mjs: I don't know

<Hixie> 2. create a task forcee to create a new language from scratch that involves xforms wg members

<Hixie> 3. ignore the prior agreement with xforms, and push an html-specific language through this wg (i.e. base the work on wf2)

<Hixie> 1 would basically cause a big chunk of the wg to quit

<schepers> would it?

<mjs> probably

<hober> I don't think those are the only three options

<schepers> I thought you said that the majority doesn't matter, that only technical arguments matter?

<hsivonen> Hixie: #2 sounds like a compromise designed to make everyone equally inconvenient

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

<mjs> well, there are no technical arguments on the merits for option 1

<schepers> and I agree that those aren't the only 3 options

<Hixie> and 3 would cause the xforms people to blow their top

<hsivonen> schepers: what other options you see?

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

<Hixie> hober: that's 2

<Hixie> s/from scratch// if you like

<mjs> I don't think #4 and #2 are the same

<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

<mjs> #4 would make the TF advisory to two separate specs, rather than in charge of a single co-owned spec

<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

<hober> mjs: yes, exactly

<Hixie> well you can certainly create lots of process that makes 1, 2, and 3 above _look_ like other options

<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

<mjs> hober: not "compatible" but "architecturally consistent"

<hober> perhaps with a third, non-spec document coming out of the tf

<hober> mjs: yes, again excatly :)

<mjs> schepers: the problem is there's no clear meaning for what "architecurally consistent" means

<mjs> thus, it is not clear what, if any, changes to WF2 are needed

<mjs> John Boyer refuses to even propose specific changes to WF2

<hober> schepers: that presumes that that's an upgrade path

<mjs> so that makes it less clear

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

<schepers> then let's come up with one in good faith, how about?

<mjs> my interpretation is that WF2 and XForms are already architecturally consistent

<mjs> they live in different namespaces

<Hixie> john boyer doesn't care about architecturally consistent

<mjs> and WF2 has enough features to machine-translate XForms content to it

<schepers> that's not good faith

<Hixie> that's not what he wants

<hsivonen> schepers: can't we admit in good faith that the goals are incompatible so there are two form technologies in different namespaces?

<mjs> schepers: I sincerely think that's architecturally consistent

<Hixie> anyway

<hsivonen> schepers: what's good faith?

<Hixie> i don't see this conversation going anywhere productive

<Hixie> so i'm gonna go back to work :-)

<mjs> my preference would be to let Boyer's FO go to the Director with suitable response from us

<mjs> as far as procedure goes

<schepers> hsivonen: I'm not going to be backed into defining every word I use... I think maciej knows what I mean

<mjs> and The Director can give it all due consideration

<mjs> schepers: I honestly don't -- do you think I'm insincere in my claim that I believe that constitutes architectural consistency?

<mjs> obviously you can't have a language that's syntactically compatible with both existing XForms and existing HTML Forms

<schepers> I can't comment on your sincerity, but I don't think that was the intent of the charter

<mjs> so that can't be what "architecturally consistent" means

<mjs> I would take it to mean "no conflicts if you implement both in one implementation" or something like that

<mjs> the way JPEG is architecturally consistent with GIF

<mjs> Philip`: people say "The Director" instead of "Tim" because, I guess, it sounds more imposing

<Hixie> the way that the svg text model is not architecturally consistent with css? :-)

<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

<schepers> we've also gotten implementor feedback to the contrary

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

<schepers> does that matter?

<schepers> it's about technical assessments, not popularity contests, right?

<schepers> but in any case, as I said, we're hoping to find a path forward for those implementations that did have a problem

<mjs> it does matter, because you can't check whether an unshipped implementation got it right

<schepers> fair enough

<mjs> implementations that are not available to the public carry no weight for things like "2 interoperable implementations" requirements

<mjs> well, at least the CSS WG requires them to be shipping products available to the public and not experimental or testing only

<schepers> I'm not sure why you're ignoring my larger point, though

<mjs> I think your larger point, that you are taking implementation issues into account on this matter, is a good one

<mjs> or rather, it is welcome news to me

<schepers> if it were up to me, there are lots of things I'd change about SVG

<schepers> but this is OT for #html

<mjs> yeah, not really relevant here

<heycam> mjs, i believe "architecturally consistent" means having a (non-trivial) mapping to the same underlying model

<heycam> at least that's my interpretation, i wasn't there during the months of charter teeth-gnashing

- DRAFT -

SV_MEETING_TITLE

2 May 2007

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output