21990 2013-05-09 22:37:07 +0000 Certain HTML attributes should use flow-relative directional mappings to CSS 2014-09-26 21:14:27 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#maps-to-the-dimension-property P3 normal Needs Impl Interest 1 contributor ian fantasai.bugs ian mike contributor oldest_to_newest 87519 0 contributor 2013-05-09 22:37:07 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html Multipage: http://www.whatwg.org/C#maps-to-the-dimension-property Complete: http://www.whatwg.org/c#maps-to-the-dimension-property Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Certain HTML attributes should use flow-relative directional mappings to CSS Posted from: 76.14.87.229 User agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 87522 1 fantasai.bugs 2013-05-09 22:38:01 +0000 *** Bug 21991 has been marked as a duplicate of this bug. *** 87523 2 fantasai.bugs 2013-05-09 22:44:24 +0000 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. 89322 3 ian 2013-06-14 18:18:20 +0000 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. 112311 4 ian 2014-09-26 21:14:27 +0000 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.