Last Comment Bug 478665 - HTML5 spec without all the new features
: HTML5 spec without all the new features
Status: RESOLVED INCOMPLETE
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Robert Sayre
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-15 13:22 PST by Robert Sayre
Modified: 2009-02-19 19:35 PST (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Robert Sayre 2009-02-15 13:22:27 PST
I often say there should be an HTML5 spec without all the invention. I used my spare time today to press the delete key for a bit. I'm just using this bug to keep track.
Comment 1 Robert Sayre 2009-02-15 13:38:40 PST
I have yet to find an HTML diff script that can process the difference between Ian's document and mine. Here's what I have so far:

http://people.mozilla.com/~sayrer/2009/02/15/html5.html

My document is roughly 1.7MB at this point. Ian's version is about 2.6MB.

I'm sure there are many dangling references. In particular, the removal of WebForms2 is not complete. Here is a list of changes I've made so far:

1.) Cut most of the introduction. Use one similar to HTML 4.01.
2.) Eliminate most of the conformance requirements section. It was very repetitive, sometimes contradictory, and contained enough loopholes to make it ineffective.
3.) Remove Communication Section
4.) Remove Command APIs
5.) Remove Drag and Drop API
6.) Remove Datagrid API
7.) Remove Structured client-side storage
8.) Remove Undo history
9.) Remove Rendering
10.) Remove "Things that you can't do with this specification..."
11.) Remove Time microsyntax in preparation for deleting all features that depend on it
12.) Remove DOMStringMap and dataset
13.) Remove video and audio elements, media elements, source element
14.) Remove MathML and SVG sections from Embedded Content
15.) Remove figure element
16.) Remove img element examples and alt text guide. Author's guide would be good for this.
17.) Remove section, nav, article, aside elements
18.) Remove header/footer element
19.) Remove "headings and sections" and "creating an outline"
20.) Remove time element
21.) Remove progress and meter elements
22.) Remove the mark element
23.) Remove details and datagrid elements
24.) Remove command and bb elements
25.) Remove DOM Feature Strings
26.) Remove "Features defined in other specifications"
27.) Remove "Common conformance requirements for APIs exposed to JavaScript"
28.) Remove DOMTokenList and relList and classList
29.) Remove "Common Grouping Idioms"
30.) Remove the dialog element
31.) Remove the output element
32.) Remove hyperlink auditing (ping)
33.) Remove autofocus attribute
34.) Remove sandbox and seamless
35.) Remove registerProtocolHandler, etc
36.) Remove hidden attribute
37.) Remove Constraint Validation
38.) Remove History section
Comment 2 Sam Ruby 2009-02-15 14:07:38 PST
One of the dangling pointers is whether or not img/@alt is required or optional.  I'd suggest that clarifying this be a priority.

More generally, declaring a consistent policy on features that were previously present in HTML4 (even if not completely or even partially implemented yet) would avoid a lot of discussion.  Examples would be the head/@profile attribute and table/@summary attribute.
Comment 3 Robert Sayre 2009-02-15 17:13:02 PST
(In reply to comment #2)
> One of the dangling pointers is whether or not img/@alt is required or
> optional.  I'd suggest that clarifying this be a priority.
> 
> More generally, declaring a consistent policy on features that were previously
> present in HTML4 (even if not completely or even partially implemented yet)
> would avoid a lot of discussion.  Examples would be the head/@profile attribute
> and table/@summary attribute.

Ian's HTML5 document describes some features that don't work very well, features that aren't used very much, features with an unclear purpose, and features that overlap with newer features that are deemed more aesthetically pleasing. That last case is often phrased as "semantic [something]", separation of presentation and content, etc. The document makes these derided elements fail to meet "conformance" requirements for someone (usually authors).

I don't think this approach is a good idea. I would rather describe reality in these cases.

For features that don't work very well:

"This [feature] doesn't work very well."

For features that aren't used very much:

"This [feature] isn't used very often."

For features that overlap with newer stuff:

"This [feature] provides capabilities that are also provided by [feature2]."

For features with an unclear purpose:

"The purpose of [feature] element is something of a mystery... some possible uses... what user agents do..."

I do not think uniform, prescriptive conformance requirements are useful way to deal with these situations.

For the extra special 'alt' attribute, I think it will be not required because that requirement is ineffective in practice. "4.8.2.1.12 General guidelines" and "4.8.2.1.13 Guidance for markup generators" provide some concise guidelines that I think are worth including.
Comment 4 Sam Ruby 2009-02-15 17:40:46 PST
(In reply to comment #3)
> 
> I do not think uniform, prescriptive conformance requirements are useful way to
> deal with these situations.

I may have been unclear, because you appear to be answering a question I did not ask.  That being said, the answer you provided was very helpful in understanding your intent.  Based on your answer, I assume that the "Conformance checkers" section will be radically altered or possibly even eliminated in subsequent drafts.

Back to my original question.  There are features in HTML4 that are not present in Ian's HTML5 draft, and vice versa.  I see that you removed most if not all of the new features that aren't widely implemented.

My question relates to features in HTML4 that did not make the cut in Ian's HTML5.  My assumption, based on your answer above, is that the intent is that most of not all of them will be "restored", likely with annotations as you describe above.

Am I reading your intent correctly?
Comment 5 Robert Sayre 2009-02-15 18:00:25 PST
(In reply to comment #4)
> 
> I may have been unclear, because you appear to be answering a question I did
> not ask.  

You did not ask any questions.

> That being said, the answer you provided was very helpful in
> understanding your intent.  Based on your answer, I assume that the
> "Conformance checkers" section will be radically altered or possibly even
> eliminated in subsequent drafts.

Yes.

> My assumption, based on your answer above, is that the intent is that
> most of not all of them will be "restored", likely with annotations as you
> describe above.
> 
> Am I reading your intent correctly?

Yes.
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-02-16 01:39:13 PST
(In reply to comment #1)
> 5.) Remove Drag and Drop API

IE implemented this first, then Webkit cloned it, then Ian specced it, then we implemented it. It's not an Ian invention.

> 13.) Remove video and audio elements, media elements, source element

I'm not sure what your plan is for the removed items, but this had better live on in another credible spec, or our push for open media formats on the Web will be significantly set back. I think it's important that that plan be in place *before* these things are removed from HTML5.

Personally, I think there has been a lot of value in an integrated spec. Technically, it's helped unify fundamental concepts like requirements on event queues (the "queue a task" concept), situations that "block the load event", script origins, etc. Strategically, it's been a good brand for a set of features important for the Web ... important enough that Mozilla has invested in a lot of them, anyway. Maybe you can factor the spec without losing those things. I'm not sure.

I don't think Bugzilla is the right place to do this work. HTML5 is not a Mozilla product.
Comment 7 Brendan Eich [:brendan] 2009-02-16 01:47:57 PST
The Drag and Drop API is a de-facto standard, it should be included in some spec. Why not in HTML5? Comment 0 does not give a rationale for this cut.

I agree with roc's last three paragraphs. But lest this bug turn into a badly threaded discussion, we should move to a newsgroup. In the mean time, any reason not to cc: Ian on this bug?

/be
Comment 8 Sam Ruby 2009-02-16 03:32:15 PST
(In reply to comment #7)
> 
> we should move to a newsgroup

I suggest http://lists.w3.org/Archives/Public/public-html/
Comment 9 Robert Sayre 2009-02-16 08:57:39 PST
 > > 13.) Remove video and audio elements, media elements, source element
> 
> I'm not sure what your plan is for the removed items, but this had better live
> on in another credible spec, or our push for open media formats on the Web will
> be significantly set back. 

I don't have any plans for the removed items. I don't want to work on them, but I am certainly not trying to block them. In fact, there's nothing stopping Ian from continuing as he has been--his document could supersede the document I've produced, but it's going to take longer.

> I think it's important that that plan be in place
> *before* these things are removed from HTML5.

I don't accept this as a gating condition.

> Personally, I think there has been a lot of value in an integrated spec.
> Technically, it's helped unify fundamental concepts like requirements on event
> queues (the "queue a task" concept), situations that "block the load event",
> script origins, etc.

Yes, there are lots of great things in the document. I don't think I've changed the ones you mentioned.

> Strategically, it's been a good brand for a set of
> features important for the Web

I am not doing branding. I am looking for a set of features that can get consensus quickly and be published. Spec quality issues aside, I feel there is no doubt that Mozilla intends to implement everything in the document I've produced.

> I don't think Bugzilla is the right place to do this work. HTML5 is not a
> Mozilla product.

I used bugzilla so people who actually contribute to Mozilla would see it first. Brendan is probably right that we should take the discussion elsewhere.
Comment 10 Brendan Eich [:brendan] 2009-02-16 09:49:11 PST
(In reply to comment #8)
> (In reply to comment #7)
> > 
> > we should move to a newsgroup
> 
> I suggest http://lists.w3.org/Archives/Public/public-html/

First I'd like to have a discussion among Mozilla contributors. If we Mozilla contributors (Sam, I don't mean to drag you into this if you want to be kept out) don't agree on crucial issues, we should find out before going to a w3c forum.

I'm told that in w3c meetings, other members have discounted individual opinions because they are not official member positions -- this kind of tactic has misled some to "speak for Mozilla" without consensus. From my point of view, speaking for Mozilla here, it's better to try for consensus among ourselves than to assume consensus will come out in the wash, or that we'll be fine without it acting as individualsl in a pay-to-play membership setting.

What I will not support in anything with Mozilla's "brand" on it (and you can't avoid that, if you're here doing work) is Consequentialism. E.g., the end of a smaller spec sooner justifies the means of making an undiffable derived document. Or the end of cutting "invention" justifies taking out de-facto standard content: was the Drag and Drop removal "collateral damage"? No answer yet. Or the end of getting stuff done justifies using bugzilla.mozilla.org (instead of whatwg.org, for instance, or any place less fork-y and single-vendor).

m.d.planning seems wrong. m.d.platform? There must be a better Mozilla group.

/be
Comment 11 Sam Ruby 2009-02-16 10:08:07 PST
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > 
> > > we should move to a newsgroup
> > 
> > I suggest http://lists.w3.org/Archives/Public/public-html/
> 
> First I'd like to have a discussion among Mozilla contributors. If we Mozilla
> contributors (Sam, I don't mean to drag you into this if you want to be kept
> out) don't agree on crucial issues, we should find out before going to a w3c
> forum.

I believe I qualify as a Mozilla contributor.  In fact, I would like to qualify more, and believe you owe me a reply on another subject...

But back to the topic at hand... I actually respectfully disagree with the premise above.  I've seen the result at the ASF when Sun or IBM attempted to prepare and present a unified opinion at all times, and the results weren't pretty.  Yes, that works in small closed door settings like one has traditionally seen at the W3C in the past, but IMHO don't work very well in large open settings like we have in the HTML working group with literally hundreds of participants, some of which who have had their employment status change significantly this past month alone.

> I'm told that in w3c meetings, other members have discounted individual
> opinions because they are not official member positions -- this kind of tactic
> has misled some to "speak for Mozilla" without consensus. From my point of
> view, speaking for Mozilla here, it's better to try for consensus among
> ourselves than to assume consensus will come out in the wash, or that we'll be
> fine without it acting as individualsl in a pay-to-play membership setting.

Hopefully none of that has occurred since I joined as co-chair.  If it does, please alert me and I will see to it that it gets addressed.

> What I will not support in anything with Mozilla's "brand" on it (and you can't
> avoid that, if you're here doing work) is Consequentialism. E.g., the end of a
> smaller spec sooner justifies the means of making an undiffable derived
> document. Or the end of cutting "invention" justifies taking out de-facto
> standard content: was the Drag and Drop removal "collateral damage"? No answer
> yet. Or the end of getting stuff done justifies using bugzilla.mozilla.org
> (instead of whatwg.org, for instance, or any place less fork-y and
> single-vendor).

When I was at Mozilla, I got a definite sense that many felt that the WHATWG spec was too large.  Rob's initial cut may be too brutal (or possibly not brutal enough... who knows?).  Actually, that's the real point of my comment: it is very easy to criticize any proposal, it is much harder to make one.  I applaud Rob for doing exactly that.  If nothing else, it will spawn a discussion that I hope will cause everybody to look critically at what should go into the spec, and when.

I've made it no secret as to my opinion: I very seriously doubt that the current "Hixie" spec has little chance of making it to W3C CR status in 2012 if it is approached as one big lump, take it or leave it.  A release early and often strategy seems much more appropriate.

> m.d.planning seems wrong. m.d.platform? There must be a better Mozilla group.

I hope that whatever venue is chosen, both Ian and I can participate.  And one thing I can assure you is that once I am allowed to participate, I will insist that it be open.

- Sam Ruby
Comment 12 Robert Sayre 2009-02-16 10:31:12 PST
(In reply to comment #10)
> 
> What I will not support in anything with Mozilla's "brand" on it (and you can't
> avoid that, if you're here doing work) is Consequentialism. E.g., the end of a
> smaller spec sooner justifies the means of making an undiffable derived
> document. 

It's undiffable because it's too big. I'm working on producing a paged diff, to catch mistakes if nothing else. It's just a tools issue, not Consequentialism. 

> Or the end of cutting "invention" justifies taking out de-facto
> standard content: was the Drag and Drop removal "collateral damage"? No answer
> yet. 

I used <canvas> as a rough cut off point, as I have said I would do many times (including to Hixie and yourself, last time I was in MV). The API is unchanged in Ian's document. How have things gotten worse for Drag and Drop?

> Or the end of getting stuff done justifies using bugzilla.mozilla.org

This is an argument about propriety, and I just don't feel like it will go anywhere.

> (instead of whatwg.org, for instance, 

whatwg.org is not inclusive enough (I want feedback from all browser vendors), and I try to avoid participating there anyway.

I'll put the proposal on github.org, rather than hg.mozilla.org or people.mozilla.com. I'm going to continue to work on it, time permitting, since the credibility of the proposal rests on document quality to a large extent.
Comment 13 Brendan Eich [:brendan] 2009-02-16 11:28:26 PST
(In reply to comment #11)
> I believe I qualify as a Mozilla contributor.

Of course, I was simply giving you an "out" from having to be part of an HTML5 consensus attempt among would-be speakers-for-Mozilla.

> In fact, I would like to qualify
> more, and believe you owe me a reply on another subject...

Sent.

> But back to the topic at hand... I actually respectfully disagree with the
> premise above.  I've seen the result at the ASF when Sun or IBM attempted to
> prepare and present a unified opinion at all times, and the results weren't
> pretty.  Yes, that works in small closed door settings like one has
> traditionally seen at the W3C in the past, but IMHO don't work very well in
> large open settings like we have in the HTML working group with literally
> hundreds of participants, some of which who have had their employment status
> change significantly this past month alone.

I remember agreeing with you in principle on this point when we met the other week. But I'm told some w3c members do not agree, and that has been a problem for at least some Mozilla developers participating in w3c working groups.

More fundamentally, it's fine to have disagreement among Mozilla principals on a great many things (it's more than fine, unanimity would be a warning sign of group-think), but we should try to agree on critical strategy and acceptable ("proper", pacé sayrer) tactics. It's clear people exchanging comments here do not agree on either.

I believe that, for the health of the Mozilla community, we need more open discussion in order to avoid passive-aggressively, or just aggressively, going off in divergent directions. Enough divergence and there will be a bigger conflict down the road. Why not have the discussion now?

> Hopefully none of that has occurred since I joined as co-chair.  If it does,
> please alert me and I will see to it that it gets addressed.

I'll let the cc'ed witnesses fill you in.

> When I was at Mozilla, I got a definite sense that many felt that the WHATWG
> spec was too large.  Rob's initial cut may be too brutal (or possibly not
> brutal enough... who knows?).  Actually, that's the real point of my comment:
> it is very easy to criticize any proposal, it is much harder to make one.  I
> applaud Rob for doing exactly that.

I'm not so sure. What if ten people do the same? What if there's a webkit.org bugzilla ticket opened with a competing cut-down HTML5 document? I'm also not so sure we should be hacking on the big HTML5 spec so much as our own code at this point (again speaking with Mozilla hat on).

> If nothing else, it will spawn a
> discussion that I hope will cause everybody to look critically at what should
> go into the spec, and when.

Everybody who? The primary author of the document in jeopardy of being forked is not cc'ed here.
 
> I've made it no secret as to my opinion: I very seriously doubt that the
> current "Hixie" spec has little chance of making it to W3C CR status in 2012 if
> it is approached as one big lump, take it or leave it.  A release early and
> often strategy seems much more appropriate.

I agree with you from a high enough altitude. I think we may not agree on the detailed cost/benefit analysis of refactoring and splitting, both in spec maintenance or review overhead, and in higher-order risks to do with coherent, integrated design. If we did everything in small increments, but had to spend a year writing each up and then freezing them forever, we could easily enshrine mistakes and paint ourselves into corners.

This has happened to some extent with ECMAScript. I'm sure you've seen the effect. It may be a good trade-off against having no standard at all ;-), but even that's not a given. I'd rather have de-facto standardization based on a shared mega-document implemented piecemeal, than a series of specs that take too long altogether and have too many unintended big-picture or integration bugs.

I acknowledge the counter-argument: that by cutting back to what is implemented already, we won't enshrine any mistakes or miss any big-picture connections that aren't already mistaken or missing in the de-facto standards.

That pave-the-cowpaths approach is good as part of a set of process rules, but by itself could be harmful. It's obviously good in an abstract sense to spec what is already implemented, and it seems an unmixed good for web content developers and new browser vendors. But it won't advance the state of the web at all, since it will simply consolidate what is already in browsers. And since such implementations will disagree and contain bugs, the standardizers will end up inventing anyway (even if only "a little" -- this could be "a lot" after analysis and testing).

There are too many imponderables and assumptions at play here, so I'll shut up now. I don't want to stand on the "integrated big spec or bust" hill and die.

But from past experience in w3c and Ecma I'm concerned that we can end up with lots of work, and an incoherent big picture over time, by trying to do less, and factor harder. We can certainly give fast-moving vendors more power to tread new cow-paths. That's not good in any open systems point of view, unless the vendors work together on proto-standards -- which I suppose is what the whatwg.org could continue to do, but without Microsoft.

Even the best software is not factored for factoring's sake, or polished in its internal APIs to the same degree as "external" ones. There's always a scarcity problem motivating some economic trade-off.

In the present world, the trade-off of no spec vs. one without <video> seems clearly worthwhile to some, but others disagree. Theory aside, the practical trade-off between doing less and deferring specification of strategic elements that at least a couple of the major vendors including Mozilla implement is a topic for a discussion I'd like to have.

> > m.d.planning seems wrong. m.d.platform? There must be a better Mozilla group.
> 
> I hope that whatever venue is chosen, both Ian and I can participate.  And one
> thing I can assure you is that once I am allowed to participate, I will insist
> that it be open.

Who said anything otherwise? Yeesh.

I've been crystal clear in talking about a public mozilla.dev.* newsgroup thread to help get Mozilla's house in order, both for w3c membership reasons (you may or may not be able to "fix" those, since they involve other members' views of what they get from pay-to-play), and for healthy working relationships and work products among Mozilla-identified people. Which includes you and Ian, who again is not cc'ed here (improperly, in my Miss Mozilla Manners book :-P).

/be
Comment 14 Sam Ruby 2009-02-16 11:58:24 PST
[aggressively snipped: clearly I don't want no steeken "out", thanks for the reply, look forward to email from cc'ed witnesses, by "everybody" I meant public-html, and I apologize for the presumption that moving this might result in a discussion that is less open to all]

Now, more substantiative responses to just two items:

(In reply to comment #13)
> (In reply to comment #11)
> 
> I believe that, for the health of the Mozilla community, we need more open
> discussion in order to avoid passive-aggressively, or just aggressively, going
> off in divergent directions. Enough divergence and there will be a bigger
> conflict down the road. Why not have the discussion now?

I can agree with the above, but will note that the original context for this was your statement "First I'd like to have a discussion among Mozilla contributors".  My take is that both discussions should proceed forthwith, and neither should wait on each other.

> > When I was at Mozilla, I got a definite sense that many felt that the WHATWG
> > spec was too large.  Rob's initial cut may be too brutal (or possibly not
> > brutal enough... who knows?).  Actually, that's the real point of my comment:
> > it is very easy to criticize any proposal, it is much harder to make one.  I
> > applaud Rob for doing exactly that.
> 
> I'm not so sure. What if ten people do the same? What if there's a webkit.org
> bugzilla ticket opened with a competing cut-down HTML5 document? I'm also not
> so sure we should be hacking on the big HTML5 spec so much as our own code at
> this point (again speaking with Mozilla hat on).

I do have a plan which should throttle this somewhat, see:

http://lists.w3.org/Archives/Public/public-html/2009Jan/0667.html
  search for "two things I would like to establish"

http://lists.w3.org/Archives/Public/public-html/2009Jan/0688.html
  search for "4)", "5)", and "a)"

In particular note that Mike's draft has *not* gone forward at this time.

- Sam Ruby
Comment 15 Hixie (not reading bugmail) 2009-02-16 16:59:15 PST
It'd probably be best to call this "HTML4.1", to avoid confusion. That would likely also set more reasonable expectations as to what it would include, and would remove problems like "where do we put <video>".

It would be good to have a clear statement of scope, though. Is this intended to be HTML4-done-right? (i.e. including proper conformance criteria for HTML4 features?) Is it intended to be HTML5-without-new-features? (i.e. a proper subset?) There are differences between HTML4 and HTML5 -- is this draft intended to be backwards-looking or forwards-looking on those topics? What do you want to do with things like the new elements being mentioned in the default rendering rules or in the parsing rules? Should those be removed or left in? Should the events be defined on a per-element basis like in HTML4, or on a global basis like HTML5?
Comment 16 Robert Sayre 2009-02-16 17:15:38 PST
(In reply to comment #15)
> It'd probably be best to call this "HTML4.1", to avoid confusion. That would
> likely also set more reasonable expectations as to what it would include, and
> would remove problems like "where do we put <video>".

The naming issue is hairy, I agree. But this problem comes from the rename of Web Applications 1.0 (a name that also sets more reasonable expecations). Switching to "HTML5" was squatting--ugly.

> It would be good to have a clear statement of scope, though. 

I guess, but HTML5 doesn't have one.

> Is this intended
> to be HTML4-done-right? (i.e. including proper conformance criteria for HTML4
> features?)

Not necessarily, I fully intend to punt on some issues. Some aren't worth fixing, or need to be fixed on an HTML5 time scale.

> Is it intended to be HTML5-without-new-features? (i.e. a proper
> subset?)

Tough to say, I never know what you're up to. :)

> There are differences between HTML4 and HTML5 -- is this draft
> intended to be backwards-looking or forwards-looking on those topics?

Case by case.

> What do
> you want to do with things like the new elements being mentioned in the default
> rendering rules or in the parsing rules? Should those be removed or left in?

I removed the Rendering section. Some of the new elements will have to be excised when they appear elsewhere.

> Should the events be defined on a per-element basis like in HTML4, or on a
> global basis like HTML5?

I don't know. I don't think it is especially important in the short term.
Comment 17 Hixie (not reading bugmail) 2009-02-16 17:26:29 PST
The renaming to HTML5 was a W3C decision, for what it's worth. I agree that naming the spec Web Apps 1.0 (with the vocabulary called HTML5) was better.

HTML5's scope description is here:
   http://www.whatwg.org/specs/web-apps/current-work/#scope

Basically, it's about taking the Web platform forward and making HTML5 suitable for more document and application types, merging the HTML, XHTML, and DOM HTML specs into one coherent design.

It's hard to review your document without a better sense of where you're heading (for example, where you're heading determines whether or not having the rendering section is necessary). From the way you responded to the questions above it almost sounds like it's just "HTML5 with Rob Sayre's pet peeves removed", which is probably not the most useful document! I think there is definitely a need for a document that is either HTML4-done-right or HTML5-without-new-features. I'm not sure it makes sense to have a mishmash, though.
Comment 18 Robert Sayre 2009-02-16 17:44:17 PST
(In reply to comment #17)
>
> Basically, it's about taking the Web platform forward and making HTML5 suitable
> for more document and application types, merging the HTML, XHTML, and DOM HTML
> specs into one coherent design.

With all due respect, I don't think that section contains a lot of information.

> From the way you responded to the questions
> above it almost sounds like it's just "HTML5 with Rob Sayre's pet peeves
> removed", which is probably not the most useful document! 

I don't think that's a fair characterization. It contains <canvas> and things that are older, roughly. There should be room to maneuver without getting dogmatic, though. Especially for things that are small and widely implemented. And, fwiw, I have mixed feelings on the things I cut.

> I think there is
> definitely a need for a document that is either HTML4-done-right or
> HTML5-without-new-features.

I think there is a need for a document that raises the bar for the Web, and doesn't have to wait for everything that's in your document. I don't think it's critical that we agree on scope--it's not like I'm off on an impractical bender. After all, I don't care for the scope of your document.
Comment 19 Hixie (not reading bugmail) 2009-02-16 18:04:08 PST
I'm not really trying to "come to an agreement" on the scope. I just want to make sure the scope for your document is understood, so that it can be properly reviewed. Right now, I really can't review it, because I don't know, for instance, if it makes sense for it to have a rendering section or not. If the scope is "anything <canvas>-and-older", then the rendering section should be in, the parser shouldn't include the new elements, the event handler attributes should be on a per-element basis not global, drag-and-drop should be in, all the img element's alt attribute requirements should be in except that there shouldn't be a section for Flickr-like situations (though should just be non-conforming), etc. If the scope is something else, then the answers might be different. All I'm asking for is a clear statement of intent so that I can most effectively help you in my review of your work.

(If you have any suggestions on what I should do to make the HTML5 spec's scope/intro section clearer, please do mail me or the list, I'd be happy to try to improve it.)
Comment 20 Robert Sayre 2009-02-16 19:56:08 PST
(In reply to comment #19)
> If the
> scope is "anything <canvas>-and-older", then the rendering section should be
> in, 

These answers seem to assume that I have the same completeness criteria that you do. I don't. There are some things that can't be fixed except maybe on an HTML5 time scale.

> (If you have any suggestions on what I should do to make the HTML5 spec's
> scope/intro section clearer, please do mail me or the list, I'd be happy to try
> to improve it.)

I don't think it means anything, but I don't think it needs to be improved.
Comment 21 Hixie (not reading bugmail) 2009-02-16 20:29:27 PST
> These answers seem to assume that I have the same completeness criteria that
> you do. I don't.

I'm confused. What is the goal of your document, if not to be a specification? Do you want it to be published through the W3C or something like that, or is this just an informal document?

I don't really understand your goals here.


> > (If you have any suggestions on what I should do to make the HTML5 spec's
> > scope/intro section clearer, please do mail me or the list, I'd be happy to try
> > to improve it.)
> 
> I don't think it means anything, but I don't think it needs to be improved.

You have a strange way of helping...
Comment 22 Robert Sayre 2009-02-16 20:36:43 PST
(In reply to comment #21)
> > These answers seem to assume that I have the same completeness criteria that
> > you do. I don't.
> 
> I'm confused. What is the goal of your document, if not to be a specification?

I just meant that I'm ok with leaving things unspecified or underspecified, since there's plenty of stuff worth publishing now that doesn't suffer from that problem. You're correct that the Rendering section is required for a complete description of (some) older browser features. I think something less than a complete description is ok.
Comment 23 Hixie (not reading bugmail) 2009-02-16 21:21:50 PST
I would strongly object to leaving this undefined in a working group deliverable. I think that defeats the entire point of having a specification. I don't really think it'd be useful, either -- for a description of just the language, we already have Mike's draft; for tutorial-like material, we have Lachlan's work and Dan's work, for the new features we have HTML5. IMHO what we need, if we need anything that resembles a cut-down version of the full spec with UA conformance criteria, is a spec for the old features. We already have a vague description of the old stuff, it's called HTML4.
Comment 24 Robert Sayre 2009-02-16 23:16:25 PST
(In reply to comment #23)
>
> for the new features we have HTML5. 

HTML5 isn't going to get consensus. So, no, we don't have HTML5.
Comment 25 Hixie (not reading bugmail) 2009-02-16 23:25:21 PST
I don't understand what you mean.
Comment 26 Sam Ruby 2009-02-17 04:36:42 PST
As I said in the meeting with both of you present, I not only wouldn't have understood the goals of the WHATWG draft, I would have vehemently objected to them... until I saw the fully fleshed out proposal.  While I differ on a number of specifics, I now enthusiastically endorse the general direction.

Looking at Rob's first draft, I too was unable to extrapolate where he was heading based on that one data point alone.  After two tries, I was finally able to ask coherent questions that satisfied me.

Here's my current understanding: HTML4 is vague and defines a set of features.  Rob's draft adds well defined error handling and a very select few features.  Ian's draft adds (as compared to HTML4) well defined error handling, a rendering section, and quite a bit more features.  To the point that I understand both, at the moment Rob's draft appears to be consistent with the direction that Ian's draft is pursuing, largely by virtue of being a derived work and containing approximately 60 to 65% of the original text verbatim.

Rob's work differs substantially from the work of Mike, DanC and Lachlan.

At some point we really should take a hint from Ian's "(not reading bugmail)".
Comment 27 Robert Sayre 2009-02-17 12:28:44 PST
Discussion is now moved to this mozilla.dev.platform thread:

<http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/0c2bbb6ed726800b>

Please don't add any more here. :)

Note You need to log in before you can comment on or make changes to this bug.