-
Notifications
You must be signed in to change notification settings - Fork 201
Add document, document fragment, document type #1983
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
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.Documentdocument.lastModifiedand `document.document.imagesanddocument.forms(yes, there may be "primary" features for the thing being collected but thedocumentshortcut is document-level)Need to determine whether to put other interface impls in the feature or in the interface - eg,
document.appendis impl ofElement... so do we add all theappendkeys to their feature or add them all to anElementfeature? TBD will ask in chat/meeting.Will see what's left after that culling and classify the remainders.