-
Notifications
You must be signed in to change notification settings - Fork 426
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
Internet Explorer support meta-issue #1234
Comments
Good news here: all "Level 1" tasks are finished. (See list above.) (But see the limitations described in the OP.) |
I'll recap here the recent news. Rangy has not corrected the opened bug (https://github.com/hypothesis/dom-text-mapper/issues/40) Results:
Possible next steps:
What do you think? |
Adding a bit more info. As a test, I've backported the relevant functions and made a test with this. (Ignoring the The good news: The IE exception for the The current exception is now inside d-t-m, |
On 2014-06-17 11:41, gergely-ujvari wrote:
If we want to ask for external help (for example, IE engineers), we |
2014.06.17. 13:24 keltezéssel, Kristof Csillag írta:
|
On 2014-06-17 11:41, gergely-ujvari wrote:
To rephrase this: the way the shoot branch of d-t-m uses the selection That's why I would prefer to migrate to it (after finishing the pending |
If our approach is to try to make IE work by doing extensive work inside
I am wary of adding more fixes to the master branch of the d-t-m, but I (Right now I am focusing on the dom-anchors library.) On 2014-06-17 13:22, gergely-ujvari wrote:
|
2014.06.17. 13:29 keltezéssel, Kristof Csillag írta:
|
It seems I was too optimistic. Digging deeper. |
By the way, I think you reported the issue to Rangy in the wrong place. That project has moved to GitHub, as it says front and center of the Google Code site. |
So, it seems that simply introducing the node ignore functions alone will not help us. So I suggest to have the d-t-m future conversation before making more effort to make the d-t-m master branch IE compatible. |
@tilgovi: You're right. What got me confused that the googlecode site had issue status changes, so I thought it was alive too. |
@gergely-ujvari do we deploy okay on IE with fuzzy anchoring disabled at this point? Is the app functional? |
Yes. That has been the case since the 28th of May. (But to deploy for IE,
|
var ua = window.navigator.userAgent;
var msie = ua.indexOf("MSIE ");
var embed = document.createElement('script');
if (msie > 0) {
embed.src = 'https://hypothes.is/embed.js?dtm=false';
} else {
embed.src = 'https://hypothes.is/embed.js';
} The above code is why I vetoed that solution. I would rather not complicate our embed code. Doing so makes it harder to turn on and off for testing and adds bloat to the payload of every embed even for users who don't care about IE support. Please stop repeating that it must be for all users or no users. That's patently false. |
Well, obviously, by adding extra code to the product we ship, one can implement smarter behavior, compared to what we provide by default. However, that does not prove that our product is capable of the smart behavior; on the contrary, the fact that it needs an external fix to do the sane thing proves that our product lacks this ability by default. (Also, I still think that insisting on the external workaround proposed here introduces unnecessary responsibilities and overhead on the integrators, as described here.)
Well, since you asked about something which has already been announced earlier, it was a reasonable assumption that you don't remember all the details - wasn't it? And hence, I gave you a short overview of the situation. To do that, it was only natural that I had to repeat things already said - wasn't it? Also, in the thread at #1233, my claim was not that "it must be for all users or no users". I said that it's unwise to force the integrators add the required auto-configuration, instead of embedding it in the relevant parts of the code. (Especially since the required algorithm might change in the future.) You might disagree with that opinion, but it's not something which can be described as "patently false". In the current thread, when I give a very short summary, I might have oversimplified the situation (by omitting to say that integrators might add external code to make up for the missing feature), so maybe you can describe my summary as incomplete or imprecise, but still not "patently false". |
I misrepresented you when I said "must be [for all users]". Sorry.
You announced that the Level 1 tasks were done. I did look at the checklist before I posted. I could not tell from that for sure that IE actually loaded and worked. I felt I asked a direct, simple question and you seized an opportunity to remind me that you disagreed with me. That feels combative and obnoxious. I know I can do the same at times, so feel free to call me out. |
On 2014-07-09 00:47, Randall Leeds wrote:
In the same announcement which said that level 1 was done, I also wrote that
in the OP.)" And in the OP, I have this definition:
So I had the impression that we have communicated the situation clearly. That's why I assumed that you forgot the details. (It has been 1.5
That was not my purpose. I wanted to give a short summary of the |
Let's get back to this when we decide what to do with the current d-t-m problems. |
I am creating this issue to coordinate and track IE-related activity.
Tasks for "level 1" support (no dtm, no position or fuzzy strategy):
evaluate
APITasks for "level 2" support (including dtm, position and fuzzy strategies)
The text was updated successfully, but these errors were encountered: