HTMLElement and other extensions.

[g105b]

The HTMLElement interface has some server-side capabilities that a normal Element doesn't, but the main point in introducing this class is to allow other classes to extend the functionality of a normal Element.

For example, input elements and select elements have certain capabilities according to their state. Rather than adding conditional logic into the main Element class for each type of sub-element, the logic should exist in its own Element-derived class.

[g105b]

This issue was raised due to the introduction of the value getter/setter to the select element. This is fine while there is only the one getter/setter for the one type of element, but there will be many more elements that need their own functionality. See https://github.com/phpgt/dom/pull/55/files#diff-cf04cad35ad97bb3de2901c4ce89acf6R100 for code in question.

[g105b]

The implementation needs some thought...

@ognjen-petrovic has asked, "Do you intend to override all element getters, like getElementById, getElementsByTagName etc, so those return proper HTMLELement?" (#55 (comment))

This could become quite difficult to maintain. My initial plan is to create the sub-classes when needed, then use something like class_exists("HTML" . $this->tagName . "Element") to check for the correct class to return.

Feedback would be appreciated.

[g105b]

List of all classes, taken from https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement

• HTMLAnchorElement
• HTMLAreaElement
• HTMLAudioElement
• HTMLBRElement
• HTMLBaseElement
• HTMLBaseFontElement
• HTMLBodyElement
• HTMLButtonElement
• HTMLCanvasElement
• HTMLContentElement
• HTMLDListElement
• HTMLDataElement
• HTMLDataListElement
• HTMLDialogElement
• HTMLDivElement
• HTMLDocument
• HTMLEmbedElement
• HTMLFieldSetElement
• HTMLFormControlsCollection
• HTMLFormElement
• HTMLFrameSetElement
• HTMLHRElement
• HTMLHeadElement
• HTMLHeadingElement
• HTMLHtmlElement
• HTMLIFrameElement
• HTMLImageElement
• HTMLInputElement
• HTMLIsIndexElement
• HTMLKeygenElement
• HTMLLIElement
• HTMLLabelElement
• HTMLLegendElement
• HTMLLinkElement
• HTMLMapElement
• HTMLMediaElement
• HTMLMetaElement
• HTMLMeterElement
• HTMLModElement
• HTMLOListElement
• HTMLObjectElement
• HTMLOptGroupElement
• HTMLOptionElement
• HTMLOptionsCollection
• HTMLOutputElement
• HTMLParagraphElement
• HTMLParamElement
• HTMLPictureElement
• HTMLPreElement
• HTMLProgressElement
• HTMLQuoteElement
• HTMLScriptElement
• HTMLSelectElement
• HTMLShadowElement
• HTMLSourceElement
• HTMLSpanElement
• HTMLStyleElement
• HTMLTableCaptionElement
• HTMLTableCellElement
• HTMLTableColElement
• HTMLTableDataCellElement
• HTMLTableElement
• HTMLTableHeaderCellElement
• HTMLTableRowElement
• HTMLTableSectionElement
• HTMLTemplateElement
• HTMLTextAreaElement
• HTMLTimeElement
• HTMLTitleElement
• HTMLTrackElement
• HTMLUListElement
• HTMLUnknownElement
• HTMLVideoElement

Noticably, not all class names correlate directly to the tagname.

[g105b]

It turns out, it isn't possible to have a class for each type of HTMLElement. This is because of the native registerNodeClass functionality - only one class can be used to construct.

Instead, because there can't be a subset of Element as HTMLElement, could we look at something like an HTMLElement trait?

There certainly needs to be a class-like construct that can be used to provide the logic for each individual HTMLElement.

[ognjen-petrovic]

Yes, subclassing is not possible with native PHP implementation. Few days ago, just for fun, I have started with custom PHP extension that exploits pugixml. https://github.com/ognjen-petrovic/php-dom-ext

[g105b]

That looks an interesting project! As far as this issue is concerned, I think it will be OK to patch these subclasses in with traits. As long as the external-facing API is consistent with the W3C spec, it doesn't matter if there are some hacks behind the scenes (take LiveProperty for example).