-
-
Notifications
You must be signed in to change notification settings - Fork 174
docs(BImg): Parity pass #2177
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
docs(BImg): Parity pass #2177
Conversation
|
|
commit: |
| }, | ||
| emits: [ | ||
| { | ||
| event: 'load', |
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 initially pulled this out based on my reading of https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/loading - there is no mention of a load event other than Window.load. But testing the code, we do get a load event fired for every image. Based on testing though, we do get a load event fired for every image load (both proactive and lazy). It looks like there is a native onLoad event on img tags, which I presume vue.js it using to fire a load event, but I'm not seeing that documented anywhere - this may just be a hole in my knowledge and I'm looking in the wrong places. In any case, I'm putting this back in, let me know if there are details that I'm missing...
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.
There's a section detailing the load event on the page you posted.
Although practically the event doesn't need to be declared as it should bubble up naturally
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 must be missing something. The place I found on that page is in the Timing of the load event section. I read that as describing the behavior of the Window.load event, which is not what I'm interested in here. The bubble-up event is a load event on the <img> element. Doesn't really matter though - the point is that the event is there and it's bubbling up.
That does bring up the question of if/when we document bubble-up events. I've been doing that when it's consistent (e.g. it doesn't depend on a wrapper component being in the middle or not) and core to the functionality of the component I'm documenting. The load event here meets my criteria for documenting even though we're not explicitly declaring it, but let me know if you have a different preference. Or, if we should flag bubble-up events as such in the documentation...
* upstream/main: (179 commits) chore: release main (bootstrap-vue-next#2175) docs(BImg): Parity pass (bootstrap-vue-next#2177) docs: Use Not Yet Implemented Component consistently (bootstrap-vue-next#2183) docs(BCarousel): Parity pass (bootstrap-vue-next#2179) feat(BCarousel): add click:prev and click:next events refactor: reduce module packages complexity refactor: make define models use component imported prop type fix directives on element update during interaction (bootstrap-vue-next#2170) fix(BTabs): fix recursion on titleLinkAttrs (bootstrap-vue-next#2169) chore: release main (bootstrap-vue-next#2172) fix(BPagination): hide-goto-end doesn't hide firstPage or lastPage (bootstrap-vue-next#2171) Update vite template for bugs to work now that it seems we don't import components docs(BCard): Parity pass (bootstrap-vue-next#2168) docs(BPagination): Update Component refs & clean up documentation (bootstrap-vue-next#2152) Delete .github/workflows/pkg-pr-new.yaml Update ci.yaml with pkg.pr.new add pkg.pr.new to publish a package for each commit and pull request chore: release main (bootstrap-vue-next#2149) fix(BPagination): Get rid of bad binding on li (bootstrap-vue-next#2150) fix: pass attributes through in BDropdownItemButton (bootstrap-vue-next#2143) ...
* upstream/main: chore: release main (bootstrap-vue-next#2175) docs(BImg): Parity pass (bootstrap-vue-next#2177) docs: Use Not Yet Implemented Component consistently (bootstrap-vue-next#2183) docs(BCarousel): Parity pass (bootstrap-vue-next#2179) feat(BCarousel): add click:prev and click:next events refactor: reduce module packages complexity refactor: make define models use component imported prop type fix directives on element update during interaction (bootstrap-vue-next#2170) fix(BTabs): fix recursion on titleLinkAttrs (bootstrap-vue-next#2169) chore: release main (bootstrap-vue-next#2172) fix(BPagination): hide-goto-end doesn't hide firstPage or lastPage (bootstrap-vue-next#2171) Update vite template for bugs to work now that it seems we don't import components docs(BCard): Parity pass (bootstrap-vue-next#2168) docs(BPagination): Update Component refs & clean up documentation (bootstrap-vue-next#2152) Delete .github/workflows/pkg-pr-new.yaml Update ci.yaml with pkg.pr.new
Describe the PR
This is the parity pass for
BImgand BImgCardbuildCommonPropswhen definingimagePropsI also marked
BImgLazyandBImgCardLazyas deprecated - I believe they aren't needed in modern browsers where theloadingattribute is implemented. There is a note in the docs that we intend to implement placeholder slots, but from my reading of BSV, they weren't implemented in the*Lazyvariations, so this would be an enhancement not a parity issue.Small replication
N/A
PR checklist
What kind of change does this PR introduce? (check at least one)
fix(...)feat(...)fix(...)docs(...)The PR fulfills these requirements:
CHANGELOGis generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied