- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 28 Mar 2010 01:45:37 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7468 Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Simetrical+w3cbug@gmail.com --- Comment #9 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2010-03-28 01:45:36 --- I agree with Sam that at least until such time as <style scoped> is reliably implemented, it would be better if cellpadding, border, and cellspacing (as well as possibly some other presentational elements/attributes that don't map easily to inline CSS) were conforming. Perhaps they could be obsolete but conforming. My understanding is that "obsolete but conforming" is used when something should be obsolete, but where it's harmless and permitting it for now would significantly ease transition to HTML5. I believe this applies to the three attributes that Sam mentions, and to any other presentational attributes that cannot be easily mapped to inline style yet in practice. For what it's worth, it will not be realistically possible for MediaWiki (or Wikipedia) to output conforming HTML5 as consistently as we now output conforming XHTML 1.0 Transitional as long as all these presentational attributes are invalid. We have a large body of content using these attributes that must be supported -- e.g., most infoboxes on Wikipedia, which means most articles. We could convert <font face> and such automatically, but not <table border> or such. Therefore, if the spec aims to only impose author conformance requirements that are practically implementable for sites with large bodies of legacy content -- I doubt MediaWiki is the only app in this position, although it might be -- then these restrictions need to be relaxed. I believe that to do otherwise would violate the principle that the spec should conform to reality. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 28 March 2010 01:45:40 UTC