-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTMLElement and other extensions. #56
Comments
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. |
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 Feedback would be appreciated. |
List of all classes, taken from https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement
Noticably, not all class names correlate directly to the tagname. |
It turns out, it isn't possible to have a class for each type of HTMLElement. This is because of the native Instead, because there can't be a subset of There certainly needs to be a class-like construct that can be used to provide the logic for each individual HTMLElement. |
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 |
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 |
The
HTMLElement
interface has some server-side capabilities that a normalElement
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 andselect
elements have certain capabilities according to their state. Rather than adding conditional logic into the mainElement
class for each type of sub-element, the logic should exist in its own Element-derived class.The text was updated successfully, but these errors were encountered: