HTMLElement and other extensions.

[phpgt]

HTMLElement and other extensions.

[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).