-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
getBounds(true) and async content #1588
Comments
If I understand correctly the issue is:
Is this correct? |
Well, sort of.
I'm thinking that this may be intended behavior, since - at the explicit point in time getBounds() is called - the embed may be a single, empty block-element high. If this is the case, I'm guessing the Blot-implementation should take care to alert quill that the dimensions have changed or something similar? |
I'm not clear on how this list is different from except your steps 1-3 sets up for 4 which is where my list's 1 starts. The point is though at the moment the application calls quill.getBounds() the dimensions are correct. Quill cannot "know" this value will change and even if it could there is no way to inform the application. Without this latter part what you are suggesting with the Blot-implementation is not enough because it will never get to your application which would need to reposition the sidebar. The suggestion I would make is for your application to listen on when the image is loaded and call |
Hmm, thanks for the clarification! So, in essence - let the application fetch the domNode created by the blot in question using regular means, observe any changes directly on that and don't involve quill at all regarding notifications on changed dimensions? |
No I would let the image be added normally but just add a DOM onload handler to it. It could get complex finding the Blot then image domNode so you could use event delegation like so:
If it were my application I would probably just add a 1 second timeout before calling getBounds since the ratio of effectiveness to effort is very high. |
Thanks for the suggestion, I'll kick it around! Also- thanks for an awesome editor! |
@buffpojken Would it be possible for you to share some code on your implementation for oembed support? I'm evaluating Quill currently and oembed support is the main thing holding me back. |
Sure thing, it was quite trivial to implement a very solid support for oembed, including the fix discussed above. We're using a matcher to capture any probable embeds, and using a little proxy checks for tags. If any are found, pass the data long. The renderer defines a custom Blot for embeds, as follows. Works extremely well.
This implementation assumes a lot based on the proxy, but that should be workable anyway. |
Whether the implementation of 2x images should also use this method? like this: class ImageBlot extends BlockEmbed {
static create(src) {
const node = super.create()
node.setAttribute('src', src)
//node.setAttribute('onload', () => invokeformat(node))
return node
}
static value(node) {
return node.getAttribute('src')
}
static formats(node) {
// We still need to report unregistered embed formats
let format = {}
if (node.naturalWidth || node.width) {
format.width = (node.naturalWidth || node.width ) / 2
}
if (node.naturalHeight || node.height ) {
format.height = (node.naturalHeight || node.height) / 2
}
return format
}
format(name, value) {
// Handle unregistered embed formats
if (name === 'height' || name === 'width') {
if (value) {
this.domNode.setAttribute(name, value)
} else {
this.domNode.removeAttribute(name, value)
}
} else {
super.format(name, value)
}
}
}
ImageBlot.blotName = 'imageBlot'
ImageBlot.tagName = 'img'
Quill.register('blots/imageBlot', ImageBlot) |
I'm having some trouble asynchronous content (oembeds, larger images - anything where the true size of the content is not known when adding the element, but rather once data has been loaded) versus the sizes reported by getBounds()
I've implemented an oembed-blot, basically using the architecture of the TweetBlot in the "Cloning Medium..."-example with some additional window dressing - and also the side-menu. However, content that has an unknown height results in the side-menu being placed "one linebreaks height" from the insertion point, rather than the true content height, and some further investigation has proven that (of course), this is due to the BlockEmbed being one linebreak high when the "editor-change" event is posted, and then expanding once the content loads.
What's the best approach for fixing this? Is there some proper way of notifying Quill about the updates in size? Another thought is whether or not it should reside within the Blot-definition, and explicitly setting the height once it's known, though that would still not AFAIU let the Quill-instance know anything about the change?
The text was updated successfully, but these errors were encountered: