Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Weird symbol on java applet windows  (Read 11840 times)
0 Members and 1 Guest are viewing this topic.
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Posted 2008-12-09 14:04:21 »


Why am I getting a yellow warning sign AND a blue border around my applet windows?
it started since update 10 I think

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #1 - Posted 2008-12-09 14:46:12 »

its a feature Wink

I think it is a replacement for the old "Java Applet Window" border on the botton of the window. Whats actually really anoying is, you can't maximize the window anymore (even with signed applets..). There will be always the gap fo r the icon. I already filed a bug a few month ago which has been closed almost instantly after i filed it.

Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #2 - Posted 2008-12-09 14:57:22 »

its a shit feature - now I have to explain world + dog why they have a yellow triangle attached on the right side of a window.
Damn it - why do applets and java have to be so broken to actually supply to customers Sad

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SimonH
« Reply #3 - Posted 2008-12-09 14:58:32 »

why do applets and java have to be so broken to actually supply to customers
even with signed applets..
I don't think Sun loves us anymore...  Cry

People make games and games make people
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2008-12-09 18:32:06 »

It's also annoying that the 'contentpane border' is BLINKING YELLOW the first second it gets focus! If you mess with lots of modal dialogs in your applet (well... at least I do), both the created dialog and upon closing, the 'parent' will BLINK!



Dear customer,

My applet is dangerous, it has windows, which may confuse you.
It blinks all borders as a clear warning to you.
We'd prefer a fullscreen shroud, like Vista security popups, and play a sound.
As we like to say, a sad customer is better than a hacked customer.

Enjoy shopping!




I think I'm going to window.alert() this message on the frontpage.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2008-12-09 18:35:40 »

Quote
There will be always the gap fo r the icon. I already filed a bug a few month ago which has been closed almost instantly after i filed it.

Really? Have you tried it recently?

Dmitri
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #6 - Posted 2008-12-09 19:21:21 »

just tested with u11, same issue like in past with u10 ea. At least the "draggable applet restart from desktop" issue is fixed now in u11.

here is a testapp (i noticed it hits from time to time a deadlock... its only for debuging anyway):
https://fishfarm.dev.java.net/demo/

If you drag and maximize you you should see a gap on the right side of the screen.

(tested on win xp)

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #7 - Posted 2008-12-09 19:31:16 »

It's also annoying that the 'contentpane border' is BLINKING YELLOW the first second it gets focus!
thats nothing - the early access versions kept it fleshing for around 5 seconds ;-).

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2008-12-09 20:20:48 »

This has got to stop.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2008-12-09 20:23:08 »

thats nothing - the early access versions kept it fleshing for around 5 seconds ;-).

Ah, then it's OK. persecutioncomplex Wink

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #10 - Posted 2008-12-09 22:39:27 »

just tested with u11, same issue like in past with u10 ea. At least the "draggable applet restart from desktop" issue is fixed now in u11.

here is a testapp (i noticed it hits from time to time a deadlock... its only for debuging anyway):
https://fishfarm.dev.java.net/demo/

If you drag and maximize you you should see a gap on the right side of the screen.

(tested on win xp)

OK, I see. This will be fixed in 6u12 (to be released early next year). The flashing border goes away, and the warning icon will only be shown on "active" window.

Dmitri
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #11 - Posted 2008-12-10 00:07:20 »

The flashing border goes away, and the warning icon will only be shown on "active" window.
WHY WHY WHY!!
Whats the point of punishing people that actually want to USE the platform.

What INSANE person thought it was a GOOD idea to add a f* warning icon on a window?Huh?

Do you know how many support requests we get because of an ODD looking Icon???

Sheesh, its like you want people to use flash instead.

Offline jezek2
« Reply #12 - Posted 2008-12-10 00:31:18 »

I fully agree with Matzon. This security banner is pointless. There are many ways how to forge some system dialog asking for password/etc. Just some image based web can do that with imitation of common OS themes. IE can do fullscreen without problem, etc. Most of people uses default themes of few OS out there... So, please get rid of it. It just complicates our lives for correct usage.

Next issue is with unsigned/signed applets/webstart apps. You either can do very little, or you must have all privileges. Which is very wrong to ask the user, if the app just need for example: fullscreen mode, mic support, file access (at least the last is fixed with JRE 6u10 by allowing JNLP services in applets too). All these things can be done by asking user before first usage (and not before app runs) without exposing bigger risks such as full filesystem access.
Offline DzzD
« Reply #13 - Posted 2008-12-10 00:43:40 »

Quote
IE can do fullscreen without problem, etc
nope, you can only with very old version maybe (5.5 and earlier), you cant with 6.0+, user have to press F11 for real fullscreen, website cannot force it.

Quote
Most of people uses default themes of few OS out there... So, please get rid of it. It just complicates our lives for correct usage.
the way it go is more that browser security are higher every day (less freedom ofcourse)

Quote
Next issue is with unsigned/signed applets/webstart apps. You either can do very little, or you must have all privileges. Which is very wrong to ask the user, if the app just need for example: fullscreen mode, mic support,

using micro or fullscreen in flash warn the visitor too and that's a good thing no ?, flash just better know how to make those things look smoother and more natural.

Offline jezek2
« Reply #14 - Posted 2008-12-10 00:58:09 »

nope, you can only with very old version maybe (5.5 and earlier), you cant with 6.0+, user have to press F11 for real fullscreen, website cannot force it.
the way it go is more that browser security are higher every day (less freedom ofcourse)

Sorry didn't recheck that lately, thanks for information.

using micro or fullscreen in flash warn the visitor too and that's a good thing no ?, flash just better know how to make those things look smoother and more natural.

Yes, but notice the important details, that a) users get informed what function app needs, b) app get access to just that function and not whole system... compare to Java where there is scary security dialog with certificate. I don't have anything against that dialog, it's very ok when you need some special stuff for example... but not for common tasks. It's just not right to see too many applets that requires full privileges just for some common thing.
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #15 - Posted 2008-12-10 05:01:18 »

just tested with u11, same issue like in past with u10 ea. At least the "draggable applet restart from desktop" issue is fixed now in u11.

here is a testapp (i noticed it hits from time to time a deadlock... its only for debuging anyway):
https://fishfarm.dev.java.net/demo/

If you drag and maximize you you should see a gap on the right side of the screen.

(tested on win xp)

If you initiate a 'Click & drag' when the browser window is being displayed on anything but the primary display device, it completely stops repainting your window.
You have to drag the window onto your primary screen for the repainting to start working again  Grin

Also, when you first initiate the Click & drag op (click/drag but dont release), the window dragging appears to be broken. It's hard to determine exactly what is interferring with the dragging.
I have to drag/release/redrag for the window to have full freedom of movement across the desktop.

Anyone else experiencing similar behaviour? (this is all with u11 in FF)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #16 - Posted 2008-12-10 08:29:44 »

maybe fishfarm is not the best example for demonstrating applets (it does a lot in background) but i think both issues you found are valid.

If you initiate a 'Click & drag' when the browser window is being displayed on anything but the primary display device, it completely stops repainting your window.
You have to drag the window onto your primary screen for the repainting to start working again  Grin
interresting, i have a dual head setup too - never saw this behavior. I remember once it wasn't possible to drag the applet out of the main screen at all Wink but i am not sure it it was windows or linux.

Also, when you first initiate the Click & drag op (click/drag but dont release), the window dragging appears to be broken. It's hard to determine exactly what is interferring with the dragging.
I have to drag/release/redrag for the window to have full freedom of movement across the desktop.

Anyone else experiencing similar behaviour? (this is all with u11 in FF)
you should see similar behavior with the javafx samples. Something happens behind the scenes if you release the mouse the first time difficult to say what.

Just by building this app i filed around 5 bugs regarding the draggable applet against u10 ea releases. I had the feeling that the draggable applet feature wasn't tested internally at all. It looked for me like the draggable applet was initially never intended to go for production and stay a proof of concept.... well the rest of the storry is marketing.

