I work for Opera Software in the Dev Relations team. I use Espresso quite a bit, and one issue I’ve had with the CSS sugar is the lack of some of the latest CSS properties.

I’m new to Sugars but I’m looking into extending the default CSS Sugar. I’ve currently added all the CSS3 that Opera supports, plus the -o- properties (Espresso currently only supports some -webkit- and -moz- properties). I’ve also added the CSS properties from SVG, and the -xv- (CSS Voice) and -wap-. I’ve just done this in the MacRabbit namespace by extending the current Sugar as advised on the Wiki.

Would MacRabbit be interested in perhaps including the extended sugar in a future build of Espresso? If so I can probably extend it to include and Mozilla or WebKit features that are missing, along with their vendor prefixed features. There are some specific Opera features I’ve added that we use to be able to support MathML via CSS (such as -o-table-baseline) that I should probably remove if so.

If it is just something that we can distribute to developers that use Espresso that care about the properties that Opera supports, would you suggest changing the namespace of the new (or also existing) properties to a Opera namespace, and perhaps changing the name, so that any future Espresso update doesn’t override it?

Eventually after I learn more about how Sugars work, I’d like to add a Sugar for the Widgets packaging spec (config.xml), HTML5, and SVG. As XML is part of the HTML sugar, would you recommend extending the HMTL+XML sugar, or writing a separate SVG sugar? SVG isn’t too different to XHTML, in that you can have a style element with CSS rules in or CSS rules in a style attribute.

Hey David,

Welcome to the forums and sugar development!

David Storey - 25 March 2010 04:17 PM

Would MacRabbit be interested in perhaps including the extended sugar in a future build of Espresso?

Jan’s got final say, but I imagine he would be more than happy to include a version of the CSS.sugar that includes a more comprehensive selection of properties.  For a version that would replace the CSS.sugar included with the app, we’d want to stick to the properties that aren’t too vendor-specific.  In the examples you’ve given, things like -moz-border-radius and so forth that are part of the CSS spec but still have vendor-specific names would be really helpful, while Opera-specific properties for dealing with MathML would probably be beyond the scope of the basic sugar.

However, that isn’t to say that you can’t easily extend Espresso’s CSS to include Opera-specific CSS properties, and you don’t have to modify the bundled CSS.sugar to do it.  Espresso supports syntax injections, which are pretty much what they sound like: you can code a completely separate sugar and tell it to inject or override rules included in the bundled CSS.sugar.  You can find more information about syntax injections in the wiki (near the bottom of the page):

http://wiki.macrabbit.com/index/Syntaxes/

My suggestion would be to send us any general-use improvements you think would benefit the bundled CSS.sugar (use Help->Send Feedback), and then construct a third party sugar that people who use Opera properties or whatever can download and install to further extend the CSS support.  This is also what I’d recommend for SVG (and possibly HTML5, although that might fit in the HTML+XML.sugar a bit better; I’d need to ping Jan to see what he thinks about that one).

Cool. I’ll look into tidying up what I have right now, and remove the Opera specific things. I can add the -webkit- and -moz- versions of transitions and transforms to go with the Opera versions.

I’ll look into the syntax injections again for the specific things.

Please let us know how this is going a long, I’d love to have better multi-platform integration in Espresso

I am also very interested in an enhanced CSS3 sugar.

Sorry guys completely forgot about this topic. I didn’t change the CSS sugar after all, what did was a bunch of snippets that make it really easy to set properties and values that are cross-browser compatible. I’ll leave you with the two I use the most, and I think you can then take it from there:

The syntax is $ marks a tab point, and inside the brackets we have two numbers, the first one is the tab number, so if you use the snippet, you will be on tab point 1, if you press tab you move to tab point 2, and so on. The second number is the default value. Don’t forget to put the measurement of the values you want to tweak outside of the brackets, like in the second example.