- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Apr 2010 11:29:37 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTML WG <public-html@w3.org>, Technical Architecture Group <tag@w3.org>
On Thu, Apr 1, 2010 at 11:17 AM, Sam Ruby <rubys@intertwingly.net> wrote: > On 04/01/2010 01:44 PM, Jonas Sicking wrote: >> >> On Fri, Mar 26, 2010 at 1:52 PM, Sam Ruby<rubys@intertwingly.net> wrote: >>> >>> I took an action item from the TAG yesterday to convey the following >>> request: >>> >>> The W3C TAG requests there should be in TR space a document >>> which specifies how one can create a set of bits which can >>> be served EITHER as text/html OR as application/xhtml+xml, >>> which will work identically in a browser in both bases. >>> (As Sam does on his web site.) >>> >>> This request requires a lot of explanation. To start, it is recognized >>> up >>> front that this will be a subset of the set of possible documents that >>> can >>> be expressed as HTML5. This is entirely OK. For example, if it were to >>> be >>> the case that such a subset were to entirely disallow scripts of any >>> kind, >>> that would be acceptable as there exists a substantial class of documents >>> which do not require scripting of any kind. >> >> Out of curiosity, what does "work identically" encompass? Do they have >> to have the same DOM? Or just render the same when the default UA >> stylesheet is applied? Or just be semantically equivalent? >> >> Even if the page itself doesn't contain any scripts, if the page is >> contained in an iframe then scripts in another page might trip over >> differences if the two pages produce different DOMs. >> >> I believe a document served as text/html and one served as >> application/xhtml+xml will always have different DOMs since the former >> will have nodes with upper case nodeNames, whereas the latter will >> have nodes with a lower case nodeName. >> >> If DOMs aren't important, only rendering is, I assume that this >> document won't qualify: >> >> <html xmlns="http://www.w3.org/1999/xhtml"> >> <head> >> <style> tbody { background: green }</style> >> <title>example document</title> >> </head> >> <body> >> Integer values for true/false. >> <table> >> <tr><td>true</td><td>1</td></tr> >> <tr><td>false</td><td>0</td></tr> >> </table> >> </body> >> </html> >> >> Since if this document is served as text/html the table will have a >> green background, but if served as application/xhtml+xml it will not. > > I'll answer this in reverse order. > > I agree that the document you cited won't qualify. There are two ways to > address this: treat tables without explicit tbody's as non-conforming, or > treat style rules that produce different results based on the existence of > tbody elements to be non-conforming. As luck would have it, I had an > opportunity to observe this exact discussion. DanC and PLH preferred it when > tbody elements were included, TimBL preferred to not include tbody elements > when they were not necessary. I didn't express an opinion in that venue, > but I will say that while I don't currently routinely use tbody elements, I > do think it would be better approach if this document were to suggest that > they were required. > > I don't believe the correct question is a binary "are DOM's important: yes > or no". In general DOMs are important, but there may be specific cases > where the differences are containable. > > Overall I do believe that rendering (including the ability to be styled with > stylesheets) is a primary consideration. My biggest problem with Appendix C > is that is makes it sound easy. My biggest problem with the WHATWG wiki > page on this topic is that it makes it sound darn near impossible. > > A document that states indicates that while it is possible it is more > difficult than it would appear to be would be worthwhile. Thanks, that explains it well. I don't really see the usefullness of such a draft (but then, I'm less of an XML fan than the target audience I suspect, which is funny given how much effort I've spent making firefox support it), but at least I understand its requirements. / Jonas
Received on Thursday, 1 April 2010 18:30:30 UTC