D
Dep
Guest
The discussion on Firefox 2 was getting off topic a bit so I have started a new one.
http://ukcaving.com/board/index.php/topic,2828.0.html
An interesting subject, it seems we have similar viewpoints but have approached the subject from two different technical perspectives.
I have to be honest and say that I know very little about the .net architecture. I am only an amateur web-developer, my primary skill is as a programer.
I have a good understanding of what I am doing with webcode but I am always happy to learn new ideas or have my false impressions corrected.
I like the CSS model, it works for me and has never seemed anything other than quite straightforwards once grasped. (but isn't that the way of all things!
)
However, your comment makes me think that you have not fully understood the CSS model either.
>>CSS was supposed to make changing a web site style easy and simple.
It does - if properly implemented.
By producing HTML code that has no styling or formating all the style goes into a CSS file.
The code is rendered by any browser in its purest form and the style is laid over using one or several stylesheets - alternate browser-specific stylesheets are just as simple.
The HTML code contains nothing but the most basic structure and the content itself.
>>The very fact that a CSS change CAN turn into a "major coding" exercise
But it doesn't for me - I think you misunderstood me.
I can make global changes to the site style in seconds by only changing one or two files.
The key factor is PROPERLY IMPLEMENTED.
If it wasn't, and there were loads of STYLE tags everywhere or worse still the deprecated FONT tag all over then place then your comment would be totally valid - but I haven't done it like that for exactly that reason.
>>I use .NET base classes modified as required
If I understand this correctly this is basically the same as how it is done in the CSS. My HTML is format free, all I have are ID or CLASS atrributes for each of the principle elements.
The single CSS file defines the styles for these.
You say that the .net system modified these classes as appropriate - well that's no different to having variant CSS loaded as required.
And surely the .net system must be doing some form of implicit browser detect to output the approriate styling and layout classes?
So what does the .net system output as the definition for each of these classes; presumably a series of CSS selectors?
Surely just two _slightly_ different ways of achieving the same thing?
I like the idea of a CSS standard as this gives each browser manufacturer a clearly understood set of rules to follow - compliancy.
The alternative, to remove the standard makes for proprietary code, and then it becomes a free for all, either having to use the unwieldy .net architecture as nothing else will cope with the plethora of variations or having sites that will only work correctly in 'compatible' browsers.
There was a move a while back to attempt to replace the TABLE element used to structure pages into a table-free CSS based layout relying upon the CSS to position, size and align the various DIV elements that make up the page.
There is nothing complicated about it, put this element here, make it this big and align it like this - done.
The very specific problem I have here is the way that the float attribute is rendered in IE7.
I have a container DIV for the page and two sidebars (left and right)
The sidebars are generally short, the main page content is usually much longer.
Thus:
(Not sure what the forum post will make of angle or square brackets so I have used curly brackets instead throughout - I'm sure you'll figure it out.)
{div id="frame"}
{div id="header"}
{/div}{!--header--}
{div id="content"}
{div id="rightbar" class="sidebar"}
{LINKS}
{/div}{!--rightbar--}
{div id="leftbar" class="sidebar"}
{IMAGE}
{/div}{!--leftbar--}
{p}Blah blah blah blah blah blah{/p}
{p}Blah blah blah blah blah blah{/p}
{p}Blah blah blah blah blah blah{/p}
{/div}{!--content--}
{/div}{!--frame--}
In the single stylesheet I have:
div#header {
regular formatting
}
div#content {
regular formatting
}
div.sidebar {
regular formatting
width:180px
border:1px
}
div#leftbar {
float:left;
}
div#rightbar {
float:right;
}
This is all simple basic stuff - very easy to maintain and works everywhere until IE7 came along.
As I am sure you know the 'float' makes the element pop up to a 'higher'** level than the rest of the page. The two sidebars float up into the corners and sit over the {P} elements in the main body which display between the sidebars and wrap themselves around and expand to the full page width lower down where the sidbars end.
**in this context, by higher I mean further out the plane of the screen, ie one lement covering another.
IE7 did something really odd. It does not place float elements at a higher level.
But my problem, and why I am calling this a bug and not a CSS/HTML coding error is that it does not fail in a consistent fashion.
I could understand it streaming the sidebar as a regular block-level element, or placing it underneath.
But it doesn't. In the example I gave above there is an image in the LH sidebar, a small thumbnail picture 180x135.
It places the paragraph text and the image at the same 'height' (ie plane of page) and displays them in alternate stripes of picture/text/picture/text instead of obtusely placing one atop the other.
Now I'm not too fussed about this, all I have to do is find the required CSS instruction to tell IE7 in whatever way it needs to be told to lift the sidebar up 'higher' and wrap the body text around it - just as the other browsers do.
And then add EITHER a few simple CSS hacks to make IE7 work, or supply a slightly modified CSS for IE7 using the MS proprietary conditional HTML syntax:
{!--[if IE 7]}
@import "/css/ie7_specific.css";
{![endif]--}
So why else did MS design this syntax?
As I said elsewhere I'm not doing this for a living so it will get done when I have time, and as with many technical issues like this a good deal of that time is initially spent simply thinking about the issue and how best to solve it.
My one constraint is that I am not designing a site from scratch, this was an unforseen problem when the current design was implemented and so I MUST find a solution that fits the existing framework, I will not be changing page code unless I really have to.
And I am fairly sure a simple CSS solution will popup, it's just a question of how best to mplement it with the least hassle.
In the meantime I need to find out specifically how IE7 views the CSS, this too presents a major issue as I cannot load IE7 without loosing either IE6 or IE5 on other installations. WTF can't MS give the executable different names iexplore5.exe, iexplore6.exe,.. - then they could coexist without being forced to upgrade and overwrite. Yes I know about all about dual boots but frankly I cannot be arsed to go to those lengths just yet. SIDIGTTS
But until I can see the error for myself I can't do much, people are going to get fed up with me asking for screengrabs all the time - and that's a very hard way to code.
Actually a few ideas have occurred to me whilst typing this, the focus has been on the float element as that is where the fault appears, but I have noticed before that IE* has real serious rendering issues with text-align:justify;
Why should IE7 be any different.
It may actually be a fault here with this causing the {p} text to expand into the sidebar.
Another point AndyF made was that a website is no good if it cannot be seen properly by 90% of users.
This is totally true, but it is also reasonable to assume that siteX should render the same in two consecutive versions of one's product.
The fact that the same code appears so differently in IE6 and IE7 says that something is wrong and that this is a compliancy issue.
And with such a long gap since IE6 came out, IE6 had become the de facto standard browser - combined with FF the two worked in much the same way and were used by the overwhelming majority. I am amazed that IE7 is not designed to continue this - again this makes me think that what I am seeing is buggy behaviour in IE7.
I think (haven't fully verified this yet) that IE7 was intended to take a very strict view of the CSS, and to read it properly and ignore all hacks. This could be annoying but would be deemed a good thing in the long term as CSS hacks are not a good thing at all - the one weakness of the CSS model.
But with IE5 dying out the need for these has gone.
But the bottom line is that 99% of internet users don't use IE5, IE6, IE7, FF, Opera, Lynx etc - they use a 'web-browser' and that's the clever ones who can even distinguish a single application from the apparently seamless 'magic' that is their operating system.
So yes this is a genuine issue with IE7 that will affect others.
I _will_ fix it.
And the CSS method will not hinder me in this fix (I hope!)
One point I will concede is that the fix will need to be sooner than I had initially anticipated.
I will be very interested to identify the specific cause of this difference.
Sorry this is a bit long, but technical stuff so often is.
http://ukcaving.com/board/index.php/topic,2828.0.html
AndyF said:
An interesting subject, it seems we have similar viewpoints but have approached the subject from two different technical perspectives.
I have to be honest and say that I know very little about the .net architecture. I am only an amateur web-developer, my primary skill is as a programer.
I have a good understanding of what I am doing with webcode but I am always happy to learn new ideas or have my false impressions corrected.
I like the CSS model, it works for me and has never seemed anything other than quite straightforwards once grasped. (but isn't that the way of all things!
)However, your comment makes me think that you have not fully understood the CSS model either.
>>CSS was supposed to make changing a web site style easy and simple.
It does - if properly implemented.
By producing HTML code that has no styling or formating all the style goes into a CSS file.
The code is rendered by any browser in its purest form and the style is laid over using one or several stylesheets - alternate browser-specific stylesheets are just as simple.
The HTML code contains nothing but the most basic structure and the content itself.
>>The very fact that a CSS change CAN turn into a "major coding" exercise
But it doesn't for me - I think you misunderstood me.
I can make global changes to the site style in seconds by only changing one or two files.
The key factor is PROPERLY IMPLEMENTED.
If it wasn't, and there were loads of STYLE tags everywhere or worse still the deprecated FONT tag all over then place then your comment would be totally valid - but I haven't done it like that for exactly that reason.
>>I use .NET base classes modified as required
If I understand this correctly this is basically the same as how it is done in the CSS. My HTML is format free, all I have are ID or CLASS atrributes for each of the principle elements.
The single CSS file defines the styles for these.
You say that the .net system modified these classes as appropriate - well that's no different to having variant CSS loaded as required.
And surely the .net system must be doing some form of implicit browser detect to output the approriate styling and layout classes?
So what does the .net system output as the definition for each of these classes; presumably a series of CSS selectors?
Surely just two _slightly_ different ways of achieving the same thing?
I like the idea of a CSS standard as this gives each browser manufacturer a clearly understood set of rules to follow - compliancy.
The alternative, to remove the standard makes for proprietary code, and then it becomes a free for all, either having to use the unwieldy .net architecture as nothing else will cope with the plethora of variations or having sites that will only work correctly in 'compatible' browsers.
There was a move a while back to attempt to replace the TABLE element used to structure pages into a table-free CSS based layout relying upon the CSS to position, size and align the various DIV elements that make up the page.
There is nothing complicated about it, put this element here, make it this big and align it like this - done.
The very specific problem I have here is the way that the float attribute is rendered in IE7.
I have a container DIV for the page and two sidebars (left and right)
The sidebars are generally short, the main page content is usually much longer.
Thus:
(Not sure what the forum post will make of angle or square brackets so I have used curly brackets instead throughout - I'm sure you'll figure it out.)
{div id="frame"}
{div id="header"}
{/div}{!--header--}
{div id="content"}
{div id="rightbar" class="sidebar"}
{LINKS}
{/div}{!--rightbar--}
{div id="leftbar" class="sidebar"}
{IMAGE}
{/div}{!--leftbar--}
{p}Blah blah blah blah blah blah{/p}
{p}Blah blah blah blah blah blah{/p}
{p}Blah blah blah blah blah blah{/p}
{/div}{!--content--}
{/div}{!--frame--}
In the single stylesheet I have:
div#header {
regular formatting
}
div#content {
regular formatting
}
div.sidebar {
regular formatting
width:180px
border:1px
}
div#leftbar {
float:left;
}
div#rightbar {
float:right;
}
This is all simple basic stuff - very easy to maintain and works everywhere until IE7 came along.
As I am sure you know the 'float' makes the element pop up to a 'higher'** level than the rest of the page. The two sidebars float up into the corners and sit over the {P} elements in the main body which display between the sidebars and wrap themselves around and expand to the full page width lower down where the sidbars end.
**in this context, by higher I mean further out the plane of the screen, ie one lement covering another.
IE7 did something really odd. It does not place float elements at a higher level.
But my problem, and why I am calling this a bug and not a CSS/HTML coding error is that it does not fail in a consistent fashion.
I could understand it streaming the sidebar as a regular block-level element, or placing it underneath.
But it doesn't. In the example I gave above there is an image in the LH sidebar, a small thumbnail picture 180x135.
It places the paragraph text and the image at the same 'height' (ie plane of page) and displays them in alternate stripes of picture/text/picture/text instead of obtusely placing one atop the other.
Now I'm not too fussed about this, all I have to do is find the required CSS instruction to tell IE7 in whatever way it needs to be told to lift the sidebar up 'higher' and wrap the body text around it - just as the other browsers do.
And then add EITHER a few simple CSS hacks to make IE7 work, or supply a slightly modified CSS for IE7 using the MS proprietary conditional HTML syntax:
{!--[if IE 7]}
@import "/css/ie7_specific.css";
{![endif]--}
So why else did MS design this syntax?
As I said elsewhere I'm not doing this for a living so it will get done when I have time, and as with many technical issues like this a good deal of that time is initially spent simply thinking about the issue and how best to solve it.
My one constraint is that I am not designing a site from scratch, this was an unforseen problem when the current design was implemented and so I MUST find a solution that fits the existing framework, I will not be changing page code unless I really have to.
And I am fairly sure a simple CSS solution will popup, it's just a question of how best to mplement it with the least hassle.
In the meantime I need to find out specifically how IE7 views the CSS, this too presents a major issue as I cannot load IE7 without loosing either IE6 or IE5 on other installations. WTF can't MS give the executable different names iexplore5.exe, iexplore6.exe,.. - then they could coexist without being forced to upgrade and overwrite. Yes I know about all about dual boots but frankly I cannot be arsed to go to those lengths just yet. SIDIGTTS
But until I can see the error for myself I can't do much, people are going to get fed up with me asking for screengrabs all the time - and that's a very hard way to code.
Actually a few ideas have occurred to me whilst typing this, the focus has been on the float element as that is where the fault appears, but I have noticed before that IE* has real serious rendering issues with text-align:justify;
Why should IE7 be any different.
It may actually be a fault here with this causing the {p} text to expand into the sidebar.
Another point AndyF made was that a website is no good if it cannot be seen properly by 90% of users.
This is totally true, but it is also reasonable to assume that siteX should render the same in two consecutive versions of one's product.
The fact that the same code appears so differently in IE6 and IE7 says that something is wrong and that this is a compliancy issue.
And with such a long gap since IE6 came out, IE6 had become the de facto standard browser - combined with FF the two worked in much the same way and were used by the overwhelming majority. I am amazed that IE7 is not designed to continue this - again this makes me think that what I am seeing is buggy behaviour in IE7.
I think (haven't fully verified this yet) that IE7 was intended to take a very strict view of the CSS, and to read it properly and ignore all hacks. This could be annoying but would be deemed a good thing in the long term as CSS hacks are not a good thing at all - the one weakness of the CSS model.
But with IE5 dying out the need for these has gone.
But the bottom line is that 99% of internet users don't use IE5, IE6, IE7, FF, Opera, Lynx etc - they use a 'web-browser' and that's the clever ones who can even distinguish a single application from the apparently seamless 'magic' that is their operating system.
So yes this is a genuine issue with IE7 that will affect others.
I _will_ fix it.
And the CSS method will not hinder me in this fix (I hope!)
One point I will concede is that the fix will need to be sooner than I had initially anticipated.
I will be very interested to identify the specific cause of this difference.
Sorry this is a bit long, but technical stuff so often is.
