Menu
▾
▴
bodington-developers
|
From: Jon M. <jo...@te...> - 2006-06-19 15:45:11
Attachments:
top_normal.css
top.html
|
Over the last week or so Ive got increasingly irritated by Bodington's top frame and so I took a couple of hours out from the testing programme to fix it. The best results will need CSS 2.1 compliant browsers but it shouldn't be too bad on CSS 1 browsers. This is still a bit of a compromise because it still works around the frame set and the fact that the top frame height is fixed but the font size is variable. The boxes in the frames now have fixed heights and are set to crop any text that overflows the border. The padding and margins is fixed in units of pixels to prevent the text drifting south as it is enlarged. A key change is to put the title text last in the top box so that it flows between the right and left floating sub-boxes. At present I dont have access to commit source to the CVS with my new user name so Ive attached the two files that Ive edited so you can test what Ive done with various browsers. (I've only tested with Firefox). Jon |
|
From: Matthew B. <mat...@ou...> - 2006-06-19 15:51:16
|
Jon Maber wrote: > Over the last week or so Ive got increasingly irritated by Bodington's > top frame and so I took a couple of hours out from the testing programme > to fix it. The best results will need CSS 2.1 compliant browsers but it > shouldn't be too bad on CSS 1 browsers. Nice one. Could you outline the bugs that this fixes? -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Jon M. <jo...@te...> - 2006-06-19 16:00:34
|
Matthew Buckett wrote: > Jon Maber wrote: > >> Over the last week or so Ive got increasingly irritated by Bodington's >> top frame and so I took a couple of hours out from the testing programme >> to fix it. The best results will need CSS 2.1 compliant browsers but it >> shouldn't be too bad on CSS 1 browsers. >> > > Nice one. > Could you outline the bugs that this fixes? > Yep... o For long titles and large font sizes the title reaches across to the search and commands box on the right and that box pops out of view and the title texts goes to the right of the page before wrapping. o As the font is enlarged the margin above the text elements increases too so the text drifts out of view. o As the font is enlarged it spills out of its designated div and goes over the box below. These are all fixed although there is no way to stop the text eventually becoming illegible when it is very big because it gets cropped. The fix to the second bug only works on CSS 2.1 compliant browsers. Another bug which I've not fixed: o The background colours in the top frame are hardwired in a static CSS file but the foreground colours are taken from the dynamic CSS - a recipe for disaster. Temp fix - add foreground colours to the static CSS. Proper fix - process all the colours. (Which I could do given a little funding....) Jon |
|
From: Antony C. <an...@sm...> - 2006-06-20 12:10:47
|
Thanks John we were about to crop title text in top frame. Have also moved search to LHS frame and other links from top div to 'login' div. Have you committed these files? On 19 Jun 2006, at 17:00, Jon Maber wrote: > Matthew Buckett wrote: >> Jon Maber wrote: >> >>> Over the last week or so Ive got increasingly irritated by >>> Bodington's >>> top frame and so I took a couple of hours out from the testing >>> programme >>> to fix it. The best results will need CSS 2.1 compliant browsers >>> but it >>> shouldn't be too bad on CSS 1 browsers. >>> >> >> Nice one. >> Could you outline the bugs that this fixes? >> > Yep... > o For long titles and large font sizes the title reaches across to the > search and commands box on the right and that box pops out of view and > the title texts goes to the right of the page before wrapping. > o As the font is enlarged the margin above the text elements increases > too so the text drifts out of view. > o As the font is enlarged it spills out of its designated div and goes > over the box below. > These are all fixed although there is no way to stop the text > eventually > becoming illegible when it is very big because it gets cropped. The fix > to the second bug only works on CSS 2.1 compliant browsers. > > Another bug which I've not fixed: > o The background colours in the top frame are hardwired in a static CSS > file but the foreground colours are taken from the dynamic CSS - a > recipe for disaster. > Temp fix - add foreground colours to the static CSS. Proper fix - > process all the colours. (Which I could do given a little funding....) > > Jon > > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Jon M. <jo...@te...> - 2006-06-19 16:09:12
|
Jon Maber wrote: > The fix > to the second bug only works on CSS 2.1 compliant browsers. > Meant to say third bug. |
|
From: Jon M. <jo...@te...> - 2006-06-20 11:40:17
|
I've finished the job off. Now all the colours are fixed, rather than just the background colours. Fixed background colours break the accessibility options but having fixed background and foreground colours breaks it less. For example, if the user selected white text on black background the top frame became totally illegible because it produced white text on an off-white background. There are many other templates which are still very dodgy. I found there were three different stylesheets for the top frame but this is not necessary - Ive reduced it to two, which has also involved chopping some code out of the template. Jon P.S. Sean, can I have access to check in to the CVS? In the meantime I've attached the files to this Email. |
|
From: Jon M. <jo...@te...> - 2006-06-20 12:24:00
|
Antony Corfield wrote: > Thanks John we were about to crop title text in top frame. Do you mean output less text from the template? The styling should make that unnecessary - the full space will be used and any extra text will be cropped at the bottom of the div. > Have also > moved search to LHS frame and other links from top div to 'login' div. > Have you committed these files? > My user ID doesn't have access to the CVS so I can't commit. I've attached another set of versions to this Email because I got I.E. 6 working in a Windows emulator and there were problems. At the same time I changed the way styling adapts to the thinner top frame used with PDAs. Now the normal css file is always included and a very small css file is added to the HTML if the slim line top frame has been selected. This makes it much easier to maintain the CSS. Jon |
|
From: Colin T. <col...@ou...> - 2006-06-20 12:29:25
|
Jon Maber wrote: > My user ID doesn't have access to the CVS so I can't commit. I can sort that if you need me to... -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Jon M. <jo...@te...> - 2006-06-20 12:58:25
|
Colin Tatham wrote: > Jon Maber wrote: > >> My user ID doesn't have access to the CVS so I can't commit. >> > > I can sort that if you need me to... > Yes please. |
|
From: Antony C. <an...@sm...> - 2006-06-20 12:30:49
|
On 20 Jun 2006, at 13:23, Jon Maber wrote:
> Antony Corfield wrote:
>> Thanks John we were about to crop title text in top frame.
> Do you mean output less text from the template?
Yes I did but will test your updates... is this a move to css files!
> The styling should make that unnecessary - the full space will be used
> and any extra text will be cropped at the bottom of the div.
>> Have also moved search to LHS frame and other links from top div to
>> 'login' div. Have you committed these files?
>>
> My user ID doesn't have access to the CVS so I can't commit.
>
> I've attached another set of versions to this Email because I got I.E.
> 6 working in a Windows emulator and there were problems. At the same
> time I changed the way styling adapts to the thinner top frame used
> with PDAs. Now the normal css file is always included and a very small
> css file is added to the HTML if the slim line top frame has been
> selected. This makes it much easier to maintain the CSS.
>
> Jon
>
>
>
>
> #NavigationContainer {
> /* frame is fixed height so this must be fixed height */
> height:24px;
> }
>
> #Search{
> height:0px;
> }
>
> #SearchKeywords{
> height:0px;
> }
> #SearchSubmit{
> height:0px;
> }
>
> #LoggedOnContainer{
> /* Fixed height to make sure border is visible */
> height: 15px;
> }
>
> .Title {
> /* Title is put in a fixed height box so the layout manager
> knows where the middle is.
> */
> height:22px;
> }
> preference.navigation.illustrations stylesheet small
> preference.navigation.nav_bar_height small big
> linkout
>
> Options notifyswitch Options Advanced Search
> title
> hidden preference.navigation.illustrations <image.tiff>
> <image.tiff> EEEE, d MMM yyyy You are logged in as:
> nameofuser
> body {
> /* ensure sub blocks touch edges of frame */
> margin: 0px;
> }
>
>
> #NavigationContainer {
> /* frame is fixed height so this must be fixed height */
> height:46px;
> /* prevents colour preferences from working - bad thing */
> background-color: #EEEEEE;
> /* at least it makes sure that there is always a high contrast */
> color: black;
> /* thin rule across bottom of box separates it from lower box */
> border-bottom:1px solid #aaaaaa;
> /* if the user increases text size it will be cropped within the
> 46px height */
> overflow: hidden;
> }
>
> #NavigationContainer :link {
> color: blue;
> }
>
> #NavigationContainer :visited {
> color: purple;
> }
>
> #Icon{
> /* does this really need properties? */
> }
>
>
> #Link{
> /* This box has the search and command sub boxes and floats on the
> right */
> /* It has to float to allow the title text to flow in the middle
> */
> float:right;
> text-align: right;
> padding: 0px 15px 0px 0px;
> margin: 0px 0px 0px 0px;
> }
>
> #Search{
> /* makes sure anything that creeps out of box is clipped */
> overflow: hidden;
> /* container box has fixed height so this must too */
> height: 18px;
> width: 250px;
> padding: 0px 0px 0px 0px;
> margin: 0px 0px 0px 0px;
> }
>
>
> #Search form{
> /* This is a bit of a bodge to make sure that the form element
> doesnt add extra space and push the input elements downwards
> */
> font-size: 0px;
> margin: 0px 0px 0px 0px;
> padding: 0px 0px 0px 0px;
> }
>
>
> #SearchKeywords{
> /* The text input has fixed dimensions and fixed font size because
> it has to fit in a fixed height box. However, in Firefox there
> is
> no such thing as a fixed font size so it goes out of whack on
> big
> text sizes.
> */
> font-size: 9px;
> height:18px;
> width:150px;
> margin: 0px 0px 0px 0px;
> padding: 0px 0px 0px 0px;
> }
> #SearchSubmit{
> /* Same considerations for button input */
> font-size: 9px;
> height:18px;
> margin: 0px 0px 0px 0px;
> padding: 0px 0px 0px 0px;
> }
>
> #Commands{
> /* There is space for the text to enlarge so a relative font size
> is specified.
> */
> font-size: 75%;
> text-align: right;
> padding: 0px 0px 0px 0px;
> margin: 0px 0px 0px 0px;
> }
>
> #LoggedOnContainer{
> /* This is the other main box. It doesnt matter if contents spill
> out of the bottom edge because that will be clipped by the frame
> */
> background-color: #ffffff;
> color: black;
> margin: 0px 0px 0px 0px;
> padding: 0px 0px 0px 0px;
> /* Fixed height to make sure border is visible */
> height: 19px;
> width:100%;
> border-bottom: 1px solid #aaaaaa;
> }
>
> #LoggedOnContainer :link {
> color: blue;
> }
>
> #LoggedOnContainer :visited {
> color: purple;
> }
>
> #toggleLeftFrame img{
> margin: 2px 0 0 2px;
> }
>
> .Text {
> font-family: Verdana, Arial Unicode MS, Helvetica, sans-serif;
> font-size:0.70em;
> }
>
> .Title {
> /* Title is put in a fixed height box so the layout manager
> knows where the middle is.
> */
> height:44px;
> /* A table cell treats the vertical align differently */
> display: table-cell;
> /* A single line of text goes in the middle of the space but if
> the title
> wraps to two lines the top line shifts up. When the box is
> filled it
> aligns at the top.
> */
> vertical-align: middle;
> font-size: 100%;
> font-weight:bold;
> padding: 0px 0px 0px 8px;
> margin: 0px 0px 0px 0px;
> line-height: 100%;
> }
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
|
|
From: Jon M. <jo...@te...> - 2006-06-20 12:57:24
|
Antony Corfield wrote: > is this a move to css files! > No, its a case of making the best of a bad job. ;-) Jon |
|
From: Jon M. <jo...@te...> - 2006-06-20 15:51:13
|
I have commit access to the CVS repository with my new user name so Ive stuck these updates in. Ive only tested on Firefox and IE6. Could someone try it out on Safari? Jon |
|
From: Antony C. <an...@sm...> - 2006-06-20 15:54:41
|
yep On 20 Jun 2006, at 16:51, Jon Maber wrote: > I have commit access to the CVS repository with my new user name so Ive > stuck these updates in. > > Ive only tested on Firefox and IE6. Could someone try it out on Safari? > > Jon > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Matthew B. <mat...@ou...> - 2006-06-21 08:07:28
|
Jon Maber wrote: > I have commit access to the CVS repository with my new user name so Ive > stuck these updates in. > > Ive only tested on Firefox and IE6. Could someone try it out on Safari? Can I suggest that we also have Bodington work reasonable well on IE 5.5 as it has a reasonable marketshare still. http://www.w3schools.com/browsers/browsers_stats.asp For WebLearn we had a bit of discussion about supported browsers and came up with: Full Supported - Everything works as expected. Testing should mainly be done against these browsers. Firefox (1.0+) - All Platforms Internet Explorer (5.5, 6.0+) - Windows Well Supported - The whole site display correctly and is useable although some advanced features may not work correctly, although there should be work arounds. Safari (?) - Mac Opera (7.5+) - all Platforms Working - These browsers allow you to use WebLearn but we do not guarantee how it will display. All the information should still be readable though and you should be able to use most of the functionality. Internet Explorer - Mac Opera Mini - Mobile Phones/PDAs? Notes: All of WebLearn should work without any plugins and with JavaScript turned of although it is perfectly acceptable to use these technologies to enhance the experience (eg RTWEdit). Of course all we can do is affect the tool, nothing at the moment stops users uploading material isn't accessable. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Colin T. <col...@ou...> - 2006-06-21 08:51:58
|
Jon Maber wrote: > I have commit access to the CVS repository with my new user name so Ive > stuck these updates in. > > Ive only tested on Firefox and IE6. Could someone try it out on Safari? I've tried on Linux/Firefox, Win/Firefox and Win/IE 6 (with user settings set to defaults) and found the following in all cases. Is anyone else seeing them, are they intended? - text size of links has changed (bigger) - size of 'Search' text and button is smaller - search box positioning has moved up to top of frame - all text and toggle icons have moved up to top of logged in div - (IE6 only) title of current resource moved up to top of frame Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Jon M. <jo...@te...> - 2006-06-21 09:29:23
|
Did you test it by increasing the font size and accessing a resource with a very long title? Colin Tatham wrote: > - text size of links has changed (bigger) > Unintentional - please adjust back down if you wish. > - size of 'Search' text and button is smaller > This is a bit tricky because additional browser specific rules apply beyond the CSS handling. I tried to fix the font size since the size of the control itself is fixed but I found that Firefox ignores absolute font sizes and scales them. That means that if the font size is increased the button label becomes illegible. By making it smaller in the first place it remains legible for longer as the font sizes are notched up. > - search box positioning has moved up to top of frame > To allow more space for growing text below it. > - all text and toggle icons have moved up to top of logged in div > Ditto - when the font is increased it grows downwards. (But not the icons - please adjust to taste) > - (IE6 only) title of current resource moved up to top of frame > Ditto - allows space for several lines of text if the font enlarges or if the title is very long. I fixed the aesthetics for CSS2.1 compliant browsers by setting the display mode to a table cell and the vertical alignment to middle. Sadly IE doesn't implement these rules so the only solution would have been to actually tag the title up as a table. > Colin > > I've commented the CSS file to explain the properties. |
|
From: Colin T. <col...@ou...> - 2006-06-21 09:53:34
|
Jon Maber wrote: > Did you test it by increasing the font size and accessing a resource > with a very long title? Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat was preventing me seeing the effects of changes to template/css files...) The title re-arranging itself worked quite well in Firefox, but IE6 wasn't great. Colin > Colin Tatham wrote: > >>- text size of links has changed (bigger) >> > > Unintentional - please adjust back down if you wish. > >>- size of 'Search' text and button is smaller >> > > This is a bit tricky because additional browser specific rules apply > beyond the CSS handling. I tried to fix the font size since the size of > the control itself is fixed but I found that Firefox ignores absolute > font sizes and scales them. That means that if the font size is > increased the button label becomes illegible. By making it smaller in > the first place it remains legible for longer as the font sizes are > notched up. > >>- search box positioning has moved up to top of frame >> > > To allow more space for growing text below it. > >>- all text and toggle icons have moved up to top of logged in div >> > > Ditto - when the font is increased it grows downwards. (But not the > icons - please adjust to taste) > >>- (IE6 only) title of current resource moved up to top of frame >> > > Ditto - allows space for several lines of text if the font enlarges or > if the title is very long. I fixed the aesthetics for CSS2.1 compliant > browsers by setting the display mode to a table cell and the vertical > alignment to middle. Sadly IE doesn't implement these rules so the only > solution would have been to actually tag the title up as a table. > >>Colin >> >> > > I've commented the CSS file to explain the properties. > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Jon M. <jo...@te...> - 2006-06-21 10:17:01
|
Colin Tatham wrote: > Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was > intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat > was preventing me seeing the effects of changes to template/css files...) > Caching of CSS files in browsers is really really bad news. In Firefox, if you reload a page the CSS files referenced within frames are NOT reloaded. To test my edits I had to type the URL of the top frame into the location box - reloading that properly reloaded the CSS files. I'm not sure about I.E. but it seems worse than Firefox most of the time. The mechanism for handling dynamic CSS files in Bodington goes to great lengths to make sure that all browsers implement changes immediately while maintaining the performance advantages. The virtual CSS file that is directly referenced by the HTML is nearly empty - it just includes the actual CSS files. This tiny CSS file is delivered with headers that prevent any kind of caching so that any changes made to it are instantly applied but the size is so small that the lack of caching doesn't slow things down. The proper virtual CSS files are sent with headers that encourage caching. If the CSS needs to change the URL also changes and the include instructions in the master CSS change. Since the URLs have not been seen before the browser is forced to load them and apply them. Jon |
|
From: Colin T. <col...@ou...> - 2006-06-21 10:33:43
|
Jon Maber wrote: > Colin Tatham wrote: > >>Yes, but not very thoroughly. (I was wanting to check that the default view I was seeing was >>intentional, it looked odd to me, and I have had problems in the past where either Firefox or Tomcat >>was preventing me seeing the effects of changes to template/css files...) >> > > Caching of CSS files in browsers is really really bad news. In Firefox, > if you reload a page the CSS files referenced within frames are NOT > reloaded. To test my edits I had to type the URL of the top frame into > the location box - reloading that properly reloaded the CSS files. Yes, or to make sure, I type in the URLs of the CSS files, and refresh each one. I have found something similar with templates occasionally. I haven't narrowed it down, but when it happens I have to go through a process of undeploying, cleaning the whole webapp and re-deploying. If that doesn't work, stopping Tomcat, checking that there's no process still hanging around (kill it) and start Tomcat again! Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Antony C. <an...@sm...> - 2006-06-21 13:46:35
|
with Safari... Loose location icons along with search and links except logout. Shrinking window causes text to collapse better but eventually spills over into login div. On 21 Jun 2006, at 11:33, Colin Tatham wrote: > Jon Maber wrote: >> Colin Tatham wrote: >> >>> Yes, but not very thoroughly. (I was wanting to check that the >>> default view I was seeing was >>> intentional, it looked odd to me, and I have had problems in the >>> past where either Firefox or Tomcat >>> was preventing me seeing the effects of changes to template/css >>> files...) >>> >> >> Caching of CSS files in browsers is really really bad news. In >> Firefox, >> if you reload a page the CSS files referenced within frames are NOT >> reloaded. To test my edits I had to type the URL of the top frame into >> the location box - reloading that properly reloaded the CSS files. > > Yes, or to make sure, I type in the URLs of the CSS files, and refresh > each one. > > I have found something similar with templates occasionally. I haven't > narrowed it down, but when it > happens I have to go through a process of undeploying, cleaning the > whole webapp and re-deploying. > If that doesn't work, stopping Tomcat, checking that there's no > process still hanging around (kill > it) and start Tomcat again! > > Colin > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Jon M. <jo...@te...> - 2006-06-21 14:21:37
|
Antony Corfield wrote: > with Safari... > Loose location icons along with search and links except logout. > Could you elaborate? Are the icons missing all the time? > Shrinking window causes text to collapse better but eventually spills > over into login div. > Does the overspilling text overwrite the content of the lower box or push it down? A not very pro CSS solution would be to go back to the use of a table. I.e. one row, two cells. The height of the row could be fixed and the width of the right hand cell fixed. This solution would not be too bad for accessibility because it could be navigated linearly and would work better with browsers that implement CSS to version 1 or dont handle it at all. What do you think about tables? Jon |
|
From: Colin T. <col...@ou...> - 2006-06-21 14:50:58
|
Jon Maber wrote: > A not very pro CSS solution would be to go back to the use of a table. > I.e. one row, two cells. The height of the row could be fixed and the > width of the right hand cell fixed. This solution would not be too bad > for accessibility because it could be navigated linearly and would work > better with browsers that implement CSS to version 1 or dont handle it > at all. What do you think about tables? If it works I wouldn't mind. We need to find a better overall solution at some point, so this would only be in the interim. I think we should also decide what the priorities are, as we no-one seems to have found the perfect solution yet (we've also had Owen here looking at it for quite a while). Visual appearance? Text re-sizing in browser? Displaying full title rather than abbreviating it? Limiting max number of parent icons to display? Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: Owen D. <owe...@ou...> - 2006-06-21 15:35:28
|
having spent a fair bit of time on this, i have come to the conclusion that the only justifiable solution is to have a vertical scroll bar on the top frame, because any other solution prevents users who enlarge their text from viewing some of the site content and/or functionality. that is, of course, until the dreaded frames are ditched! owen ----- Original Message ----- From: "Colin Tatham" <col...@ou...> To: "Bodington developers" <bod...@li...> Sent: Wednesday, June 21, 2006 3:50 PM Subject: Re: [Bodington-developers] Top frame styling improvement - commited to HEAD > Jon Maber wrote: >> A not very pro CSS solution would be to go back to the use of a table. >> I.e. one row, two cells. The height of the row could be fixed and the >> width of the right hand cell fixed. This solution would not be too bad >> for accessibility because it could be navigated linearly and would work >> better with browsers that implement CSS to version 1 or dont handle it >> at all. What do you think about tables? > > If it works I wouldn't mind. We need to find a better overall solution at > some point, so this would > only be in the interim. > > I think we should also decide what the priorities are, as we no-one seems > to have found the perfect > solution yet (we've also had Owen here looking at it for quite a while). > Visual appearance? Text > re-sizing in browser? Displaying full title rather than abbreviating it? > Limiting max number of > parent icons to display? > > Colin > > -- > ____________________________________ > Colin Tatham > VLE Team > Oxford University Computing Services > > http://www.oucs.ox.ac.uk/ltg/vle/ > http://bodington.org > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Jon M. <jo...@te...> - 2006-06-21 15:56:33
|
In summary, o There is a good solution - using CSS 2.1, trouble is it requires browsers to properly support CSS 2.1 o Bad browsers mean we need to use bad HTML and/or bad CSS o My conclusion is that we have to deal with the whackier browsers for the time being and plan for most browsers properly supporting CSS in a year or two's time. Therefore I propose an interim solution, i.e. the use of a very simple table with a fixed height. One cell on the left would contain the navigation icons and the title and within that the icons would float left therefore allowing the title to wrap to two or more lines beside it. A second cell on the right would have a fixed width and contain... ...what? Just the quick search? The use of the table makes it possible to vertically centre all the contents which would be neat and should work on all browsers. The rest of the frame could be outside the table or in a second one row table and could also vertically centre the contents. Jon Owen Davies wrote: > having spent a fair bit of time on this, i have come to the conclusion that > the only justifiable solution is to have a vertical scroll bar on the top > frame, because any other solution prevents users who enlarge their text from > viewing some of the site content and/or functionality. that is, of course, > until the dreaded frames are ditched! > > owen > ----- Original Message ----- > From: "Colin Tatham" <col...@ou...> > To: "Bodington developers" <bod...@li...> > Sent: Wednesday, June 21, 2006 3:50 PM > Subject: Re: [Bodington-developers] Top frame styling improvement - commited > to HEAD > > > >> Jon Maber wrote: >> >>> A not very pro CSS solution would be to go back to the use of a table. >>> I.e. one row, two cells. The height of the row could be fixed and the >>> width of the right hand cell fixed. This solution would not be too bad >>> for accessibility because it could be navigated linearly and would work >>> better with browsers that implement CSS to version 1 or dont handle it >>> at all. What do you think about tables? >>> >> If it works I wouldn't mind. We need to find a better overall solution at >> some point, so this would >> only be in the interim. >> >> I think we should also decide what the priorities are, as we no-one seems >> to have found the perfect >> solution yet (we've also had Owen here looking at it for quite a while). >> Visual appearance? Text >> re-sizing in browser? Displaying full title rather than abbreviating it? >> Limiting max number of >> parent icons to display? >> >> Colin >> >> -- >> ____________________________________ >> Colin Tatham >> VLE Team >> Oxford University Computing Services >> >> http://www.oucs.ox.ac.uk/ltg/vle/ >> http://bodington.org >> >> >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > |
|
From: Antony C. <an...@sm...> - 2006-06-22 09:05:47
|
How about a much simpler approach?!! Just add a method 'public static String trimText(String text, int maxLength)' to org.bodington.util.TextUtils and use that whenever there's a limited space for displaying text? Could always use title attribute in link to display full text. As I said we've also removed search and links from the navigation div so we have more space to play with. On 21 Jun 2006, at 16:56, Jon Maber wrote: > In summary, > o There is a good solution - using CSS 2.1, trouble is it requires > browsers to properly support CSS 2.1 > o Bad browsers mean we need to use bad HTML and/or bad CSS > o My conclusion is that we have to deal with the whackier browsers for > the time being and plan for most browsers properly supporting CSS in a > year or two's time. > > Therefore I propose an interim solution, i.e. the use of a very simple > table with a fixed height. One cell on the left would contain the > navigation icons and the title and within that the icons would float > left therefore allowing the title to wrap to two or more lines beside > it. A second cell on the right would have a fixed width and contain... > ...what? Just the quick search? The use of the table makes it possible > to vertically centre all the contents which would be neat and should > work on all browsers. > > The rest of the frame could be outside the table or in a second one row > table and could also vertically centre the contents. > > Jon > > > Owen Davies wrote: >> having spent a fair bit of time on this, i have come to the >> conclusion that >> the only justifiable solution is to have a vertical scroll bar on the >> top >> frame, because any other solution prevents users who enlarge their >> text from >> viewing some of the site content and/or functionality. that is, of >> course, >> until the dreaded frames are ditched! >> >> owen >> ----- Original Message ----- >> From: "Colin Tatham" <col...@ou...> >> To: "Bodington developers" >> <bod...@li...> >> Sent: Wednesday, June 21, 2006 3:50 PM >> Subject: Re: [Bodington-developers] Top frame styling improvement - >> commited >> to HEAD >> >> >> >>> Jon Maber wrote: >>> >>>> A not very pro CSS solution would be to go back to the use of a >>>> table. >>>> I.e. one row, two cells. The height of the row could be fixed and >>>> the >>>> width of the right hand cell fixed. This solution would not be too >>>> bad >>>> for accessibility because it could be navigated linearly and would >>>> work >>>> better with browsers that implement CSS to version 1 or dont handle >>>> it >>>> at all. What do you think about tables? >>>> >>> If it works I wouldn't mind. We need to find a better overall >>> solution at >>> some point, so this would >>> only be in the interim. >>> >>> I think we should also decide what the priorities are, as we no-one >>> seems >>> to have found the perfect >>> solution yet (we've also had Owen here looking at it for quite a >>> while). >>> Visual appearance? Text >>> re-sizing in browser? Displaying full title rather than abbreviating >>> it? >>> Limiting max number of >>> parent icons to display? >>> >>> Colin >>> >>> -- >>> ____________________________________ >>> Colin Tatham >>> VLE Team >>> Oxford University Computing Services >>> >>> http://www.oucs.ox.ac.uk/ltg/vle/ >>> http://bodington.org >>> >>> >>> _______________________________________________ >>> Bodington-developers mailing list >>> Bod...@li... >>> https://lists.sourceforge.net/lists/listinfo/bodington-developers >>> >>> >> >> >> >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X