CSS compression issues

Discuss general web development questions. Help others and get help from others.

Moderator: kfury77

Re: CSS compression issues

Postby mapleleaf » Mon Mar 14, 2011 9:06 pm

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 :D

mapleleaf
User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby mapleleaf » Mon Mar 14, 2011 10:28 pm

Hi Gatis

Gatis wrote:Can you please verify if the following file makes the compression result acceptable:
http://fileshar.es/Bb67ZaL

To use the file, make a back-up of your current file C:\Program Files\WeBuilder 2010\data\csscompress.ini and then replace it with the one above.

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.




Ok, I've d/l that file and made some tests

1. took my compress css file a size of 13K being in length of JUST 1 line and used the 'format' aspect from WB
- the formatted file became 16K and I do like the formatting of WB however a comment that I wish to make is the the space after the : isnt really needed
<code>
.menubar{
position: relative;
width: 980px;
height: 45px;
margin: 0 auto;
padding: 0;
}
</code>

This also works
<code>
.menubar{
position:relative;
width:980px;
height:45px;
margin:0 auto;
padding:0;
}
</code>

But my personal preference is
<code>
.menubar {position:relative;width:980px;height:45px;margin:0 auto; padding:0;}
</code>

- the re-formatted css file became 872 lines with a size of 16K
- I did notice an issue with the re-formatted file which I corrected which related to the reset of the CSS properties at the beginning of the CSS file.

2. I then used the WB CSS compression with the ini file that you'd sent me and applied CSS compression to the re-formatted CSS file
- files size dropped from 16K to 13K a compression saving(reduction) of approx. 18.75%
- no issues were so far found with CSS3
- the number of lines dropped to 132 lines

3. I then applied the compression from HTML Guardian which then created a CSS file with only 1 line with a file size of 13K
- IMHO a 1line CSS file is more efficient than a 132 line CSS file since the computer is a creature that read left to right and then top to bottom and thereby
it will read a 1 line file more efficiently but both are OK only drawback to a 1 line CSS file is that it is difficult to edit when changes are required or needed

I'll add the newly created compressed file to the whole of my web site(locally) and give it a "full blown" test. OK?

Hope this perhaps answers your thoughts in part

mapleleaf
User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby mapleleaf » Wed Mar 16, 2011 2:22 am

Gatis

So far, I havent come across any issues with the ini file that you provided. It did make a significant change and I like it.

We all know that the purpose of compression is two-fold:
1. reduce the file size
2. speed-up the display a web page as the perception by a visitor to a web site in this case is critical and should be foremost in web development
- a slow web site is certain death; the visitor will leave
- if the display in speed meets the perception by the visitor then it goes to the next level namely ease of navigation

I am making here an assumption and assuming that the visitor's internet connectivity is optimized particularly the TCP/IP receive window, if set incorrectly then that will be a big factor in the visitor's reception of speed in display of a web page.

One of the last factors that I execute or perform when placing a web page online is web optimization and wherever possible reduce
a. http calls (ie. CSS sprites)
b. file size (ie. compression)

One thing that I've noticed when looking at the result of the compression is perhaps a mute point but noticable and a possible contributory factor in the file size namely the ; prior to the closing }

In this case, the result of compression was 132 lines from 879 lines, excellent.

But each compressed line had just prior to the closing } a ; this ; is in fact not required since the ; in a single line CSS statement acts purely as a seperator and therefore in this case isnt needed resulting in 132 bytes being used for nothing.

This is something that Blumental should consider when compression is applied via the WB; remove the last ; prior to the closing }

Some may say that this is going overboard but it can/may play a factor when a CSS file is large BUT in the final analysis any savings in bytes is a plus.

Here is a link that you may be interested in when testing for a web site optimization which should be the very last step in the web development process.

http://www.websiteoptimization.com/services/analyze/

I use this and have for years, although somewhat antiquated it still is a useful tool when used to analyze a web site.


mapleleaf
User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby Gatis » Wed Mar 16, 2011 11:39 am

Hi mapleleaf!

Thanks for all the information.

But my personal preference is

When using the CSS formatter, you can change the rules applied. The CSS will be formatted in one line, if you enable the option "Single Line" under tab "Rules".

