*** Bug 21991 has been marked as a duplicate of this bug. ***

Presentational attributes for elements whose layout transforms between horizontal and vertical writing modes should also transform. E.g. 'width' on a table should always refer to the logical width. (However, 'width' on an image should always refer to its physical width, since images stay upright.)

Here's some text that was commented out of an earlier Writing Modes editor's draft for reference:

<h3 id="html-attributes">HTML Attributes</h3>

  <p>This section defines the mapping of HTML presentational attributes
    in CSS. This section is normative for user agents supporting HTML
    in addition to the 'writing-mode' property. [[!HTML40]] [[!HTML5]]

  <h4 id="width-height-attributes">The <code>width</code> and <code>height</code> attributes</h4>

  <p>The HTML <code>width</code> and <code>height</code> attributes refer
    to the physical width and height for elements that that are replaced,
    i.e.
    <code>&lt;applet&gt;</code>,
    <code>&lt;embed&gt;</code>,
    <code>&lt;iframe&gt;</code>,
    <code>&lt;img&gt;</code>,
    <code>&lt;object&gt;</code>,
    <code>&lt;canvas&gt;</code>,
    and
    <code>&lt;video&gt;</code>

  <p>Form elements elements contain text, therefore their contents should be
    affected by writing mode, in which case these attributes refer to the
    <em>logical</em> width and height. The UA may, however, choose not
    to rotate nor flip these elements in vertical writing modes if it is not
    capable, and in that case, these attributes remain physical.</p>
    <p class="issue">When not rotating form elements/MathML,
      should we treat them as images (always upright)
      or force writing-mode to always calculate to horizontal-tb?</p>

  <p>On table-related elements (<code>&lt;table&gt;</code>, <code>&lt;colgroup&gt;</code>,
    <code>&lt;col&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;th&gt;</code>,
    <code>&lt;td&gt;</code>) the <code>width</code> and <code>height</code>
    attributes are always logical.

  <p>The <code>size</code> attribute of the <code>&lt;hr&gt;</code> element
    is also logical (refers to the logical height).

  <h4 id="alignment-attributes">Alignment, Float and Clear Attributes</h4>

  <p>The following attributes behave the same way as their corresponding
    CSS properties:</p>

  <ul>
    <li><code>align</code> as 'float' or 'text-align'</li>
    <li><code>clear</code> as 'clear'</li>
    <li><code>valign</code> as 'vertical-align'</li>
  </ul>

  <h4 id="spacing-attributes">Spacing Attributes</h4>

  <p>The following attributes are logical and, as margins, are logical
    with respect to the writing mode of the <em>parent</em> element.</p>

  <ul>
    <li><code>hspace</code> as inline-start and inline-end margins</li>
    <li><code>vspace</code> as block-start and block-end margins</li>
    <li>marginwidth</li>
    <li>marginheight</li>
  </ul>

If the CSSWG ever agrees to write a spec for logical properties,
  http://lists.w3.org/Archives/Public/www-style/2013May/0224.html
this will be much simpler to explain. Figured I'd at least file the issue against HTML for now, though.

Do any browsers actually treat them logically? Most if not all of these are obsolete in HTML now, so if browsers don't already do it, I don't see much point in adding complexity to their legacy document handling.

Since these are all obsolete anyway, I'm punting on this. If there's a compat need to do this, please let me know. Thanks.