Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1)

On Oct 10, 2009, at 12:43 PM, Manu Sporny wrote:

>
> I think you're missing Toby's point. Let me attempt to elaborate in
> order to shed some light on the issue.
>
> At present, your statement that HTML5 will "never break backwards
> compatibility with existing content" is not true. HTML5 breaks  
> backward
> compatibility in many (good) ways... it obsoletes a number of HTML  
> features:
>
> http://dev.w3.org/html5/spec/Overview.html#non-conforming-features

That's not breaking backwards compatibility. If HTML4 content uses any  
of these features, it will continue to work as expected in an HTML5  
UA. It just won't be conforming. This is a key design goal for HTML5.

>
> Now, I don't know the intent of the Non-conforming features section,  
> but
> after reading Section 12.2, if I were to write a User Agent - I expect
> that I wouldn't have to support any of those features. For example, if
> my web browser saw <center>, it would ignore it completely and be  
> fully
> conformant with the HTML5 specification, IIRC.

That would not be a conforming implementation of HTML5. HTML5 requires  
you to respect the centering:

http://dev.w3.org/html5/spec/Overview.html#alignment

'The center element, the caption element unless specified otherwise  
below, and the div element when its align attribute's value is an  
ASCII case-insensitive match for the string "center", are expected to  
center text within themselves, as if they had their 'text-align'  
property set to 'center' in a presentational hint, and to align  
descendants to the center.'

This is the approach HTML5 takes to essentially all obsolete features  
- implementations are still required to support the behavior, even  
though the feature itself is nonconforming.

> Since most HTML4 documents are now magically HTML5 documents, how does
> this not break backward compatibility in this particular scenario?  
> In an
> HTML5 conformant browser, suddenly, text will no longer be required to
> be centered.

This paragraph is based on an incorrect premise.

> How do we allow for deep changes to a language in the future, but  
> ensure
> backwards compatibility for those that want to ensure their document  
> is
> processed in the same way in the future? That is the question that the
> HTML5-EPB[1] spec attempts to answer.

Many of us don't want to allow for deep changes to HTML in the future.  
The primary reason HTML5 exists was to avoid incompatible changes.  
Otherwise we'd all be working on XHTML2.

>
> Somebody that is far more knowledgeable and astute than I am (I'm
> looking at you Dan Connolly) about the history of HTML and what
> compatibility was or was not broken from version to version will  
> have to
> enlighten us. Specifically, on whether your assertion that pre-HTML5
> hasn't broken backwards compatibility and depended on the @version
> attribute to differentiate between different versions of the spec,  
> is true.

It's definitely true that browsers have never paid attention to the  
legacy @version attribute to apply different processing. (Browsers do  
look at the DTD, but only to decide between quirks, limited quirks and  
standards mode, which mainly affects CSS; they do not use it to treat  
HTML 3.2 differently than HTML 4.)

>
> * HTML5 breaks backwards compatibility for several good reasons.

I think your belief that it does is based on a misunderstanding.

> * There is currently no way for an author to specify that they would
>   like their documents to be processed as HTML5 instead of HTML6.

We don't need a way for authors to say that. And having a way to do it  
could have harmful side effects.

> * There is currently no way for an author to specify that their
>   document uses a number of extended processing behaviors built on top
>   of HTML5.

That seems like a completely separate issue from versioning the HTML  
language itself.

> * There is currently no way for an author to specify that their
>   document should be processed via extended processing behavior
>   using FeatureX version 1.0 instead of FeatureX version 2.0.

This too.

> As I've stated previously, this is a technical issue and is directly
> relevant to XMLLiteral generation in RDFa 1.0 vs. RDFa 1.1.

Since existing RDFa content mostly doesn't use the version attribute,  
it's unclear how the version attribute is part of the solution to that  
problem.

Regards,
Maciej

Received on Sunday, 11 October 2009 04:20:22 UTC