This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23966 - Move "attribute DOMString abbr" to HTMLTableCellElement?
Summary: Move "attribute DOMString abbr" to HTMLTableCellElement?
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-03 09:39 UTC by contributor
Modified: 2013-12-06 11:58 UTC (History)
3 users (show)

See Also:


Attachments

Description contributor 2013-12-03 09:39:34 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html
Multipage: http://www.whatwg.org/C#attributes-common-to-td-and-th-elements
Complete: http://www.whatwg.org/c#attributes-common-to-td-and-th-elements
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html

Comment:
Move "attribute DOMString abbr" to HTMLTableCellElement?

Posted from: 83.218.67.123 by philipj@opera.com
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/30.0.1599.114 Chrome/30.0.1599.114 Safari/537.36
Comment 1 Philip Jägenstedt 2013-12-03 09:41:30 UTC
Both HTMLTableDataCellElement and HTMLTableHeaderCellElement has the abbr attribute, so why not move it up to HTMLTableCellElement?

Perhaps the fact that it's obsolete on HTMLTableDataCellElement is the reason?
Comment 2 Ian 'Hixie' Hickson 2013-12-05 18:37:09 UTC
Yeah, that's the reason. Avoiding that confusion seems to outweigh the slight performance benefit from combining them (which I presume is the desire for combining them); am I wrong on this?
Comment 3 Philip Jägenstedt 2013-12-06 11:58:24 UTC
(In reply to Ian 'Hixie' Hickson from comment #2)
> Yeah, that's the reason. Avoiding that confusion seems to outweigh the
> slight performance benefit from combining them (which I presume is the
> desire for combining them); am I wrong on this?

Well, I was looking at implementing HTMLTableDataCellElement and HTMLTableHeaderCellElement in Blink and realized I would have to explain what the point of moving an attribute from a base interface to *both* subinterfaces would be, since in Blink obsolete stuff isn't in a separate partial interface.

That it is intentionally this way in the spec should be justification enough, just wanted to make sure.