2. I then used the WB CSS compression with the ini file that you'd sent me and applied CSS compression to the re-formatted CSS file
- files size dropped from 16K to 13K a compression saving(reduction) of approx. 18.75%
- no issues were so far found with CSS3
- the number of lines dropped to 132 lines
This is strange, because the compressor settings I gave you (and also the ones shipped with WeBuilder) should format the CSS in one line (at least that is what it does here). Are your rules embedded in HTML, or is it a plain text file..?
This is something that Blumental should consider when compression is applied via the WB; remove the last ; prior to the closing }
Thanks for pointing this out. The new compressor.ini now removes the last semicolon which is not needed. You can download the latest version from here:
http://fileshar.es/Nj49DiH

Kind regards,
Gatis
Kind regards,
Gatis Avots
Gatis
Blumentals Software Developer
 
Posts: 545
Joined: Sun Mar 05, 2006 12:30 am
Location: Latvia

Re: CSS compression issues

Postby mapleleaf » Wed Mar 16, 2011 1:00 pm

Hi Gatis

This is strange, because the compressor settings I gave you (and also the ones shipped with WeBuilder) should format the CSS in one line (at least that is what it does here). Are your rules embedded in HTML, or is it a plain text file..?


Perhaps I am guilty of not clarifying myself as I often write what I think. You misunderstood. :!:

I implied that the CSS was 1 line there isn't any other way where it could go from 879 lines to 132 lines. Yes, I am aware that one is able to change the setting to 1line for the CSS and this is what I have done.

I am happy with what the WB compression did no complaints from me, in fact I am overall more than happy with WB having stumbled upon WB last October.
I'd love to get my hands on a beta copy to play with it and check my html5 coding. :D

Ok great will d/l it. Thanks

I did it simply the other way. Loaded the newly created CSS file into WB then did a search/replace of the ;} in the CSS file
searching for ;} and replacing it with }, easy right?

I then spent considerable time implementing the new CSS to all of my web pages for my web site and along the way corrected any errors that I had missed, enhanced the html5 and added a couple more pages.

feel free to visit http://www.mirana.net (btw, I've added videos to my photo gallery) and have a peek, each page validates in html5 from three different sources but have a peek at my 3D video cube in the multimedia section which may interest you.(currently only work for/with FF3.6 but hopefully soon when they correct the bug in the Gecko 2 engine) you can however with FF4.0 you can view the videos in/on the cube in full screen if you right click on the black faces and then select full screen. I am now working on enhancing the 3D video cube so that there is rotation present and you'll be able to rotate the cube. mathematically I've done this but cant really apply anything until Mozilla Org solves the bug in the Gecko 2 engine.


mapleleaf

User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby mapleleaf » Wed Mar 16, 2011 1:18 pm


Hi Gatis

You can download the latest version from here:


Ok, d/l the used it and it works perfectly

mapleleaf

User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby mapleleaf » Tue Mar 29, 2011 5:22 am


This may be a bit off-topic but it is related

IMHO, the same would also apply when formatting CSS code in that the last ; of the listing isnt required.

(ie) as in below there is no need to have a ; with the line z-index:1. Also notice, the absence of the space after the :, in reality the space isn't needed as well for the : serves only as a delimiter between the parameter and its value.


#source-code {
display:none;
position:absolute;
top:0;
left:0;
width:100%;
height:100%;
background:rgba(225, 233, 255, 0.3);
z-index: 1
}

User avatar
mapleleaf
 
Posts: 121
Joined: Thu Oct 14, 2010 2:21 am
Location: Ashcroft, BC Canada

Re: CSS compression issues

Postby Gatis » Tue Mar 29, 2011 8:58 am

Hi!

The compressor will remove any spaces before/after ":". Also the semicolon after last line is not added if option is enabled for this.
Not only compressor, but also the CSS formatter is capable of doing all that, you just need to apply the correct settings (let me know, if you need to know which).
The default formatting settings are enabled so, that the code looks "prettier", but not necessarily more compact.

Kind regards,
Gatis
Kind regards,
Gatis Avots
Gatis
Blumentals Software Developer
 
Posts: 545
Joined: Sun Mar 05, 2006 12:30 am
Location: Latvia

Previous

Return to Web Developer Talk

Who is online

Users browsing this forum: No registered users and 1 guest

cron