Gatis wrote:Basically, it seems there are problems with CSS3, because when using compressor, property order is changed, and also duplicate properties are removed. With the updated csscompress.ini file this is not the case anymore.
I wonder if with CSS3 some general rules have changed? Because in the code example mapleleaf gave, there are some duplicate properties. How do browsers handle this situation..?background: #333;
background: -moz-linear-gradient(top, #333, #181818);
background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#333), to(#181818));
background: linear-gradient(#333, #181818);
I've just download it and will test this out shortly.
No, I don't think the order has changed BUT I will check this out. There are no duplicate properties.
1. background:#333 is the fall back for the browser's background (ie) in this case Opera will display #333
2. -moz is for the Gecko engine used by FF albeit Gecko 1.9.1/2 or Gecko 2
3. -webkit is for the webkit engine browser
4. this is used by the Trident engine
5. be also aware of the bi-rendering engine ability that the Maxthon browser has namely the Trident and Webkit engines. This browser should not be ignored since it has approximately 1 billion users in Asia and is ever increasing.
It is therefore that when I develop a web site that I also include for testing not only IE, FF, Opera, Safari, Google Chrome BUT also Maxthon. But in the long run I develop using FF as my preference and it is therefore that I am in the process of showcasing my 3D video cube using only FF.
BTW, last Thursday while testing my 3|D video cube, I had discovered a bug within the Gecko 2 engine that is currently being addressed by Mozilla which has been confirmed and identified. The cube will at the moment only work with/in FF 3.6 but not in FF4.0. I am using for the 3D cube the fallback method for the video as the html5 video tag; in fact the multimedia tags for html5 need alot of work before it becomes a specification.
A particular rendering engine will simply ignore a statement and only apply that which is defined for its engine.
I cant place what the issue is with compression at the moment why this occurs BUT I will find it.
Later tonight I will test the file that you've listed. I could also send you a copy of my CSS file(uncompressed), and compressed which I've done manually and a copy of the compression that I did with WB as well as with the compression from a program that I have made using HTML Guardian from http://www.protware.com/, I am using their version 7.7.5.
email me and I will send you the files.
Obviously there were no issues when I manually did the compression(but I am not doing that again took hours), the issue with WB and HTML Guardian are similar yet different.
IMHO, this is an important aspect to consider seriously by virtue that with html5 and CSS3 usage is ever increasing one issue that I've identified was that by virtue of the compression any space was eliminated even if it is present in the defined declaration of a property/attribute.
(ie.) .myform show
<code>
form#myform .opt{color:#b4eeb4;font-size:12px;font-weight:bold;}
</code>
the space between form#myform .opt is removed resulting to form#myform.opt being totally different and this is where I had originally observed the issue prior to my asking in this forum.
In so far as to the CSS3 declaration, I truly wish the different venders get off their butts and not place their individualistic name for properties etc.
(ie) -moz, -webkit, -o etc.
In working with WB 2010 and using html5 I found it problematic and often spend considerable time troubleshooting only to find that I had made syntactic error by not closing the tag and thereby leaving a so called 'dangling' tag (ie) <article> wasn't closed.
I truly hope that with WB 2011 that there will be an automatic tag opening and closing issued and/or check made, it would certainly help. Another thing that I've uncovered in converting my web site from flash to html5 was the spelling mistakes I had made and yet the html5 worked. Just look at the code on my web site to see what I mean
For instance, one error that I had made was <artic> </article> logically that should generate an error BUT it didn't. Some-sort of spell-check should also be present in WB 2011.
Believe me that using html5, it is a living document and therefore, I highly recommend that Blumental create on this forum a separate section for html5 by virtue of the support provided by the different browsers and there will be an avalanche of queries relating to html5 forthcoming when WB 2011 is releasing.
I personally dont mind waiting a longer period of time for the release of WB 2011 knowing that it will support html5.
Gee, did I ramble on..I am known to write lengthy replies
mapleleaf