23810 2009-02-06 17:23:46 -0800 Multiple inheritance costs too much for HTMLInput/Option/.../SelectElement 2019-02-06 09:03:02 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Mac OS X 10.5 RESOLVED DUPLICATE 25617 P2 Normal --- 1 zimmermann zimmermann cdumez darin eric hyatt mjs sam staikos oldest_to_newest 108784 0 zimmermann 2009-02-06 17:23:46 -0800 Recently some ABCs have been introduced to give the render tree an abstract access to form control elements, so RenderTextControl/RenderListBox/etc. can be used from outside HTML (before those classes depended on HTMLSelectElement/HTMLInputElement directly). The simple & dirty approach I've chosen, costs too much memory, as Dave & Sam pointed out in private talks, while I argued the waste is low (real-life pages don't use thousands of input/select elements), but still it hurts HTML, and is only of benefit for WML (at least at the moment, and it's even turned off by default). So it only hurts HTML without giving it any benefit, besides a cleaner interface to the render tree. One approach, floating in my mind is just to have _one_ FormControlElement class, replacing InputElement/OptionElement/OptionGroupElement/FormControlWithStateElement/SelectElement. All methods could be moved in this central class for form control elements, not as pure-virtual methods, but as virtual-methods defaulting to 'ASSERT_NOT_REACHED'. We could add some boolean methods isInputElement/isOptionElement to differentiate between the types of form control elements. This would only add 4-bytes to HTMLInputElement, etc, which is really low, and it gives huge benefits for WML (able to reuse the Render* classes for form control elements). Currently ie. HTMLInputElement derives from HTMLFormControlElementWithState (deriving from HTMLElement, FormControlElementWithState, FormControlElement) and InputElement, which is 12-bytes. That's just _one_ idea, this bug is meant as a container to discuss the future of this code. I'm filing this bug, to adress I'm aware of the current limitations of the design, and I'm willing to improve it, after I get some input, where the journey should end. 108787 1 darin 2009-02-06 17:45:37 -0800 Another idea is to find a way to make the functions non-virtual in builds without HTML. InputElement would become a typedef for HTMLInputElement and we'd include all the appropriate functions, perhaps by inheriting from a base class, but they would not be virtual functions. 120449 2 zimmermann 2009-05-08 12:13:47 -0700 This bug has been fixed yesterday. *** This bug has been marked as a duplicate of 25617 *** 1502892 3 lforschler 2019-02-06 09:03:02 -0800 Mass moving XML DOM bugs to the "DOM" Component.