|
Um, a frameset is necessary because we don't have any control over the HTML in the included file ie it will probably have it's own DOCTYPE etc and will break XHTML.
Ciao Martin
I don't agree with you. What you write is 100% correct but in this way you are completely taking off a Moodle feature to user compliant with Italian legislation. I agree that Moodle has to allow also not compliant actions, but at the same time, Moodle should provide an alternative. From now on I have no knowledge about what I am going to write. IMO as it is now it is quite incorrect, from my view point. Ciao. Ciao Martin
as far as I am fitting legislation about accessibility I believe I have to know what I am doing and what linking to my course. I mean, I have to know the doctype of the file I am linking. On this basis I made the attached modification to moodle/mod/resource/file/resource.class.patch in order to show a linked html file using the "same window" but without framesets. What is still missing in my hack is the use of the css of the linked file. Let me know your idea, please I need some clarifications.
At this moment on Moodle 1.8 (Note: the issue is reported for 1.8 only) and Moodle 1.9, if you select "Same Window" and "Keep page navigation visible", the linked HTML will be displayed in a frameset. For some legal reasons, Daniele does not want the linked HTML having a DOCTYPE. Daniele also says that it doesn't want a frameset. However in the patch. it still generates frameset... Moreover this modification would imply a new option when you create/edit this kind of resource (checkbox: do not generate a frameset). To be honest, I don't understand exactly what is the problem with the frameset. > However in the patch. it still generates frameset...
No! Where? The code today in use in between a: if (false) { It ONLY creates the frameset. My new code is in the } else { > To be honest, I don't understand exactly what is the problem with the frameset.
The problem with the frameset is this: Read the "Requirement No 2" of the page: http://www.pubbliaccesso.gov.it/normative/DM080705-A-en.htm  Thanks Daniele for your explanation.
To summarize: Thanks to you, Jerome, for your continuous work.
Yes, you are 100% right. I attached a patch (MDL_10021.patch for Moodle 1.8) that:
We need to clarify:
Fantastic Jerome.
I believe my answer is not relevant at all but... in any case, for both questions it should be: yes, of course!!! Ciao and thank you. I come back to this issue
We could : 1. change "Keep page navigation visible on the same page" checkbox for a select box with following value: 2. do not change "Keep page navigation visible on the same page" checkbox and embed everything in object tag (when object tag doesn't support the mime type, the user get download the file) I'm for the 2. Sorry Jerome
I am quite embarrassed. I am for the secont too, but as I already wrote, the last word has to come from others. No problem Daniele
 I see with Martin. After looking at http://joliclic.free.fr/html/object-tag/en/object-results.php
I think we are quite safe to use OBJECT all the time.
+10 from me for #2 in 1.9 and 2.0! Thanks Jerome and Daniele. Commited on 1.8, 1.9 and HEAD
Tested on 1.8 and 1.9 (resource currently broken on HEAD) 1.9: Firefox and Opera on Linux, Safari and IE5-6-7 on Windows 1.8: Firefox on Linux, IE5-6-7 on windows All using standard theme When you retest on QA, try different settings/theme. QA Test steps:
Hello,
tested the update on HEAD using the following settings: Link to file or web site: added a generic URL available on the Internet Accessing the resource using FF2, FF complains about missing plugin. Clicking "Install misisng plugin button", FF ends up telling "Unknown Plugin (Document/unknown)". The resource is not displayed except the ALT link. Using IE7, no complains but no resource displayed as well (except the ALT link). Tested same setting on 1.9 stable and the problems described are the same. Why are you running so fast.
I planned to wait for tomorrow for the next M19 weekly release but you are already testing it !!!! 
Well, I just replaced the file moodle19/mod/resource/type/file/resource.class.php with the new version 1.71.2.15 and I started my test. By checking the "Keep page navigation visible on the same page" I get the notice: Undefined property: resource_file::$navigation and, no block is shown!!
Thanks for the report. Andrea, I confirm that on FF2 (I tested URL on FF3, it worked) and IE6-7, the alternative is displayed for URL resource. I have a look at it.
Daniele, I'll commit soon a fix for the problem you reported. I commited a fix for the notice problem.
For the FF2, IE6-7 problem, it's due that Moodle doesn't identify the mime type of a URL. So in the particular case of URL on another domain, we'll use iframe (or frame). I'll come back soon with a patch for that. I commited the change. Now when you try to display a resource which is not on your Moodle wwwroot, iframe is used instead of the object tag.
commited in 1.8, 1.9 and HEAD.
The resource summary now appears at the bottom of the page - was this a deliberate decision? It would be good if visual changes like this didn't occur in a stable version
After talking with Shane and Martin, here is the situation:
Before the fix, the description was already displayed at the bottom for Flash, PDF, ZIP, MP3, video, image and many other kinds of known file. Only HTML and unknown MIME type files were displayed with a description at the top. In order to be consistent, I put the description at the bottom for HTML/unknown files. When the description is bigger than three/four lines a scrollbar will appear. It sounds a reasonable behavior. However if someone writes an issue and that many people require the need to the description to be displayed at the top, we'll of course consider it I am re-opening this issue for a number of reasons explained in my comment message below.
My reasons for re-opening this issue.
1- All moodle developers know that Daniele is a strong advocate of "WC3 strict XHTML compliance". I have already expressed the view that such compliance problems cannot be considered as "bugs" and certainly not "critical" bugs, since they do not prevent Moodle from "normal operation". However I do agree that Moodle should be as compliant as possible... as long as it does not break things. 2- I hope all Moodle developers agree that fixes committed to CVS for stable moodle versions should be considered with care and should not break existing moodle installations. Of course I appreciate that it is very difficult for developers to test bug fixes for all possible existing moodle configurations. It is of course impossible to do such tests for modules, plugins and themes which are not part of moodle regular distribution. After all these "hedging" considerations here we go... 3- If an HTML page ressource is longer than the navigator's viewport , it displays an ugly, confusing and useless double vertical scrollbar (see attached JR01 screenshot). This double scrollbar is displayed with standard themes when in Teacher mode, with Chameleon theme also in Student mode, with CustomCorners themes (in 1.9) in Teacher and Student modes. 4- The new fix breaks the display of my own orangechoc theme (by adding a vertical bar and a horizontal bar etc.) But I have to find a solution for that by myself, of course. (see attached JR02 screenshot). 5- Suggestions In conclusion, if there is a way to get rid of the "frame" in resource display in Moodle, I am all for it, but only if it does not cause display problems for embedded resource HTML files. Many thanks, Answers to points #3 and #4 of my previous comment.
#3- Upon further investigation, I think I have identified the culprit. #4- As for the problem with fixed width themes (my orangechoc theme) I have found that adding the CSS rule body {overflow-x: hidden;} to the CSS of my HTML uploaded files solves the problem. Plus a couple of other minor changes. So that's OK for the moment. Joseph PS.- I'm sorry if I sounded a bit harsh in my previous comment... Hi Joseph, you didn't sound harsh. I understand that it is bad to have a broken theme after an upgrade. We knew that for some people they could have a second scroll bar in low resolution. I didn't find yet a way to know the exact size of the top menu (neither the bottom description) in order to resize correctly the HTML ressource. We don't even speak about the "no javascript" version which needs static size values...
I agree it's really annoying to navigate into an HTML ressource when there is an horizontal scroll bar. I'll have a look to the horizontal scroll bar on the standard themes 800x600. Hi Joseph,
These issues come with object tag or iframe. The solution would be to come back to the "normal" frame not strict XHTML, as you suggested. I'll talk back with Martin about this issue. PS: I'll not be available before January, I'm off from tomorrow . Martin: I'll probably not have time to implement the Frame/Object option.
You'll need to look at the attached patch: We just need to put back the removed lines of this patch. Then change the user interface: option "Keep navigation on top" should be changed into a select box: No Yes, Frame (Better display) Yes, Object (XHTML strict) Thanks Hi, I'm back from holidays. I attached a patch implementing the select box solution (no, frame tag, object tag) for 1.9.
Commited on 1.8, 1.9 and HEAD
The "keep navigation visible" option is now a select box. No: navigation isn't visible Thank you Jerome,
The latest change is fine with me (offering the 3 options including the possibility to keep a frame tag). However, any uploaded file resource that had previously been embedded in an object tag now defaults to the frame tag, which means that one has to edit them one by one to change from frame to object (if desired). Anyway, I think that now we have reached an acceptable solution for all concerned, Thanks, Joseph Hi Joseph,
I knew you, Daniele and some others would have to change code/settings. I decided to not add some hacky code to manage the two situations (people who updated Moodle in the two last months and people who didn't). So people who updated their Moodle following the first "fix" could have to change the 'keep navigation visible' setting a new time. It's annoying, and I apologize for that. Thank you for your effort. I stay tuned Daniele, Jerome, Joseph, and everyone else, a big thank you for all your work on this issue
Documentation added: PS Just wondering whether we should have a "Keep page navigation visible on the same page" default setting in Administration > Modules > Activities > Resource? If you think so too, please create a new issue for it.
Can someone answer this question for me?
These changes have been added to improve accessibility - presumably for those who use screen readers. When a user has Screenreader set to "Yes" in their profile the settings here are ignored ... so what's the point of making the changes if those it's implemented for do get to use it? I'm really not convinced that displaying the summary text at the bottom of the screen is a good idea.
On a 1024 x 768 screen this makes the viewable area of the web page too small. it's not user friendly to have this small area within the Moodle page. IMO this needs to be at the top of the page so that more of the web page can be displayed below. We really need to lessen the likelihood of scroll bars appearing. I didn't receive alerts for my earlier posts. Re-opening in case that's required to send alerts.
Sorry to keep on about this but I've been playing around further. I've attached a screen shot at 1024 x 768.
I don't believe that what is displayed is a useful representation of the site at www.register.co.uk Hi Ray,
If it doesn't work like that, it's a bug. Hope it helps Hi,
Screen reader: Yes, so there's no accessibility improvement? Yes it works like that... and that's the issue. The no frame (object?) option is pretty hopeless on a 1024 x 768 res. monitor. See screenshot. Better solution: summary at top of page, longer space for display of web page etc. There's a lot of issues here in balance, Ray...
Accessibility is not supposed to totally rely on the screenreader setting ... in fact even having that setting is considered bad form by many people who are interested in Moodle's accessibility (since it's so hard to find, I think). We use it just to force-disable some interfaces in a few places where we could not make things work both ways automatically. Moodle is XHTML strict ... frames are not allowed in XHTML strict. They are the best solution for this problem IMHO but they can't be our default solution if we want to be XHTML strict (and we do). They are there as an option if you don't care. Objects allow us to be strict but don't work quite like frames, as you see. it's basically impossible to have an arbitrary-length summary at the top (remember this could be pages long for some people) and then have a scrolling object WITHIN the same page ... remember that the scrollbars need to fit in the same page ... if the object is only half on the visible page then it's really difficult to scroll down to the bottom, because you have to scroll the real page first, and then the object. You don't want that, trust me. Consistency of an interface is also important. Currently, all the resource types work consistently for all file types and this is a good thing I think. We also can't make too radical changes in the stable branch for 1.9.... especially for resources. At the moment I think we have the best solution for 1.9 which balances all these things, even if it's not perhaps ideal. The resource module is being rewritten in Moodle 2.0 anyway, that would be a good time to perhaps make some radical changes if we can agree exactly what they are. Martin wrote > At the moment I think we have the best solution for 1.9 which balances all these things, even if it's not perhaps ideal.
... for 1.9 AND 1.8 I agree that with choice of display (frame vs. object) we have the best solution at the moment. Since I never ever use a "summary" for resources (I see no use for it) the display of the summary being pushed to the bottom of the screen does not bother me, but I understand it can be a strange place to display a summary for those who do use it. Joseph Thanks for that additional info. that's given me a broader appreciation of the issues involved.
I think Joseph's comments speak volumes in that he never uses the summary ,whilst others do. So different to please all users and their contexts. Interested in the scale of the resource mod rewrite. Could you share a little here, in email or in docs (couldn't find it on the roadmap). Cheers. Thanks everyone for the additional comments.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Critical
still frameset linking html pages
 |
|
Window = Same window
Keep page navigation visible on the same page = selected
Sorry!!!