-
Notifications
You must be signed in to change notification settings - Fork 125
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
Create documentation/aria-idl.md #2340
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM overall. Some minor nits;
- ***Standardization***: Web APIs (e.g., `getAttribute()`) are implemented the same which ensures consistent behavior and usage across browsers | ||
- ***Language-independent***: | ||
- Define interfaces in a way that isn’t tied to a programming language, e.g., could have JavaScript/C++/Python or any other language implementation | ||
- Easier to generate bindings (single web IDL spec can be used to generate bindings for multiple languages) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this sentence could read a little easier? Maybe this is an improvement:
- Easier to generate bindings (single web IDL spec can be used to generate bindings for multiple languages) | |
- Can be used to generate code (IDL files can be used to generate code across multiple languages) |
- Define interfaces in a way that isn’t tied to a programming language, e.g., could have JavaScript/C++/Python or any other language implementation | ||
- Easier to generate bindings (single web IDL spec can be used to generate bindings for multiple languages) | ||
- Facilitates cross-language integration (e.g., Python backend can communicate with JavaScript frontend) | ||
- ***Feature detection***: If (el.someIDLAttribute) is true, then the feature is supported which facilitates user agent detection for that particular attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- ***Feature detection***: If (el.someIDLAttribute) is true, then the feature is supported which facilitates user agent detection for that particular attribute | |
- ***Feature detection***: If (`'someIDLAttribute' in el`) is `true`, then the feature is supported; facilitating user agent detection for that particular attributes |
- ***Documentation***: | ||
- Specifies how web APIs should behave for both browser implementers and developers | ||
- Interfaces are largely self documenting | ||
- ***Backwards compatibility***: Can add new properties/methods without breaking backwards-compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps worth capturing the consistency between APIs as a feature of IDL:
- ***Backwards compatibility***: Can add new properties/methods without breaking backwards-compatibility | |
- ***Backwards compatibility***: Can add new properties/methods without breaking backwards-compatibility | |
- ***Consistency***: New APIs, such as methods and properties, follow similar forms to existing APIs - conventions and types are heavily reused, creating familiarity interface between APIs. |
Closes #2310
This PR adds a new
aria-idl.md
documentation file that provides general explanation about IDL, how ARIA IDL works and chronology/history of key ARIA IDL decisions.