Against Fx - CSS namespaces

[Ben Clinkinbeard]

CSS namespaces are the first argument given in support of prefixing on
Deepa's blog (http://iamdeepa.com/blog/?p=34). Only arguments against
the prefix that address this issue (or perhaps any related CSS issues)
should be included in this thread. I have copied the related argument
from Deepa below.


1.CSS namespaces
We would have had to have introduced namespaces in CSS in order to
distinguish styles applied to a Halo component vs a Gumbo component
(since type selectors use the leaf name of an MXML tag). Introducing
namespaces in CSS is a beast – very tricky for the compiler and the
tools. Developers would have needed a new CSS syntax to target styles
for sets of components based on the namespace of the component set.
This would have required updating the internal CSS parser to be aware
of CSS namespace syntax, at least for element selectors, as well as
updating the Flex compiler to track style namespaces. Additionally,
support would have to be added such that Flex styles could, at
runtime, be updated to handle namespaces. Even if all of this work was
undertaken, other issues crop up. Since CSS does not support packages,
if we tried using packaging to distinguish styles applied to a Halo
button vs styles we want applied to a Gumbo button, like so:

mx.controls.Button
{
}

flex.components.Button
{
}

we would still be out of luck because dots (.) in CSS have pre-
existing meaning. And, if we did add CSS namespace support, migrating
pre-Gumbo code to Gumbo would be more difficult, something we try to
avoid when possible. Additionally, there is an inherent trickiness
with avoiding code bloat when depending on namespaces to control style
inclusions. Because of naming collisions, you’re almost guaranteed to
bloat your SWFs due to styles for one component being pulled in even
if that component wasn’t in use in your application.

[Simeon Bateman]

Ok, So I just put this really simple example together and we can build
on it if we like.

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://ns.adobe.com/mxml/2009"
xmlns:mx="library:adobe/flex/halo" xmlns:fx="library:adobe/flex/
gumbo" skinClass="mx.skins.spark.ApplicationSkin">

<Style>
Button {
color: white;
skinClass: ClassReference('mx.skins.spark.ButtonSkin');
}
</Style>

<layout>
<VerticalLayout />
</layout>

<fx:Button label="fx button" />
<mx:Button label="test halo button"/>
</Application>


I just posted the compiled swf is posted in the Files section. This
is compiled using the codebase I call Ply (provide: give what is
desired or needed. http://www.google.com/search?client=safari&rls=en-us&q=define:ply&ie=UTF-8&oe=UTF-8)
Ply is my fork of the flex framework where I fixed the file naming and
added back the original manifest files. I left my laptop in the car,
but once my wife comes home I will put the code on s3 so anyone here
can grab it if they want it. Or if anyone here is a git user I can
pass along the url.

Anyhow, What you can see above is using type selector to style both
the gumbo and halo buttons. Styles that are shared are applied to
both, styles that are not are ignored by halo.

But from this we can build a good example that shows that the name
changes are stupid.

Thanks,
sim

[Tom Chiverton]

2009/2/2 Ben Clinkinbeard <ben.clin...@gmail.com>:

> We would have had to have introduced namespaces in CSS in order to
> distinguish styles applied to a Halo component vs a Gumbo component

No, you wouldn't. Just don't touch anything.
Developers who need to can use styleName.

Mixing Flex 3 and 4 is very very rare, I imagine, so let's not stress
too much about making it Just Work. As long as it can be made to work,
with little fuss, it's worth a bit of pain here.

--
Tom

[Simeon Bateman]

Just in case anyone actually wanted to try some of this stuff here is
the Ply build.

http://s3.amazonaws.com/ply-framework/ply_4783.zip

Just set it up as an available sdk in eclipse, then set your project
to use it as the compiler.

sim