-
Notifications
You must be signed in to change notification settings - Fork 72
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
Add document, document fragment, document type #1983
Conversation
Ready for a first pass. There's not any real standalone feature candidates in the key list for Document. There's a couple notes on Caniuse keys that are related. Open question is what approach for keys like Aside from one-off keys that'll get poached into future features, some things that might make standalone features:
Aha, so there's this: https://caniuse.com/dom-manip-convenience The description shows its age enough that I'm skeptical we want to align around that bag of APIs specifically. However, there may be something to a "working w/ the DOM and nodes" collection of features, looking through developer lens. |
I think a lot of this stuff is going to get swept into a monolithic DOM feature. I'd appreciate if other reviewers also had a look through https://github.com/web-platform-dx/web-features/pull/2007/files#r1813040012. |
Closing to fold into #2007 |
kitchen sink at this point, pulled from various drafts.
Ok, whittling down to keys which match the following criteria:
api.Document
document.lastModified
and `document.document.images
anddocument.forms
(yes, there may be "primary" features for the thing being collected but thedocument
shortcut is document-level)Need to determine whether to put other interface impls in the feature or in the interface - eg,
document.append
is impl ofElement
... so do we add all theappend
keys to their feature or add them all to anElement
feature? TBD will ask in chat/meeting.Will see what's left after that culling and classify the remainders.