This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7034 - authoring conformance requirements in the spec should either be removed or replaced
Summary: authoring conformance requirements in the spec should either be removed or re...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://lists.w3.org/Archives/Public/p...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-18 04:58 UTC by Michael[tm] Smith
Modified: 2010-10-04 14:56 UTC (History)
10 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2009-06-18 04:58:20 UTC
Please change all instances of the phrase "conformance checker" in the spec to either "ideology checker" or "loyalty checker".
Comment 1 Kornel Lesinski 2009-06-18 09:47:55 UTC
This change won't be complete without changing Ian's title to "Supreme Leader" and renaming Working Group to "Highest Echelons of HTML".
Comment 2 Larry Masinter 2009-06-18 10:05:11 UTC
The role of the specification in providing appropriate normative advice for authors, authoring tools, dynamic HTML generation tools and others that wish to be "conservative in what they send" is a legitimate question. Because many web "authors" might not pay attention to such advice is no reason not to provide it or proof that such advice is useless or worthy of ridicule.

Comment 3 Michael[tm] Smith 2009-06-18 13:50:46 UTC
(In reply to comment #2)
> The role of the specification in providing appropriate normative advice for
> authors, authoring tools, dynamic HTML generation tools and others that wish to
> be "conservative in what they send" is a legitimate question. Because many web
> "authors" might not pay attention to such advice is no reason not to provide it
> or proof that such advice is useless or worthy of ridicule.

If you're concerned that the existence of this particular bugzilla issue is somehow an attempt to suggest that such advice is useless, I think you can rest assured that it is not. As far as I can see at least, the context isn't at all about what whether such advice is useful; the context instead is general agreement that such advice is in fact very useful, but with disagreement about what the specific nature and scope of that advice should be -- with some (arguably lame) attempts at humor (not ridicule) thrown in.
Comment 4 Michael[tm] Smith 2009-06-18 13:51:12 UTC
(In reply to comment #2)
> The role of the specification in providing appropriate normative advice for
> authors, authoring tools, dynamic HTML generation tools and others that wish to
> be "conservative in what they send" is a legitimate question. Because many web
> "authors" might not pay attention to such advice is no reason not to provide it
> or proof that such advice is useless or worthy of ridicule.

If you're concerned that the existence of this particular bugzilla issue is somehow an attempt to suggest that such advice is useless, I think you can rest assured that it is not. As far as I can see at least, the context isn't at all about what whether such advice is useful; the context instead is general agreement that such advice is in fact very useful, but with disagreement about what the specific nature and scope of that advice should be -- with some (arguably lame) attempts at humor (not ridicule) thrown in.
Comment 5 Rob Sayre 2009-06-18 18:52:30 UTC
(In reply to comment #2)
> The role of the specification in providing appropriate normative advice for
> authors, authoring tools, dynamic HTML generation tools and others that wish to
> be "conservative in what they send" is a legitimate question.

I agree that it is a legitimate question, although IMO instructions on how to produce a well-crafted HTML page are best left to another document. I do not think the current requirements lead authors to be conservative in what they send. In many contexts, <center> and <font> are the conservative choice.
Comment 6 Larry Masinter 2009-06-18 20:52:32 UTC
Seems like everyone agrees that 

(a) there is a serious issue: the nature of conformance
(b) the "bug" as stated is a joke -- argument-by-ridicule.

The "bug" as written implies that checking conformance is as meaningless as checking ideology or loyalty.

If this isn't going to remain a joke, please change the 'bug' to identify the actual issue.
Comment 7 Michael[tm] Smith 2009-06-18 22:53:08 UTC
(In reply to comment #6)
> If this isn't going to remain a joke, please change the 'bug' to identify the
> actual issue.

I can't see much of a point in keeping this issue open, so I'm closing it. We can continue the discussion on the list.
Comment 8 Michael[tm] Smith 2009-06-18 23:18:44 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > If this isn't going to remain a joke, please change the 'bug' to identify the
> > actual issue.
> 
> I can't see much of a point in keeping this issue open, so I'm closing it. We
> can continue the discussion on the list.

To clarify, what I meant there was I don't see a point in keeping this bugzilla item open. I do see a point in keeping the general issue open for discussion on the list (instead of limiting it to discussion here). 

Comment 9 Rob Sayre 2009-06-18 23:20:16 UTC
This bug shouldn't be closed, it's totally valid
Comment 10 Michael[tm] Smith 2009-06-18 23:30:20 UTC
(In reply to comment #9)
> This bug shouldn't be closed, it's totally valid

If you can offer some appropriate alternative wording for the summary (as Larry suggests), I will happily re-open it.
Comment 11 Rob Sayre 2009-06-19 00:12:16 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > This bug shouldn't be closed, it's totally valid
> 
> If you can offer some appropriate alternative wording for the summary (as Larry
> suggests), I will happily re-open it.

If this were a normal bug tracker, I would just reopen it myself. The current title seems fine to me, but Larry is welcome to change it.
Comment 12 Maciej Stachowiak 2009-06-19 04:01:00 UTC
(In reply to comment #4)

> If you're concerned that the existence of this particular bugzilla issue is
> somehow an attempt to suggest that such advice is useless, I think you can rest
> assured that it is not. As far as I can see at least, the context isn't at all
> about what whether such advice is useful; the context instead is general
> agreement that such advice is in fact very useful, but with disagreement about
> what the specific nature and scope of that advice should be -- with some
> (arguably lame) attempts at humor (not ridicule) thrown in.
> 


As far as I can tell, the bug is ridiculing the idea of having authoring conformance requirements, or at least ridiculing the specific authoring conformance requirements that are currently in the spec. I do not see any constructive suggestions for change or flagging of concrete problems in the summary or description, just snark.

In my opinion, this bug should be closed. If anyone would like to raise real issues with conformance requirements, or even make a sincere suggestion that authoring conformance requirements should be removed, then that would be a reasonable bug report. This bug report is just ridiculous and insulting.
Comment 13 Sam Ruby 2009-06-19 10:15:43 UTC
(In reply to comment #12)
> 
> In my opinion, this bug should be closed. If anyone would like to raise real
> issues with conformance requirements, or even make a sincere suggestion that
> authoring conformance requirements should be removed, then that would be a
> reasonable bug report. This bug report is just ridiculous and insulting.

The current title (not set by me) reads "authoring conformance requirements in the spec should either be removed or replaced".  Rob Sayre seems sincere in that suggestion.  In my opinion, Maciej's concerns are addressed by this change... Maciej: do you agree?

In my opinion, this bug report would be strengthened by mentioning one or more tools that are impacted adversely by these Author conformance requirements.

It would also be helpful to discuss whether things like misnested elements "<b><i>foo</b></i>" and &foo= in href values should be considered harmful.  Having authoring /tools/ (as contrasted with hand-authored markup) emit such is often a sign of deeper issues.

My own personal opinion is that the current conformance requirements are judgment calls and seem to focus more on the ideal held by a some as to how hand-authored content should look.  I've seen plenty of evidence that dropping quotes around attribute values causes problems, and meta charset is a consequence of that.  If the conformance requirements were more comprehensive, and split into categories (example: those issues that are indicative of structural problems, markup that has proven to be error prone, and markup where there are preferred alternatives), I could be happy with that too.  Meanwhile, consider me as one of those who are unhappy with the current draft in this respect.

Comment 14 Anne 2009-06-19 10:36:45 UTC
(FWIW, it seems more likely meta charset was a consequence of bogus charset scanners that just looked for the string charset rather than doing proper tokenization.)
Comment 15 Michael[tm] Smith 2009-06-19 10:47:10 UTC
(In reply to comment #13)
> It would also be helpful to discuss whether things like misnested elements
> "<b><i>foo</b></i>"

I would think most everybody agrees that misnested elements are harmful. And the spec currently does define misnested elements as an authoring conformance error (though IMHO at least, it could do so much more explicitly than it does now).

> and &foo= in href values should be considered harmful.

The case of &foo= seems to me to be in very different class than that of misnested elements. It is not just markup, it occurs much more commonly, and is not clearly/intuitively an error. Intuitively, I would think I should be able to copy a URL from the address bar of my browser and copy into the source for any HTML page I'm authoring.

> Having authoring /tools/ (as contrasted with hand-authored markup) emit such is
> often a sign of deeper issues.

Ah, OK, I get your point there. But if you're talking about content emitted by tools, I'd guess that there there are too few (or no) otherwise useful tools that emit "<b><i>foo</b></i>" -- but there are some quite capable ones that will gladly emit &foo= in the value of a href attribute, if the user puts it into the tool that way. I don't think that case on its own would be a sign of any deeper issue.

> My own personal opinion is that the current conformance requirements are
> judgment calls

And my own personal opinion is that while some of them are, most of them are not, but instead are mostly based on some careful consideration of what requirements are optimal, and mostly reflect best practice.

For the ones that are closer to judgment calls, I think those fall into a large gray where, to paraphrase Henri, you need to decide whose time it is most important for you not to waste; that is, that it's a case of choosing between on the one side the risk of perpetuating greater confusion among new authors who are trying to learn the language, and on the other side, wasting the time of experienced authors who know what they're doing and who, for example, don't care to have conformance checkers peppering them with reports about deprecated attributes that they are using intentionally.

> [...] If the conformance requirements were more comprehensive,
> and split into categories (example: those issues that are indicative of
> structural problems, markup that has proven to be error prone, and markup where
> there are preferred alternatives),

Categorizing them in the way seems like a useful task that we maybe should try to get some members of the group to volunteer to do. 
Comment 16 Maciej Stachowiak 2009-06-19 16:36:00 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > 
> > In my opinion, this bug should be closed. If anyone would like to raise real
> > issues with conformance requirements, or even make a sincere suggestion that
> > authoring conformance requirements should be removed, then that would be a
> > reasonable bug report. This bug report is just ridiculous and insulting.
> 
> The current title (not set by me) reads "authoring conformance requirements in
> the spec should either be removed or replaced".  Rob Sayre seems sincere in
> that suggestion.  In my opinion, Maciej's concerns are addressed by this
> change... Maciej: do you agree?
> 

The title now strikes a more appropriate tone. But it's still not specific enough. It's like having a bug report that says "the spec should be changed".

Sam, you listed a grab gab of conformance requirements which should maybe be strengthened or relaxed, but it's not clear to me if this matches the set that Mike or Rob were concerned about. And my impression is that Rob would like *all* authoring conformance requirements removed, not just modified.

What we could use is bug reports or tracker issues that suggest (a) removing all authoring conformance requirements; or (b) removing specific authoring conformance requirements; or (c) changing specific conformance requirements in particular ways. For example, "<font> should be conforming" would be sufficiently specific to drive useful discussion.

As it stands, everyone has a different idea of what this bug means, so we can't tell when it is addressed.

(Side note: I personally think at least some of the authoring conformance requirements should be relaxed. I used to think removing all of them made sense, but Henri convinced me otherwise. I'm not sure if the set I think should go matches anyone else's, so I can't tell if agree with the substance of this bug or not. This is why concrete issues would be much more helpful than this vague meta-bug.)
Comment 17 Larry Masinter 2009-06-19 17:06:54 UTC
Conformance requirements are always judgment calls. It is contradictory to say they are not, but instead "careful consideration of what requirements are optimal" and "mostly reflect best practice", as these both require judgments. Different constituencies may have different values that they are trying to maximize ("optimal"), or have different judgments as to the effect of a requirement against their values.  Different constituencies may consider different practices to be significant, and have different criteria for what is "best". Of course there is judgment. We should try to find consensus on requirements even if there is not consensus on goals.

To address authoring requirements specifically, I suggest spending a little (limited, please) time on trying to find some agreement on design principles for authoring conformance requirements.  I know this will be contentious, but hopefully useful. For example, "allow use of XML downstream processing", "be compatible not only with HTML5 implementations but also older deployed browsers such as IE6", "preserve document modularity so that copy/paste is more likely to be reliable", "be already supported in popular proprietary authoring tools". (I threw that in for humor.)

If splitting out the authoring requirements into a separate document would then allow more careful review by the affected communities (mainly non-browser community consisting of builders of authoring tools, validators, post-processors, content management systems, template creators, etc. as well as their significant user communities of web designers, coders, etc.), that would be very helpful.




Comment 18 Ian 'Hixie' Hickson 2009-06-26 09:17:16 UTC
I don't understand what change to the spec this bug is requesting at this point.
Comment 19 Maciej Stachowiak 2010-03-14 14:48:17 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 20 Sam Ruby 2010-03-14 17:19:20 UTC
At the present time, the only effective means by which a working group participant can obtain a rationale for why any given restriction is included in the spec is to file a bug and ask for that restriction to be removed.  In this case, we have a large number controversial restrictions for which there is no single place that a person can go to find the answer as to why those restrictions were put in there in the first place.

I'm open to proceeding with a separate bug or change proposal for each attribute or element that is commonly used, or with a single omnibus bug report such as this one, or with escalating this as a single issue.

To make this more specific, I believe that conformance rules and conformance checkers are a good thing to have -- but only so far as those conformance rules are ones that are likely to be followed once a reasonable person is made aware of the rule.  When rules are put in place that large number of people will willfully violate, the end result is undermine the integrity of the standard.

I will suggest that http://google.com/ as a starting point.  I believe that the people who put that page together are both reasonable and highly knowledgeable about what is the most effective use of markup.  I will also suggest at the current time, any browser that failed to render that particular page acceptably is simply not viable.

At the present time, the HTML5 validator produces 47 messages -- some of them warnings, most of the errors -- on that page.  I believe that the optimum number is zero.

The overwhelming majority of such messages fall into two categories.  

The first is the use of unescaped attributes inside of URLs as attribute values.  In rare cases, such usage can be mistaken a character reference, but none of these occurrences on this page have any danger of being mistaken in this way, and therefore should be allowed.

The second is the use of mostly attributes and a few elements which perform layout functions: spacing, margins, width, align, wrapping, centering, clearing.  Apparently, the rules for when it would be best to use these allegedly obsolete elements vs when to use CSS are not yet universally agreed to, at least not in the context of this page.

I believe that there is value in both set of checks, but I don't believe that either should be mandatory.  And there is a reasonable discussion which can be had as to whether authors should state their intent to conform to these additional restrictions inside the markup itself or outside of the markup (e.g., in the UI of a validator).

Again, whether this is to be pursued as 1, 2, or 20+ bugs, or as an equal number of change proposals, or on the mailing list (which also has been discouraged as not a great use of the groups time[1]), I care not.

[1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0310.html
Comment 21 Maciej Stachowiak 2010-03-14 17:43:49 UTC
(In reply to comment #20)
> At the present time, the only effective means by which a working group
> participant can obtain a rationale for why any given restriction is included in
> the spec is to file a bug and ask for that restriction to be removed.  In this
> case, we have a large number controversial restrictions for which there is no
> single place that a person can go to find the answer as to why those
> restrictions were put in there in the first place.
> 
> I'm open to proceeding with a separate bug or change proposal for each
> attribute or element that is commonly used, or with a single omnibus bug report
> such as this one, or with escalating this as a single issue.

My recommendation:

At the very least you should list the specific changes you're proposing. Ideally a separate bug for each (so we can have a clear record in bugzilla of which were accepted and which were reected)., but listing them all in this bug would still be an improvement on the current state. Given the current contents of the bug, it's not possible to tell what kinds of changes would satisfy your request.

However, one bug per issue is even better than an "omnibus bug report". One bug per issue is good because the requests can be fielded individually, and we end up with a clear record of which requests were accepted or rejected and why, and which change was made for each.

(In reply to comment #20)
> I will suggest that http://google.com/ as a starting point.
[...]
> At the present time, the HTML5 validator produces 47 messages -- some of them
> warnings, most of the errors -- on that page.  I believe that the optimum
> number is zero.

Would turning all of these errors into non-errors be necessary and sufficient to satisfy your request? If so, that should be sufficient information, and there would be no need to list which rules you think should change in more detail (though it would be useful to paste in the current error log in the bug for reference).
Comment 22 Larry Masinter 2010-03-14 18:13:54 UTC
A "HTML5 differences from HTML4" that satisfied the request from Marcos Caceres (Opera):

http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0003.html

might make reviewing authoring requirements and the changes from HTML4 feasible. 

Marcos wrote: "I've reviewed this document with my "author" and "generally interested in this stuff" hat on."

Of course, Marcos' comment is on another document, but in this case there is some coordination required.

To make the request explicit for this document: 

For every section in the HTML5 document, if the authoring requirements for HTML5 are different from the authoring requirements for HTML4, provide a direct link to the explanation in the "differences" document that explains the reason for the change. 

 If the "differences" document doesn't provide such an explanation, then please submit a bug on the "differences" document, including (in the bug report) sufficient information so that the author(s) of the "differences" document can provide this information.

Having this "differences" information would facilitate the otherwise nearly impossible review of HTML5 conformance changes.
Comment 23 Maciej Stachowiak 2010-03-14 18:49:47 UTC
(In reply to comment #22)

> 
> To make the request explicit for this document: 
> 
> For every section in the HTML5 document, if the authoring requirements for
> HTML5 are different from the authoring requirements for HTML4, provide a direct
> link to the explanation in the "differences" document that explains the reason
> for the change. 
> 
>  If the "differences" document doesn't provide such an explanation, then please
> submit a bug on the "differences" document, including (in the bug report)
> sufficient information so that the author(s) of the "differences" document can
> provide this information.
> 
> Having this "differences" information would facilitate the otherwise nearly
> impossible review of HTML5 conformance changes.
> 

Would you mind filing a new bug with that suggestion? It seems to me that, notwithstanding the merits of the suggestion, making this change would not address the original intent of the bug, which is to remove some or all authoring conformance requirements. (That is to say, if your suggested change was made, I don't think that would lead the people requesting removal of some/all requirements to conclude that no further change is needed.)
Comment 24 Sam Ruby 2010-03-14 20:49:59 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > At the present time, the only effective means by which a working group
> > participant can obtain a rationale for why any given restriction is included in
> > the spec is to file a bug and ask for that restriction to be removed.  In this
> > case, we have a large number controversial restrictions for which there is no
> > single place that a person can go to find the answer as to why those
> > restrictions were put in there in the first place.
> > 
> > I'm open to proceeding with a separate bug or change proposal for each
> > attribute or element that is commonly used, or with a single omnibus bug report
> > such as this one, or with escalating this as a single issue.
> 
> My recommendation:
> 
> At the very least you should list the specific changes you're proposing.
> Ideally a separate bug for each (so we can have a clear record in bugzilla of
> which were accepted and which were reected)., but listing them all in this bug
> would still be an improvement on the current state. Given the current contents
> of the bug, it's not possible to tell what kinds of changes would satisfy your
> request.
> 
> However, one bug per issue is even better than an "omnibus bug report". One bug
> per issue is good because the requests can be fielded individually, and we end
> up with a clear record of which requests were accepted or rejected and why, and
> which change was made for each.

I think that there are at least two "classes" of bugs.

One deals with using conformance criteria to selectively prefer stricter syntax in order to reduce errors.  Always quoting attributes, always explicitly closing open tags, and always escaping ampersands in content are three examples of such features which have been requested, only one of which has been adopted by the current specification.  The number of such cases to consider is quite small.  (Another example would be the fact that double dashes are not allowed in comments).

A second deals with using conformance criteria to enforce one common approach to style, namely CSS.  In total, there are literally dozens of attributes and/or elements which are deprecated for this reason.

> (In reply to comment #20)
> > I will suggest that http://google.com/ as a starting point.
> [...]
> > At the present time, the HTML5 validator produces 47 messages -- some of them
> > warnings, most of the errors -- on that page.  I believe that the optimum
> > number is zero.
> 
> Would turning all of these errors into non-errors be necessary and sufficient
> to satisfy your request? If so, that should be sufficient information, and
> there would be no need to list which rules you think should change in more
> detail (though it would be useful to paste in the current error log in the bug
> for reference).

Google is just one example of a high profile site, though it is one that has chosen to adopt the HTML5 Doctype and has yet to adopt the conformance criteria.

So: necessary?  Probably, though there may be one or two cases that can be defended.  Sufficient?  Unlikely, but I do believe that a point of diminishing returns would occur after the first few dozen sites.

The goal would be to make HTML5 an inviting place, where the actual error messages produced by the validator indicate places where something unlikely to be intentionally done was encountered in the document.  Over top of this can be additional checks that the author can opt into should they desire, and we could discuss various alternative methods by which one could opt in.

Finally, by making the controversial checks opt-in, we have the possibility of significantly reducing the number of open issues:

http://lists.w3.org/Archives/Public/public-html/2010Mar/0314.html
Comment 25 Maciej Stachowiak 2010-03-15 01:42:10 UTC
(In reply to comment #24)

> 
> I think that there are at least two "classes" of bugs.
> 
> One deals with using conformance criteria to selectively prefer stricter syntax
> in order to reduce errors.  Always quoting attributes, always explicitly
> closing open tags, and always escaping ampersands in content are three examples
> of such features which have been requested, only one of which has been adopted
> by the current specification.  The number of such cases to consider is quite
> small.  (Another example would be the fact that double dashes are not allowed
> in comments).
> 
> A second deals with using conformance criteria to enforce one common approach
> to style, namely CSS.  In total, there are literally dozens of attributes
> and/or elements which are deprecated for this reason.

It would definitely be helpful to have at least one bug per "class" of proposed removals, additions, changes, or modifications of status from mandatory error to optional check.

> > Would turning all of these errors into non-errors be necessary and sufficient
> > to satisfy your request? If so, that should be sufficient information, and
> > there would be no need to list which rules you think should change in more
> > detail (though it would be useful to paste in the current error log in the bug
> > for reference).
> 
> Google is just one example of a high profile site, though it is one that has
> chosen to adopt the HTML5 Doctype and has yet to adopt the conformance
> criteria.
> 
> So: necessary?  Probably, though there may be one or two cases that can be
> defended.  Sufficient?  Unlikely, but I do believe that a point of diminishing
> returns would occur after the first few dozen sites.

OK, sounds like we need more details on what conformance criteria you propose adding, removing, or making optional. If there are thematically related sets (like "all presentational attributes and elements" or "proposed optional checks for stricter XML-like syntax") then one bug per set would be fine, but ideally it should still define what's in it.

Note: I have no particular interest either way in any of the types of changes you have described. I simply want bugzilla to end up with well-defined, actionable bugs. Right now this bug report amounts to "please add and/or remove some conformance criteria" with hints of the kinds of changes to make, but not enough detail to determine what set of changes would be sufficient.

> 
> The goal would be to make HTML5 an inviting place, where the actual error
> messages produced by the validator indicate places where something unlikely to
> be intentionally done was encountered in the document.  Over top of this can be
> additional checks that the author can opt into should they desire, and we could
> discuss various alternative methods by which one could opt in.
> 
> Finally, by making the controversial checks opt-in, we have the possibility of
> significantly reducing the number of open issues:
> 
> http://lists.w3.org/Archives/Public/public-html/2010Mar/0314.html

Out of the issues that deal solely with document conformance, it doesn't seem to me that any fall into the categories you described above. (Out of the 12 issues that are purely about document conformance, I see 2 about making HTML4 accessibility features conforming again, 4 about making legacy metadata conforming, 2 about changing the mechanics of registries from wiki to something else, and 4 that propose adding new more restrictive conformance requirements on content models.)
Comment 26 Larry Masinter 2010-03-15 23:24:53 UTC
It has frequently been observed that many of the topics expressed as "authoring conformance" are primarily a matter of "document conformance": a conforming authoring tool or content generation tool MUST (first and foremost) generate conforming documents. There may be other requirements for "authoring tool" conformance as well, such as following accessibility guidelines.

I think discussion of where "authoring conformance" belongs may be easier to sort out if the distinction is made more explicit.

Comment 27 Michael[tm] Smith 2010-03-16 01:55:06 UTC
(In reply to comment #26)
> It has frequently been observed that many of the topics expressed as "authoring
> conformance" are primarily a matter of "document conformance": a conforming
> authoring tool or content generation tool MUST (first and foremost) generate
> conforming documents. There may be other requirements for "authoring tool"
> conformance as well, such as following accessibility guidelines.
> 
> I think discussion of where "authoring conformance" belongs may be easier to
> sort out if the distinction is made more explicit.

Agreed. Another example of an authoring-conformance requirement that's not a document-conformance requirement is http://dev.w3.org/html5/spec/syntax.html#the-doctype - the "The DOCTYPE legacy string should not be used unless the document is generated from a system that cannot output the shorter string." statement.

Granted, that's only a SHOULD-level requirement. But it nevertheless states conformance criteria that is not checkable given a document alone; checking it instead also requires that you have some knowledge of how the document was generated.

Anyway, I think as far as making things more explicit, the distinction is that document-conformance requirements can be checked by looking at a document in isolation from however it was generated or in isolation from whoever wrote it.
Comment 28 Leif Halvard Silli 2010-03-19 13:23:02 UTC
(In reply to comment #22)
> A "HTML5 differences from HTML4" that satisfied the request from Marcos Caceres
> (Opera):
> 
> http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0003.html
> 
> might make reviewing authoring requirements and the changes from HTML4
> feasible. 

Ai ai. I had not seen his comments. My impression from Anne when I discussed what the diff doc says about SGML features, was that the HTML4-diffs document is meant as a PR document - for "the bloggers" - those who don't need to read the details. 

I have been thinking of writing my own HTML4 diffs document lately .... Big thank to Marcos.
Comment 29 Larry Masinter 2010-03-19 20:47:27 UTC
> Another example of an authoring-conformance requirement that's not a
> document-conformance requirement is
> http://dev.w3.org/html5/spec/syntax.html#the-doctype - the "The DOCTYPE legacy
> string should not be used unless the document is generated from a system that
> cannot output the shorter string." statement.
> 
> Granted, that's only a SHOULD-level requirement. But it nevertheless states
> conformance criteria that is not checkable given a document alone; checking it
> instead also requires that you have some knowledge of how the document was
> generated.
> 
> Anyway, I think as far as making things more explicit, the distinction is that
> document-conformance requirements can be checked by looking at a document in
> isolation from however it was generated or in isolation from whoever wrote it.

While I appreciate the support, I don't really agree with your example.

The distinction between "MUST" and "SHOULD" in conformance requirements is that "SHOULD" allows some wiggle-room: implementations can be conforming and yet not implement "SHOULD" in situations where there are well known, understood, and established exceptional circumstances. The presence of a DOCTYPE in one or another well-known format can be a document conformance requirement (SHOULD) even if the exceptions are because of other reasons relating to deployment, compatibility with legacy workflows, or even social engineering (convincing the authoring community to adopt new practices that were previously not widespread.)

I don't think the fact that the applicability of exceptions might depend on context means that a conformance requirement that applies to documents automatically is re-categorized as an authoring tool conformance requirement.

Comment 30 Maciej Stachowiak 2010-03-20 03:02:27 UTC
For reference, I checked the validator errors on http://google.com/ in detail, and every single one of them falls into one of the following categories:

- Use of presentational attributes that HTML5 considers obsolete.
- Use of presentational elements that HTML5 considers obsolete.
- Use of unescaped & in URL-valued attributes.

(I did notice bug 9286 in the course of reviewing the errors.)
Comment 31 Sam Ruby 2010-03-20 05:25:03 UTC
(In reply to comment #30)
> For reference, I checked the validator errors on http://google.com/ in detail,
> and every single one of them falls into one of the following categories:
> 
> - Use of presentational attributes that HTML5 considers obsolete.
> - Use of presentational elements that HTML5 considers obsolete.
> - Use of unescaped & in URL-valued attributes.

I've expanded this analysis to a few more sites:

http://intertwingly.net/blog/2010/03/20/Authoring-Conformance-Requirements
Comment 32 Sam Ruby 2010-03-21 11:57:09 UTC
Clear statement of the problem:

The overwhelming majority of the Author Conformance Requirements that are contained in the spec cover situations that pose no real interoperability problems.  Not only is this an incorrect application of RFC 2119, as a strategy, it is entirely self-defeating.  Specs that contain such requirements will be willfully, flagrantly, and widely violated.  Furthermore, such requirements that have no basis in interop issues and describe situations that either authors or tools will commonly violate cause validators to produce volumes of spurious issues that only serve to obscure real problems.

Specifically problematic are the Author Conformance Requirements that essentially treat the web as being versioned and/or define personal preferences which are not universally shared.  It simply is not a viable strategy to revisit the web every decade or so and declare documents that conform to recommendations that were made as little as a decade ago as now non-conformant without a clear and significant problem.  As an example: "CSS would be better" is not such a problem.

Issue:

Author Conformance Requirements exist in the spec for which there is no documented rationale and over which there is no consensus.

Sections affected:

Effectively the whole specification.

One suggested way to solve the problem:

Remove and and all author conformance requirements which cover markup that poses no significant interop issues.

Additional analysis can be found here:

http://www.w3.org/html/wg/wiki/HTML5_Authoring_Conformance_Study#Methodology
Comment 33 Larry Masinter 2010-03-22 16:26:45 UTC
See  http://masinter.blogspot.com/2010/03/browsers-are-rails-web-sites-are-trains.html  for a take on why document and authoring conformance requirements are useful and what purpose they serve.

Comment 34 Sam Ruby 2010-03-22 18:07:20 UTC
(In reply to comment #33)
> See 
> http://masinter.blogspot.com/2010/03/browsers-are-rails-web-sites-are-trains.html
>  for a take on why document and authoring conformance requirements are useful
> and what purpose they serve.

Conformance requirements that prevent trains from going off the rails are clearly useful.  I will assert that not a single one of the following "errors" fall into that category:

http://validator.w3.org/check?uri=http%3A%2F%2Fgoogle.com%2F

Example: google.com uses the "align" attribute on "td" elements.  More than a few people use this site.  If this were to cause real-world problems, you would think that there would be some evidence of this.

I believe that every single "error" reported on that page falls into the RFC 2119 definition of SHOULD: "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

I further believe that HTML5 could be significantly improved if the "errors" that have nothing to do with keeping the train on the rails were removed from the HTML5 specification, and placed into a separate specification.  The IETF has an entirely sane process for this, it is called "Best Current Practices" or "BCP". I believe that such a document could include "don't use presentational markup, use CSS" as well as "explicitly close all open non-void tags".

These two documents could also proceed on entirely different schedules.
Comment 35 Ian 'Hixie' Hickson 2010-03-27 04:44:28 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: 

It's very unclear to me what this bug is actually requesting. However, based on some of the comments above and on some of the mailing-list discussion on this bug, I have added a section to the spec describing in detail many of the reasons for having authoring conformance criteria. Hopefully this provide the rationale that some have requested, while explaining to others why conformance criteria are in fact an important part of a language specification.

Incidentally, I would like to request that anyone tempted to reopen this bug again to please open a new bug instead, so that there is a clear statement explaining the purpose of the bug. I do not wish to discourage anyone from opening a new bug, it's just that this one started as a joke, and then morphed several times on the basis of various people's concerns, such that at this stage it really covers multiple topics, and this is not really in line with our stated process. Thanks.
Comment 36 contributor 2010-03-27 04:44:43 UTC
Checked in as WHATWG revision r4876.
Check-in comment: Provide rationale for authoring conformance criteria.
http://html5.org/tools/web-apps-tracker?from=4875&to=4876
Comment 37 Sam Ruby 2010-03-30 21:04:35 UTC
(In reply to comment #35)
> at this
> stage it really covers multiple topics, and this is not really in line with our
> stated process.

At this stage, in addition to the various bugs that have been filed and continue to be filed[1], I am concerned about one single overarching aspect: reuse of existing MIME types and XML namespaces in a way that makes prior uses non-conforming.  I care not about whether that's a separate bug, a reopening of this bug, or an escalation.  I'm also quite willing to wait while the other bugs run their course as it might very well turn out that the incompatibilities that have been introduced in HTML5 will be reverted.

[1] http://www.w3.org/html/wg/wiki/HTML5_Authoring_Conformance_Study#Bugs_Filed_Against_Spec