Caret iframe support / refactor default document occurrences #1152
Conversation
|
Can one of the admins verify this patch? |
|
Development cycle wise when would I see a fix like this rolled down to .25? I am trying to implement Aloha in this same fashion and I would love to see this working in the stable release. Upon looking further, I'm seeing aloha.js is radically different from .25? I'm guessing this is just going to be part of a 1.0 release then? And in that case, any time frame for the 1.0 release? |
|
@evindor Yes, we should replace all references to the global |
|
@MKuenzi Yes, Aloha Editor in the "howling-mad" branch is a very different beast. We've revolutionised our approach to editing. We will be announcing soon the launch date for this new API. |
|
@petrosalema Thanks for the response. Is there anywhere I can check out a build of this? Otherwise I can build this but I'm running into issues. I have started a thread if you have time to help me https://getsatisfaction.com/aloha_editor/topics/building_howling_mad |
|
@MKuenzi, to build:
|
petrosalema
force-pushed
the
howling-mad
branch
from
5cdf99d to
5f76871
Compare
petrosalema
force-pushed
the
howling-mad
branch
from
10d969a to
ca2877a
Compare
cprerovsky
force-pushed
the
howling-mad
branch
2 times, most recently
from
cf709a2 to
9c8c31f
Compare
Jotschi
changed the title
|
Can one of the admins verify this patch? |
1 similar comment
|
Can one of the admins verify this patch? |
Not ready to merge yet, i'm opening this PR for a discussion. We started it here.
At first i would like to know if this is an issue which needs to be fixed. Right now caret is not rendering in case of aloha being fired up from top document on an element which is in iframe. Is this a use case for aloha? Should we fix it?
While digging in it i found out that somewhere Aloha uses default document, and this is subject to change for sure. In the current state this PR contains some document refactoring, fixes iframe issue and brings in one more sandbox case with iframe.