whacky idea: CSS compiling?

[Reinier Zwitserloot]

Alex Russell of Dojo has written a nice post flaming CSS3 into the
ground here: http://alex.dojotoolkit.org/?p=625 but there's a
hypothetical CSS sample in there that simple allows you to 'import'
another CSS rule. The main thesis of the rant is that CSS2 should have
had that, but didn't, and CSS3 doesn't either, which means that CSS3
developers are apparently not in touch with what the web developers in
the trenches really want.

Aside from Alex' endorsement, I would definitely like such a feature
myself as well. Then there's the issue of 'compiling in' the use of
ImageBundle images into background-image, which i think can be done
with the right fiddling of background offsets. I know I can make that
work in safari, but haven't tested on all browsers yet. At any rate,
if that is possible, this 'CSS compiler' would also be able to allow
you to add ImageBundles images into background-image properties, and
the compiler would replace it with the correct bundle png filename and
the correct background position properties to get the offset right.

Too far out there? Not gonna work? Good idea? What features other than
'refer to another definition' and 'allow background-image with
bundles' would be nice to have here?

[Scott Blum]

Hah, it's great to see someone is thinking along the same lines we are!  As a matter of fact, Bob Vawter has been working on a style bundle prototype which I think is in a usable state.  Maybe Bob can comment on its status.

Longer term, yes, we would like to have a real CSS compiler.  It could do a number of things such as:

- merge scattered CSS together
- sanity check for problems: syntax, semantics, portability
- read in "standard" CSS and make transformations to correctly target nonstandard browsers
- compress, of course

Longer term, we could even add extensions (like real inheritance) and let the compiler do the grunt work.

[Ray Cromwell]

This brings back old memories. In 2000-2001, I was Oracle's
representative on the W3C XForms Working group (I was also part of the
CSS-WG) At the time, I was implementing a server-side
translator/compiler to convert an offline XForms App (Google Gears
anyone? :) ) into WML+WMLScript, VoiceXML+VoiceXMLScript, XHTML
Mobile, and J2ME midlets. Unfortunately, we didn't have GWT back
then, so if you wanted to author some validation, event handling, or
computation code that could run on the client or on the server, XForms
was the best thing we had.

Nevertheless, the biggest issue we had was UI layout on mobile
devices, and many of the same CSS issues came up, especially the lack
of a grid layout, so we added one (display: _orcl-grid). Grid control
was important, since apps had to be authored for a dialog/response
style to support VoiceXML transformation, but then CSS was overlaid on
top of this with Media Queries to transform it into the appropriate
small form-factor screen. We also had to compile and translate CSS for
devices with varying degrees of capability (from bad/buggy to none).

Here's my two cents from that experience: Apache Batik is your friend.
I started out with just a SAC parser, but aborted it, because
implementing all of the CSS semantics is a massively huge PITA to get
right. But Apache Batik has already done most of the standards
compliant work, it just happens to be for SVG mostly.

You don't really need all of Batik, just the CSSEngine and CSSOM (W3C
CSS DOM) stuff. From there, you can introduce your own value types,
your own properties, and if brave enough, your own lexical syntax. I
found Batik invaluable for compiling down oodles of spreadsheets, and
generating either cascaded values or computed values. I'm still using
it today for Chronoscope server side rendering, as Chronoscope's
rendering style is controlled by CSS, and the server-side renderer
needs to be able to process it.

-Ray

[Reinier Zwitserloot]

Oh, heh, wasn't aware an effort was already on the rails for something
like this.

A way to bind CSS blocks to java files, or at least to the source tree
proper, also sounds like a nice feature. You could even add multiple
different CSS blocks, each with a different 'theme' name. Then, every
widget can carry its own style information, in multiple themes. GWT
would then come styled properly 'out of the box', instead of having to
rip a CSS file out of one of the samples.

Just tossing out ideas.

On Sep 20, 5:14 pm, "Scott Blum" <sco...@google.com> wrote:
> Hah, it's great to see someone is thinking along the same lines we are! As
> a matter of fact, Bob Vawter has been working on a style bundle prototype
> which I think is in a usable state. Maybe Bob can comment on its status.
>
> Longer term, yes, we would like to have a real CSS compiler. It could do a
> number of things such as:
>
> - merge scattered CSS together
> - sanity check for problems: syntax, semantics, portability
> - read in "standard" CSS and make transformations to correctly target
> nonstandard browsers
> - compress, of course
>
> Longer term, we could even add extensions (like real inheritance) and let
> the compiler do the grunt work.
>

> On 9/20/07, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
> > Alex Russell of Dojo has written a nice post flaming CSS3 into the

> > ground here:http://alex.dojotoolkit.org/?p=625but there's a

[Joel Webber]

On 9/20/07, Reinier Zwitserloot <rein...@gmail.com> wrote:

Oh, heh, wasn't aware an effort was already on the rails for something
like this.

A way to bind CSS blocks to java files, or at least to the source tree
proper, also sounds like a nice feature. You could even add multiple
different CSS blocks, each with a different 'theme' name. Then, every
widget can carry its own style information, in multiple themes. GWT
would then come styled properly 'out of the box', instead of having to
rip a CSS file out of one of the samples.

+1 to that. I think the prototype Bob's working on will bring us a lot closer to being able to apply compiler-like leverage to CSS problems. I'll let Bob talk about the details when he has it all worked out, but this will be a big win for a lot of reasons.

[BobV]

http://code.google.com/p/google-web-toolkit-incubator/wiki/ImmutableResourceBundle
http://code.google.com/p/google-web-toolkit-incubator/wiki/StyleInjector

I'm working on expanding the prototype with a proper SPI for making
new resource types pluggable. One can imagine a fully-integrated
StyleResource that's able to encapsulate many of the different
"compiled CSS" ideas that have been discussed.

My plan today is to port the ImageBundle optimizations to the
ResourceGenerator API to make sure that the API can handle resource
generation that requires a reduction phase.

--
Bob Vawter
Google Web Toolkit Team

[John]

I've been using a set of python scripts that someone else made; it
works well for simple things like importing CSS files and global
defines:

https://sourceforge.net/projects/switchcss/

-John

On Sep 20, 1:11 pm, BobV <b...@google.com> wrote:
> On 9/20/07, Joel Webber <j...@google.com> wrote:
>

> > On 9/20/07, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > A way to bind CSS blocks to java files, or at least to the source tree
> > > proper, also sounds like a nice feature. You could even add multiple
> > > different CSS blocks, each with a different 'theme' name. Then, every
> > > widget can carry its own style information, in multiple themes. GWT
> > > would then come styled properly 'out of the box', instead of having to
> > > rip a CSS file out of one of the samples.
>
> > +1 to that. I think the prototype Bob's working on will bring us a lot
> > closer to being able to apply compiler-like leverage to CSS problems. I'll
> > let Bob talk about the details when he has it all worked out, but this will
> > be a big win for a lot of reasons.
>

> http://code.google.com/p/google-web-toolkit-incubator/wiki/ImmutableR...http://code.google.com/p/google-web-toolkit-incubator/wiki/StyleInjector