<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Oct 15, 2008 at 12:20 PM, Ralph Giles <span dir="ltr"><<a href="mailto:giles@xiph.org">giles@xiph.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Oct 15, 2008 at 12:04 PM, Sander van Zoest <<a href="mailto:sander@vanzoest.com">sander@vanzoest.com</a>> wrote:<br>
<br>
> integer another data type? Also, having non-square pixels is not<br>
> broken. If we go this route, we might as well get rid of the distinction all<br>
> together.<br>
<br>
</div>I was responding to Ian's question against your original<br>
pixelratio='59:54' proposal.<br>
</blockquote><div><br>Do note, I also mentioned two attributes. I am just trying to say we need two 32-bit integers<br>to express PAR, so we can do that however is appropriate. The only reason I liked the above<br>is that it was keeping h &v together. I didn't realize that this was going to cause such a stir.<br>
I am willing to put forth the effort if it would help.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Shall I instead say, conforming to best practices doesn't justify two<br>
interactive attributes here? :)</blockquote><div><br>Following that logic, why add the attribute at all? If it is going to be wrong, and require guessing to the<br>nearest fraction by the user agent. It is rarely going to be used. Why not just force people to transcode<br>
the content to make it work correctly? Have them put it in a Ogg container while they are at it?<br><br>-- Sander<br><br></div></div><br>
</div>