(technically: what is the best unit test for the out-of-proccess applet? -> make it draggable)

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #17 - Posted 2008-12-10 18:53:56 »

Getting back to the security warning thing.

So what would you like to see? What's the scenario you'd like your users to go through?

For the following cases:
  - unsigned applet (doesn't go full screen, or even maximize window)
  - signed applet which attempts to execute some privileged operation

We're discussing changes that could be made (probably in jdk7 time frame) so now
would be a good time to speak up (but be reasonable)..

Ideally, I'd like to see no warning for unsigned applet unless it gets maximized.

The problem is, of course, that showing a window is already a privileged operation
in some sense. It didn't make sense to disallow it for unsigned applets, so they put a
warning on it instead.

The only reason I heard of for having the warning banner is to avoid spoofing -
presenting a user with a false page and leading them into entering their info or
something.
It would seem that if someone managed to stick a malicious applet onto a
page you'll have bigger things to worry about, so may be this should be reconsidered.

For signed apps, there should be a way to specify exactly which privileged operations it is
intended to perform, and perhaps ask the user to allow/deny particular operations.

It would probably need to be done before the applet is started instead of when the operation
is about to be performed.

Any other ideas/comments?

Dmitri
Offline irreversible_kev

Junior Member





« Reply #18 - Posted 2008-12-10 19:12:17 »

It would probably need to be done before the applet is started instead of when the operation
is about to be performed.

Here ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.
Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.

It would be nice if it could say somthing like :

"Would you like to let this applet access your mouse?"  <== ie Robot class

"Reason : <PROGRAMMERS-REASON>"

where <PROGRAMMERS-REASON> = "To enable the easier to use first person shooter mouse control."

This example might look a bit ugly but to be honest its already ugly in the sense that it is scary.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #19 - Posted 2008-12-10 19:13:57 »

In the short term, I'm told that there's an internal API (in com.sun....) which allows the developer to control where the warning icon is placed (within window bounds, and it's guaranteed to be visible).

So you could place it in the title bar, for example, so it's less prominent. Not much help for undecorated windows though.

Dmitri
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #20 - Posted 2008-12-10 19:26:59 »

It would probably need to be done before the applet is started instead of when the operation
is about to be performed.

(the following on a purely theoretical level, ignoring pesky technical issues)

Does it really make sense to put the allow/deny queries before the app has even started? This is exactly the kind of clunky user-unfriendly experience which people have grown to hate about existing applet/webstart security model. At the point where the user is asked to make a decision they don't know what they're granting permissions for - they don't have enough data to make an informed decision. IMHO they should be asked when the app actually tries to use the functionality, when they know the context it'll be used in.

Example:
- user goes to webpage
- applet loads, security dialog says "grant access to printer? y/n"
- user gets scared, says no, or just navigates away completely.
vs.
- user goes to webpage
- applet starts up, user happily clicks around, paints pretty picture
- user clicks "print"
- security dialog "grant access to printer?"
- user is fine with dialog, since they initiated the whole process, clicks yes

The important thing about the above is that the average case of the user who turns up, makes a bit of a picture but doesn't want to print it never sees a scary security dialog.

Asking at start up makes even less sense when an app wants multiple permissions. If you load an applet and the first thing it asks is "grant access to hard drive", "grant access to network", "grant access to printer", "grant access to bank account" then they're going to run a mile. But if permissions are asked individually as required by the app then it's generally a much smoother and less scary experience.

As a side bonus, if you ask the user and they refuse then app code can catch the security exception (or similar) and provide a helpful message to the user ("We noticed you refused access to the hard drive. This means your preferences won't be stored"). Again this reduces scariness and makes the experience smoother without compromising security.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #21 - Posted 2008-12-10 19:45:35 »

Here ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.
Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.

Nice.  How does it do that? Reload a signed version of the applet or something?

Quote
It would be nice if it could say somthing like :

"Would you like to let this applet access your mouse?"  <== ie Robot class

"Reason : <PROGRAMMERS-REASON>"

where <PROGRAMMERS-REASON> = "To enable the easier to use first person shooter mouse control."

This example might look a bit ugly but to be honest its already ugly in the sense that it is scary.

Yes, that's the general idea. Not sure about programmers-reason thing, one can
give a reason like "give me this permission and you'll be rich!" =)

Basically, I think there would be a known list of permissions (which already exists, but
only the client can control that through the policy file) that app can request, and if apps needs a
specific permission, it can request it in some way (during packaging, probably).

When such applet is loaded, user will be presented with a dialog listing requested
permissions.

Dmitri
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #22 - Posted 2008-12-10 19:46:37 »

I agree with the replies, in that we need this granular access (I think it already exists in applets - or at least I seem to remember back in the old days).

But from my point of view, there are two groups of application those that can run with as little permission as possible and those that need permission.
Adding the granular access makes this better for the group that needs the access. However for the rest of the applets/jws applications that run with basic permission, are already sandboxed. So no need to warn the user about _any_ _thing_. No 'Warning: Applet Window' or Yellow exclamation mark - whats the point? I could just have well opened a browser window with an applet in it - instead of an applet window.
Fortunately, you fixed the remote connection from applets in update 10. Should have been done *years* ago - but it is here now - just have to wait ~ 5 years for people to upgrade.

Witness the JavaFX mess with native components that required a user to accept a SECURITY: DANGER! DANGER! dialoge before they watched a video stream.

Flash - although it has issues also - has a LOT better user experience, and we need that same 'feel' when launching our applets or jws.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #23 - Posted 2008-12-10 19:51:13 »

(the following on a purely theoretical level, ignoring pesky technical issues)

Does it really make sense to put the allow/deny queries before the app has even started? This is exactly the kind of clunky user-unfriendly experience which people have grown to hate about existing applet/webstart security model. At the point where the user is asked to make a decision they don't know what they're granting permissions for - they don't have enough data to make an informed decision. IMHO they should be asked when the app actually tries to use the functionality, when they know the context it'll be used in.

Example:
- user goes to webpage
- applet loads, security dialog says "grant access to printer? y/n"
- user gets scared, says no, or just navigates away completely.
vs.
- user goes to webpage
- applet starts up, user happily clicks around, paints pretty picture
- user clicks "print"
- security dialog "grant access to printer?"
- user is fine with dialog, since they initiated the whole process, clicks yes

The important thing about the above is that the average case of the user who turns up, makes a bit of a picture but doesn't want to print it never sees a scary security dialog.

Asking at start up makes even less sense when an app wants multiple permissions. If you load an applet and the first thing it asks is "grant access to hard drive", "grant access to network", "grant access to printer", "grant access to bank account" then they're going to run a mile. But if permissions are asked individually as required by the app then it's generally a much smoother and less scary experience.

As a side bonus, if you ask the user and they refuse then app code can catch the security exception (or similar) and provide a helpful message to the user ("We noticed you refused access to the hard drive. This means your preferences won't be stored"). Again this reduces scariness and makes the experience smoother without compromising security.


Yes, that makes sense.

Dmitri
Offline DzzD
« Reply #24 - Posted 2008-12-10 21:00:54 »

Quote
Quote from: irreversible_kev on Today at 10:12:17 AM
Here ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.
Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.


Nice.  How does it do that? Reload a signed version of the applet or something?

nop, it works the same (with some improvment) way as the hardware switch (H key)


- This method was initied a long time ago by Thijs and me. It is probably at the origin of "working" JOGL applet and JOGLAppletLauncher ..... not mentionned anywhere  Lips Sealed...

http://www.java-gaming.org/topics/jogl-in-applet/16911/msg/132800/view.html#msg132800

http://www.java-gaming.org/topics/jogl-in-applet/16911/msg/134132/view.html#msg134132

the idea behind is to request right to a loader and use this loader to perform remote or local privileged package/class loading at runtime.

In this sample there is no "break" on the game : for example hardware switch or mouse control switch is done at runtime and loading (for hardware) use streaming no game lock. the applet remain the same and only few class get privileged right


scenario could be for example :

=> in applet :
getPrivilegedClassInstance(Robot)
=> sun dialog asking if user want to allow mouse and screen access
trows RefusedPrivilegedClassException
or
return new Robot


Offline bienator

Senior Member




OutOfCoffeeException


« Reply #25 - Posted 2008-12-10 21:19:01 »

I agree, on demand security permission dialogs are probably the best solution but there should be also a checkbox like "don't ask me again for this application" for the users which think to know what they are doing.

Maybe it would be even possible to open a dialog right after JRE has been installed which allows the user to opt in some options like "always allow media" or "always allow hardware acceleration" which can be of course only done for official sun libs (e.g javafx stuff).

The only question remains what to do with libs like LWJGL? I really don't know. A similar approach is possible per library or certificate but i am not sure if it is already to complicated for the average user.

But why not start with the easy things first Wink? A nicer looking security dialog could be rendered undecorated on top of the applet and scroll with the page instead of the ugly window... There is currently also a default behavior missing which defines what happens if the user does not agree with the security permission. Something like "application canceled by user click here to reload applet" would be IMO sufficient for applets.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2008-12-10 21:27:14 »

I just think the whole security thing completely lost its focus on the use cases.

I believe that a signed applet should be granted any and all permissions automatically by default by a standard Java install unless revoked by a user.

<edit>That is, signed by a root CA, not self-signed.

Cas Smiley

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #27 - Posted 2008-12-10 21:38:18 »

> I believe that a signed applet should be granted any and all permissions automatically by default by a standard Java install unless revoked by a user.

You mean, without the security dialog?

Dmitri
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #28 - Posted 2008-12-10 22:18:29 »

signed applets should behave exactly like a non-singed applet - until it tries to do something that requires access. Then the dialog shown will also contain some info about the application being signed. Of course, one can execute someking of grant-<permissions>-permission-thingy in the start of an application to get it over with, so to speak.

Signed applets should NOT be alllowed to run - unless I have allowed it. The potential for a CA to give someone a cert is too high.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2008-12-10 22:58:06 »

Yes, I mean without any security dialog.

A signed applet isn't in the least bit safe - it can do anything. People seem to be getting all confused about what signing actually does. It doesn't make anything safe. It just means you can guarantee that the code hasn't been tampered with since whoever it was signed it did the signing.

The fact is if you're worried about websites that put up malicious keylogging applets or screen spoofers or hard-drive bashers... then somebody somewhere has to sign those applets and that those somebodies will be therefore traceable. So those sorts of applets will exist in the sorts of places where people who are Good Citizens in the first place aren't going to be going to.

Matzon has big paranoia about applets being allowed to run if signed when he hasn't explicitly allowed it - but I bet you he's perfectly happy to download a .exe installer and install anything on his hard drive at face value. That's where it all breaks down. People already are entirely happy to compromise their own security by clicking "yes" when they want to run something when they honestly have no idea what it's really doing.

I realise this probably puts me firmly in the firing line for every security pundit and paranoid netizen floating around here but you have to ask yourselves - what really are the advantages of the scary dialog? What are the advantages given users actual behaviour? How might you get rid of the security dialog if you wanted to but if you're paranoid ensure that it comes back? So I say: remove it by default for signed code, and allow power users to turn it back on. Sod the granularity stuff, they'll take bloody years putting that into the JRE. You know what Sun are like.

I now don my flameproof underpants and await your roastings.

Cas Smiley

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (38 views)
2014-04-15 18:08:23

BurntPizza (34 views)
2014-04-15 03:46:01

UprightPath (50 views)
2014-04-14 17:39:50

UprightPath (32 views)
2014-04-14 17:35:47

Porlus (49 views)
2014-04-14 15:48:38

tom_mai78101 (71 views)
2014-04-10 04:04:31

BurntPizza (130 views)
2014-04-08 23:06:04

tom_mai78101 (230 views)
2014-04-05 13:34:39

trollwarrior1 (193 views)
2014-04-04 12:06:45

CJLetsGame (201 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!