HDP: Revised "Support Existing Content" Principle

I revised the "Support Existing Content" Principle in response to  
feedback in email, in the survey, and from the last telecon.

You can see the results at <http://dev.w3.org/html5/html-design-principles/Overview.html#support-existing-content 
 >.

Here's my responses to some specific comments:

On Aug 22, 2007, at 7:57 AM, Lachlan Hunt wrote:

> 2. Support Existing Content
>
> This principle is essential.  However, there appears to be some  
> misunderstanding as to the purpose of this principle.  In several  
> comments on the survey, people have attempted to apply this  
> principle as an argument to retain certain attributes on the grounds  
> that not making them conforming will break existing content.  
> (Although I'm not particularly sure what relevance such arguments  
> have to the survey itself, beyond making noise about issues they  
> want addressed.)

[...]

> This principle is actually more about processing by user agents, not  
> retaining previous markup from earlier versions.  Existing content  
> would not break by making such attributes non-conforming, as long as  
> the user agent processing requirements remained compatible with the  
> legacy content.  This is not an argument for or against those  
> specific attributes, just an explanation as to why the principle is  
> being misused here.
>

[...]

> It really doesn't matter whether a particular feature was defined in  
> HTML4, XHTML1 or not defined at all (since HTML 1.0 doesn't exist).   
> If there is significant existing content on the web that relies on  
> particular user agent behaviour, then that behaviour should be  
> specified.  This does not imply that such content should be  
> considered conforming.  For example, <marquee> will have processing  
> requirments, but it's not likely to be considered conforming.
>
> Given the amount of confusion, I think it would be wise to clarify  
> the meaning and purpose of the principle.  Ideally, it should  
> clearly describe the situations when it can and can't be applied.
>
> This is my proposed rewording:
>
> Existing legacy content often relies upon expected user agent  
> processing and behaviour to function as intended.  Where possible,  
> processing requirements should be specified to ensure that user  
> agents implementing this specification will be able to effectively  
> handle most legacy content in a way that is compatible with the  
> existing expectations of users and authors, and behaviour of  
> existing browsers.
>
> The effect of all changes applying to the handling of legacy content  
> should be carefully considered with respect to the cost of breaking  
> some content and the expected benefits to be gained from the  
> changes. Changes that break significant content and provide little  
> benefit should be avoided.  Changes that provide significant benefit  
> and break only insignificant or no content should be adopted.

Based on the new Introduction section, I made it more clear that this  
principle applies primarily to the supported language. I also used  
some of your wording in the rewritten principle. Thanks!


On Aug 23, 2007, at 9:01 AM, Richard Ishida wrote:
>
>> 2. Support Existing Content
>
> Strongly agree with the principle per se
> Agree with the wording...
>
> BUT... the spec should not read as if it's ok to continue with less  
> desirable practices.  It should be very clear to the reader that  
> support is provided for legacy documents, but you should not use  
> broken markup, font tags, etc for new content. This should be  
> mentioned in the text for this principle.

I addressed this by clarifying the distinction between what is  
supported and what is conforming. I also added this explicit  
statement: "In some cases, it may be desirable to make a nonstandard  
feature or behavior part of the conforming language, if it satisfies a  
valid use case. However, the fact that something is part of the  
supported language does not by itself mean that relying on it is  
condoned or encouraged."



On Aug 22, 2007, at 8:58 PM, Lachlan Hunt wrote:
>
> Leif Halvard Silli wrote:
>> A new, honest, title is all this principle needs: «UAs Should Support
>> *Significant Existing* Content». Then we would have understood what
>> this is about:
>> Statistics and percentages, again and again.
>
> I didn't say anything about statistics.  Stats by themselves are not  
> the only way to show that something is significant, it's just one of  
> many factors to consider.

Leif and Lachlan, I added wording to make it more clear what kinds of  
considerations are important. Statistics are not the only  
consideration for this principle. Keep in mind that there are also  
other considerations based on the other principles for what should be  
supported, so  even features that don't see any significant use may  
merit inclusion based on the other principes.

 From the telecon minutes:

> Chris: First part - current sites shouldn't stop working. If you
>   make it stronger than it is, we have a problem with things built for
>   IE 6 and whether that has to work for HTML 5. The question is how
>   strongly you take this principle - existing content already does
>   browesr switching. if you make this too strong, then you create
>   problems. IE has to have an HTML 5 mode and we hope not to kee doing
>   that in the future, but current behaviour for old browsers is kind
>   of goofy. I think this is already covered in the text. inclined not
>   to do anything with the first part of the feedback.
>
>   CMN: Yeah, I am happy with the current wording in that respect
>
>   PROPOSED RESOLUTION: We do not strengthen the statement about sites
>   working in HTML 5

I have clarified the principle but have avoided making it a stronger  
statement.

>  PROPOSED RESOLUTION: Strike the sentence "We need to judge whether
>   the value of the change is worth the cost."
>
>   RATIONALE: It's a truism.

I tried to make it clear that supporting existing content is a  
balancing act without resorting to statements that sound like truisms.

>   Laura: "Cross-browser content on the public Web should be given the
>   most weight." should be changed to "Valid markup should be given the
>   most weight, but legacy invalid markup shouldn't stop working."
>
>   <Chris> anyone else have thoughts about the valid markup comment
>   from Laura?
>
>   Chris: I think valid markup should be given the most weight, but
>   saying that legacy invalid markup shouldn't stop working takes a lot
>   of the value out of that statement.
>
>   <mjs> I disagree that valid markup should be given more weight

[...]

>   CMN: I think it should be "well-written markup" that gets weight - a
>   vague term meaning validity, working on lots of browsers, working on
>   mobile, supporting accessibility, are the things that should have
>   weight

[...]

>   <Chris> mjs, what does "cross-browser" capture for you that "valid
>   markup" doesn't?
>
>   <mjs> valid/conforming markup is a minority of web content and
>   non-representative of the general web

[...]

>   <mjs> cross-browser means it works in multiple browsers today


>   <Chris> that's true. Would you give weight to overlapping <b> and
>   <i> tags?
>
>   <mjs> in other words, content that only works in a single version of
>   a single browser might be given less weight
>
>   CMN: [how many is multiple...? mjs, more browers is better as a rule
>   for giving weight?]
>
>   <mjs> overlapping <b> and <i> should continue to be supported in a
>   reasonably compatible way, yes, and I think the spec does that
>
>   Mike: Wellformed etc are relevant to XML, but not really HTML.
>   Sticking to "conformant" makes more sense, but I agree with Maciej
>   that it is not necessary to change this.
>
>   <Chris> I think "cross-browser" actually doesn't capture the
>   majority of web content or is representative of the general web.
>
>   Chris: "works in IE6" probably would, though I'm not suggesting that
>   as a replacement.

[...]

>   Chris: Maybe the right focus is to say "real-world, existing content
>   on the current web should be given the most weight."
>
>   Chris: Validity is perhaps not the best target given today's web.
>   "cross browser as representative of the real world web"
>
>   <mjs> chaals, obviously some of this is too fuzzy to quantify, but I
>   think both the amount of content and how many browsers it works in
>   is relevant:

[...]

>   <mjs> chaals, also popularity of specific sites
>
>   <chaals> [mjs: amount and number of browsers makes sense to me.
>   popularity of specific sites is mor difficult to measure... There
>   are some hideously popular Indian sites with appalling markup...]
>
>   <mjs> Chris: if you factor in both quantity and popularity of
>   content, I think "cross-browser" is a fairly good standard
>
>   Chris: Okay. I think we want wording, then, that captures
>   "real-world, existing content on the web" and "cross-browser"
>   standard.
>
>   <mjs> Chris, the basic idea is if there is some Firefox-only
>   intranet site, we don't necessarily want to cater to every detail it
>   depends on
>
>   <mjs> Chris, in part because we have no way to be aware of all such
>   sites or know anything about what they depend on
>
>   Chris: I get that. But what about IE behavior on the public web,
>   that a lot of public web content relies on.
>
>   CMN: So I am happy with "cross-browser real world content" given
>   this is just a principle, and will make further suggestions in
>   relation to other principles.
>
>   <mjs> If there is a large number of reasonably popular sites that
>   depend critically on some IE-only feature, and currently fail in all
>   other browsers, we should cater to that
>
>   Chris: I'd like to capture cross-browser (I do value that), and
>   "real-world" as separate principles.
>
>   <oedipus> i don't understand what "cross-browser real world content"

[...]

>   Chris: "Real-world content, particularly that supported across
>   browsers, should be given the most weight."?

[...]

>   <MikeSmith> real-world = production sites that are not manufactured
>   for testing but are intended to provide real information or real
>   services to users
>
>   <mjs> Chris, I will take a shot at rephrasing it to indicate that
>   multiple factors are relevant

[...]

>   CMN: When you have the two factors together, they are more important
>   than they would be individually

[...]

>   <chaals> Propose: MJS come up with wording that clarifies the
>   importance of cross browser, real world, working with accessibiltiy
>   technologies, and the combination of these

[...]

>   PROPOSED RESOLUTION: MJS come up with wording that clarifies the
>   importance of cross browser, real world, works with accessibility
>   technology, and the combination of these

I explicitly listed a number of considerations. I did not specifically  
list accessibility technology because I plan to cover this in the  
revised Universal Access principle.

 From the survey:

> Ian Massey: I think that at some point supporting legacy standards  
> and/or writing explicit support for substandard authoring practices  
> becomes more harmful than helpful. The web isn't going anywhere  
> anytime soon, the longer we continue supporting these unfavorable  
> situations, the more difficult it will be when we're finally forced  
> to drop them.
>
> Bob Hopgood: I agree with the need to support existing content in  
> XHTML 1.0 and HTML 4.01 but as written it implies support for HTML  
> 1.0 as well. There are a lot of old elements out there. New HTML 5  
> browsers should not be constrained by so much baggage.

I have clarified when support is important, and that this principle is  
not intended to encourage poor authoring practices.


> Laura Carlson: Delete the sentence: "We need to judge whether the  
> value of the change is worth the cost." That is true of everything.

It's gone. But it is still made clear that this principle is a  
balancing test.

> Laura Carlson: The sentence, "Cross-browser content on the public  
> Web should be given the most weight." should be changed to "Valid  
> markup should be given the most weight, but legacy invalid markup  
> shouldn't stop working."
>
> Philip Taylor: "Cross-browser content on the public Web should be  
> given the most weight." Strongly disagree. "/Valid/ cross- 
> browser ..." should be given the most weight, and invalid content  
> ignored. For the same reason, I strongly disagree that "We need to  
> define processing requirements that remain compatible with the  
> expected handling of such content."
>
> Leif Halvard Sili: * «Cross browser content [etc]t»: To clear up  
> what «existing content» is, I support Laura's proposed change:  
> «Valid markup should be given the most weight, but legacy invalid  
> markup shouldn't stop working.»


Based on the telecon discussions, I haven't made any special mention  
of valid markup. This principle is primarily about the supported  
language, not the conforming language, so valid content does not need  
to get special weight under this principle.

> Karl Dubost: Note: For me the principle has two sub categories
> - Ability to parse the document
> - Ability to make it functional in future applications.
>
> For example a converter (ala tidy) has to be able to parse it to fix  
> the document but not to make it functional. A conformance checker  
> has to be able to parse the existing content but not to make it  
> functional.

I don't think we need to draw a distinction between "parse" and "make  
functional". This is really just a difference in what different  
classes of user agents do with the content, not a distinction in  
principle.

> Nik Thierry: I'd much rather push things forward without having  
> legacy code hold things back. Having IE6 as a legacy browser is hard  
> enough, and by taking a bold step and laying down a line between old  
> and new code will stop the blurring and confusion that comes with  
> legacy support.

I've made clear that this principle applies primarily to the supported  
language, not the conforming language, so the distinction you want  
will be drawn.

> Leif Halvard Silli: The wordig «even if they [...] do not  
> specifically request HTML 5 processing». How can a document «request  
> HTML 5 processing» when we are moving away from a DOCTYPE that tells  
> which version of HTML we are dealing with?

The principle no longer says this.

> * The wording «We need to judge whether the value of the change is  
> worth the cost» is a principle in its own. Remove it.

This sentence is no longer there.

> * What does «change» refer to in this principle? The spec? Well  
> isn't it the spec we are making?

The spec now says "changes to legacy features or behavior, relative to  
current implementations and author expectations".

> In a debate on public-html, the interpretation «changes applying to  
> the handling of legacy content» was proposed, and qualified with the  
> word «significant»: «significant content» [1]. Further, to  
> demonstrate that «significant» was not meant purely as a reference  
> to quantity, an related WhatWG IRC debate was quoated where, as  
> first requirement, it was stated that one should look for «use  
> cases» to justify that UAs support existing legacy content. [2] As  
> if <b>a<i>b</b>c</i> has a use case?

I made more clear what counts as significant. Valid use cases are not  
part of the relevant considerations for this principle; that's  
primarily important for what is part of the conforming language, not  
part of the supported language.


Regards,
Maciej

Received on Thursday, 13 September 2007 21:01:33 UTC