W3C home > Mailing lists > Public > www-html@w3.org > May 2005

Re: Formal Response to My issue on styling embedding attributes. (PR#7655)

From: Shane McCarron <shane@aptest.com>
Date: Fri, 27 May 2005 20:32:48 -0500
Message-ID: <4297CA40.6050203@aptest.com>
To: Jim Ley <jim.ley@gmail.com>
CC: www-html-editor@w3.org, www-html@w3.org, xhtml2-issues@hades.mn.aptest.com

Jim Ley wrote:

>On 5/27/05, Shane McCarron <shane@aptest.com> wrote:
>It is disappointing that just a few days after being last reminded of
>your obligations under the W3 Process document, you again fail to
>adhere to those obligations.
Thanks again for reminding me.

>I do not regard this as an appropriate attempt to respond to or
>satisfy my issue, there is no techincal content in why the issue was
>rejected, and at no time have you attempted to explain either the
>decision or attempted to satisfy me.  Please formally address the
>issue in accordance with the process document.
Our primary obligation is to produce a document that achieves 
consensus.  This particular feature has achieved a sufficient level of 
consensus in the working group.  That's why it is in the draft.  I have 
not had an opportunity to discuss this issue further with the working 
group, or to ask the group to consider revising its response.  However, 
here are some PERSONAL THOUGHTS on this feature of XHTML 2:

The working group has chosen to extend the fallback model that was 
present in HTML 4 with the object element.  There is no requirement that 
document authors use this mechanism, just as there was no requirement 
anyone use the mechanism that was available with the object element.  
There are a myriad of pathological cases where this mechanism, while 
technically sound, would be aesthetically disappointing.  This is true 
of lots of features in HTML, XHTML and indeed in other markup languages 
and technologies.  Tables, for example, are used in inappropriate ways 
all over the place.  However, we would never consider getting rid of 
tables, because there are situations where tables are the perfect tool 
for the job.

Your original request, b.t.w., asked a question.  It did not request a 
change or propose a solution, even a vague one.  Regardless, the working 
group took the request as a serious submission and reviewed it.    We 
interpreted your comment as having two related components - 1) that 
fallback items might be different sizes, and 2) that the fallback 
content might need to be styled differently.

We responded to 1) with "We understand that fallbacks might have 
different sizes.  This is really an issue for the author.  The 
flexibility far outweighs the risk that things will render in 
unpredictable ways."  You have indicated that this is an unacceptable 
response, and we have recorded your objection.

We did not respond to the second component explicitly.  I can 
extrapolate from my notes that the group felt the issue with different 
styles could be addressed by, for example, assigning different @id 
values to each level, or using different @style attributes at each 
level, or using different @class values at each level that you wanted to 
style differently.  This permits very finely grained control of the 
formatting of fallback blocks.  You could also, of course, choose to NOT 
style the different levels explicitly too.  This provides for maximum 

You are correct that using the fallback in the example you cite would be 
challenging to style using the mechanisms above. However, it could be 
written as:

<div src="temperature-graph.png" srctype="image/png" id="weatherimg">
<table id="weathertable">
<caption>Average monthly temperature over the last 20
<tr><td> 4</td><td> 2</td><td>
7</td><td> 4</td>
<!-- 19 more rows for the other 19 years>

And then styled appropriately.

If you have a proposal that would address your concern in some other 
way, please let us know.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Saturday, 28 May 2005 01:33:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:10 UTC