Re: HDP: Revised "Support Existing Content" Principle

Maciej Stachowiak wrote:
> 
> 
> 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>. 
<start quote>
2.1.1. Examples

Many sites use broken markup, such as badly nested elements (<b>a<i>b</b>c</i>),
and both authors and users have expectations based on the error handling used by
legacy user agents. We need to define processing requirements that remain
compatible with the expected handling of such content.

Some sites rely on the <u> element giving the presentational effect of an
underline. "
<end quote>

I don't think you should use broken markup as an example for supporting existing
content.

more useful examples would be

a) "vspace", "hspace", "align" on "img" or "cellpadding", "cellspacing" on "table".
b) some authors use the "alt" tag where the "title" tag may be more appropriate.
c)use of quotes  eg src=test.jpg instead of src="test.jpg"

Marghanita

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


-- 
Marghanita da Cruz
http://www.ramin.com.au
Phone: (+61)0414 869202

Received on Friday, 14 September 2007 01:35:45 UTC