Re: Shorten <object> in XHTML 2.0?

> I agree consistancy is good, and don't see a problem with adding <obj />
> as an alias for <object /> as long as the original method remains.

I didn't want the opportunity (?) to have 1+ aliases for an element, but a
consequent naming of elements (and getting rid of endless naming discussions
by e.g. a guideline). And if you refer to parsing speed, you are right
worrying about performance losings having several names for one element -- but if
you use full element names, you lose transfer speed.


 Jens.



> 
> --- Jens Meiert <jens.meiert@erde3.com> wrote:
> > 
> > <irony>Sorry, but there are so many Harvard, Yale, Stanford etc.
> students
> > involved in this discussion, is nobody here who can propose a real
> generic
> > and
> > consequent solution for it right now?</irony>
> 
> Well, here is an opinion from a Rensselaer Polytechnic Institute student
> ;-)
> 
> First off, let me say that I am not well versed in XML, but I thought XML
> was
> extensible. Can't people create their own <obj /> element in their page
> that
> would be an <object /> element? If so, then they can rename it at their
> own
> descretion.
> 
> > 
> > In practice it's totally irrelevant if you use <object /> or <obj />,
> <image
> > /> or <img />, <paragraph /> or <p /> (as long as it works), but one
> (and
> > maybe the most important) thing is missing: a consequent naming. Why is
> there
> > <td />, but <object />, why is there <p />, but <title /> (please, don't
> tell
> > me any history or background...)? So I -- and I guess there are some
> other
> > people, too -- prefer one single way to name elements, and then all
> > discussion
> > is over.
> 
> With respect to what browsers would do, if obj were now available as obj
> or
> object, they would simply handle both the same way and it would probably
> be
> something like a 4 line fix (assuming based on Mozilla's code), so it
> wouldn't
> change anything except to be more convenient to the user.
> 
> <title> is not an oft-used element (it only appears once in the head) so
> doing
> it as <t> or something wouldn't have much point, especially since the
> shorter
> tags <tt>, <p>, etc back in the days of HTML 3.2, etc were generally
> reserved
> for things you would use multiple times in most pages. Will people really
> load
> their pages up with fiftenn <object /> elements? Possibly, if it becomes
> more
> accepted by user agents.
> 
> I agree consistancy is good, and don't see a problem with adding <obj />
> as an
> alias for <object /> as long as the original method remains. The only
> issue is
> you are creating more work for the UA developers, and possibly slowing
> down
> parsing by a few hundred microseconds having to check for two versions of
> the
> same element.
> 
> > 
> > 
> >  Jens Meiert.
> > 
> > 
> > 
> > > 
> > > Masayasu Ishikawa <mimasa@w3.org> writes:
> > > 
> > > > Draft, but since the second Working Draft the spec introduced
> > > > the Embedding Attribute Collection [1], which means any element can
> > > > embed an external resource (such as image), not just 'object'.  Most
> > > > simple image inclusions will be done through the 'src' and 'type'
> > > > attributes, and only complex cases will be dealt by the 'object'
> > > > element.
> > > > 
> > > > [1]
> > >
> >
>
http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-attribute-collections.html#col_Embedding
> > > 
> > > Cute, but unwise.
> > > 
> > > I quote from the cited section 6.6:
> > > 
> > > : Examples:
> > > : 
> > > : <p src="holiday.png" type="image/png">
> > > :     <span src="holiday.gif" type="image/gif">
> > > :         An image of us on holiday.
> > > :     </span>
> > > : </p>
> > > : 
> > > : <table src="temperature-graph.png" type="image/png">
> > > : <caption>Average monthly temperature over the last 20
> years</caption>
> > > :
> > >
> >
>
<tr><th>Jan</th><th>Feb</th><th>Mar</th><th>Apr</th><th>May</th><th>Jun</th>
> > > :    
> > >
> <th>Jul</th><th>Aug</th><th>Sep</th><th>Oct</th><th>Nov</th><th>Dec</th>
> > > : </tr>
> > > : <tr><td> 4</td><td> 2</td><td> 7</td><td>
> 9</td><td>13</td><td>16</td>
> > > :     <td>17</td><td>17</td><td>14</td><td>11</td><td> 7</td><td>
> 4</td>
> > > : </tr>
> > > : </table>
> > > 
> > > With this design a user agent will waste time checking for non-empty
> > > values of the src attribute for *every* inline and *every* block level
> > > element.
> > > 
> > > Doesn't processing strategy usually involve looking only at particular
> > > attributes of interest based on the name of the element?
> > > 
> > >                                     -- Bill
> > > 
> > 
> > 
> > -- 
> > Jens Meiert
> > 
> > Steubenstr. 28
> > D-26123 Oldenburg
> > 
> > Mobil +49 (0)175 78 4146 5
> > Telefon +49 (0)441 99 86 147
> > Telefax +49 (0)89 1488 2325 91
> > 
> > Mail <jens@meiert.com>
> > Internet <http://meiert.com>
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 


-- 
Jens Meiert

Steubenstr. 28
D-26123 Oldenburg

Mobil +49 (0)175 78 4146 5
Telefon +49 (0)441 99 86 147
Telefax +49 (0)89 1488 2325 91

Mail <jens@meiert.com>
Internet <http://meiert.com>

Received on Monday, 30 June 2003 18:08:16 UTC