Table of topic groups > Front page of CSS-guide > Proposals > Comments to my proposals for CSS3

Comments to my proposals for CSS3

Topics

• Inconvenient features in CSS
  • Background values
• HTML

Inconvenient features in CSS

Background values

Everything works fine as far as elements are small, but BODY and HTML concerns the whole document , which makes serious problems to background definition. Backgrounds are displayed always in a WINDOW (window can be a frame, pop-up window or ordinary frame free HTML document).

Microsoft handles BODY element as there would be element container "window", which is technical language called viewport. MS calculate background values according viewport, if the background does have definition fixed. In my mind this is correct, because CSS2 14.2.1 W3C specifications says:

If the background image is fixed within the viewport ..., the image is placed relative to the viewport instead of the element's padding area.

It is error if user agent (= the browser) can't keep the image fixed:

User agents may treat fixed as scroll. However, it is recommended they interpret fixed correctly, at least for the HTML and BODY elements, since there is no way for an author to provide an image only for those browsers that support fixed.

It is not guaranteed that the background is visible:

Even if the image is fixed, it is still only visible when it is in the background or padding area of the element. Thus, unless the image is tiled (background-repeat: repeat), it may be invisible.

This may happen, if the background is defined into TABLE or other block-level container element, but not into BODY, which concerns the whole document. But the element BODY begins always on the top of the viewport - and background should be always visible.

If there would not be background-attachment definition of background-attachment: scroll, the image should calculate like Mozilla - MS IE 5.0 renders background images just the same way as Opera, if I remove the attachment value! Even if there is not container element WINDOW or VIEWPORT, browsers should handle background image according to the container block = viewport if there is definition fixed!

Compare to common rule 10.1 Definition of "containing block" (the principle in BODY works quite the same like containing block elements:

If the element has position: fixed, the containing block is established by the viewport.

In order to get quite the same result as Microsoft, basic background and possible border values should put first in HTML element container:

HTML
/* this is in a separate file, because HTML can't have class names*/ {margin: 0px; padding:0px;
border-top: thin maroon solid;
border-left: thin maroon solid;
border-right:none;
border-bottom:thin maroon solid;
background: #DCD2D3 url(./Taulut/Pystyreuna.gif) repeat-y ;
background-position: 0px -30px;
}

BODY.alkusivut {
background: #DCD2D3 url(./Taulut/Pystyreuna.gif) repeat-y ;
background-position: 0px -30px;
padding-top: 10px;
padding-left: 30px;
padding-right: 10px;
padding-bottom: 10px;
margin: 0px;
border-top: thin #66302F groove;
border-left: thin #66302F groove;
border-right: none;
border-bottom: thin #66302F groove;}


In the newest test version the background and border value works well, when I defined them to both HTML and BODY.

A little bit better result can be achieved to container elements HTML and BODY, if in future CSS-definitions would be added border-attachment -value, which could work according to the same principles as background-attachment and does have values scroll and fixed. Fixed would go according to the viewport - like MS 5.0. Scroll means the system, which Mozilla and Opera have just now - and very often there is no border on the top or bottom. My proposals as new standards into the CSS3:

If borders of BODY or HTML container element is defined border-attachment:fixed, they are fixed within the viewport and borders are placed according to the viewport instead of the element's padding area.

Then the browser would behave at the same way as MS IE 5.0 works today, but because this would be standard behavior, also Mozilla organisation and Opera could support it and it would be possible to create pages, which works at the same way in all major browser.

If you could put different definitions to HTML like <HTML class="background-class1"> (I don't use this name - this is an example only), the CSS system would be more flexible, because all definitions could be in a single CSS-file. Now I must put many versions of CSS-files to define different values to HTML -element - not very effective. This definition, which is in this paragraph is however invalid according to W3C!

HTML

I have in my Finnish pages some suggestions concerning references and I write about them to you in English, because you cannot read my Finnish texts:

• Pop-up windows could be some kind of extensions in HTML and they would not need javascript. After target definition there could be eg. <A HREF="../Seurakunta/vasen_alue.html" target="_blank" value="top:30; left:30; width:630; height=400">
• Multi linking. That means that instead of opening a single file there could be the possibility to open multiple files like <A href="../Seurakunta/vasen_alue.html" target=left value="top:30; left:30; width:630; height=400;" HREF="../Seurakunta/Virheet.html" target=keski>. At this system the user could exchange the content of several frames at the same time, but he would not need to exchange the whole frameset neither use block level frame systems like I have designed.
• All documents should have the possibility give a name even if they don't belong into a frameset. Then all documents could be called with targets. A file could have this property: <HEAD> <Document Name=Tapio></HeAD>;

These are possible to define with JS 1.2, but:

• Java scripts, which exchange the contents of a frame are unreliable. NS 4.04 gives error messages of this script, when loading this script another time ("KehyksenNimi.location is read-only"; works well with IE 4.01 and Opera 3.60):

  <SCRIPT>
<!--function tiedote(KehyksenNimi, Tiedosto)
{
KehyksenNimi.location=Tiedosto;
}
// -->
</SCRIPT>
<BODY BGCOLOR="#ffffff" TEXT="#3f3f3f" LINK="#3f3f3f" VLINK="#2f2f2f" onunload="onunLoad="tiedote(parent.ylareuna, 'Frame13fyla.html') ;"tiedote(parent.alareuna, 'Frame13fala.html')">" onLoad="tiedote(parent.ylareuna, 'Frame13fyla.html') ;"tiedote(parent.alareuna, 'Frame13fala.html')">

• Many people take java script support off - JS 1.2 does have security problems.

In my mind the need of scripts should minimize just for the security. I try to design my pages so, that java script support is not needed. But all pop-up windows needs them - that's the problem. I put soon in the net as common page concerning this matter and a suggestion of better navigation system ([S]).