Re: smarter css
Just a small note: you can reuse the provided processors (like LessCssProcessor, CoffeeScriptProcessor, SassCssProcessor, etc) without being forced to use a filter or a maven plugin. The processors interface is pretty simple and can be used like this: new CoffeeScriptProcessor().process(Reader reader, Writer writer); Similar usage is available for other processors and there are http://code.google.com/p/wro4j/wiki/AvailableProcessors plenty of them . Cheers, Alex -- View this message in context: http://tapestry.1045711.n5.nabble.com/smarter-css-tp5051068p5062698.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
I'm looking forward to integrating these! I think using the raw processor may fit into Tapestry's overall lifecycle best. On Fri, Dec 9, 2011 at 10:48 AM, Alex Objelean alex.objel...@gmail.com wrote: Just a small note: you can reuse the provided processors (like LessCssProcessor, CoffeeScriptProcessor, SassCssProcessor, etc) without being forced to use a filter or a maven plugin. The processors interface is pretty simple and can be used like this: new CoffeeScriptProcessor().process(Reader reader, Writer writer); Similar usage is available for other processors and there are http://code.google.com/p/wro4j/wiki/AvailableProcessors plenty of them . Cheers, Alex -- View this message in context: http://tapestry.1045711.n5.nabble.com/smarter-css-tp5051068p5062698.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
On Wed, 07 Dec 2011 23:08:28 -0200, Lenny Primak lpri...@hope.nyc.ny.us wrote: but doesn't it kinda have to be in the core so the core CSS can use it? I don't think so. :) It could be implemented as a separate package. It could be implemented by adding another dispatcher that picks requests to .less or .sass files. Or better yet, by decorating or overriding ResourceCache. This last option is actually used in a company package to implement CSS and JavaScript minification before Tapestry 5.3 provided it out-of-the-box. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
be ignored... be sure though that they are not understood or you might encounter a nasty surprise or two. In your example there should be no need for detection. Cheers, Peter - Original Message - From: Chris Collinschris...@me.com To: Tapestry usersusers@tapestry.apache.org Sent: Tuesday, 6 December, 2011 7:48:57 AM Subject: smarter css So when it comes to css3 is it really so ugly? Ok perhaps its just things like gradients: http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html So in the microsoft example above for getting a gradient background you have to use different css properties per browser. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Random thoughts: - You can't tml-ify css, if you could then you could condition parts of it by browser right? - Would you create a series of browser specific css assets then build inject them directly into the layout page? Clearly I don't have a clue :-} again sorry for dumb questions. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
That's a debate; for instance, tapestry-core could use SCSS and CoffeeScript, but use build-time tools to convert those into standard CSS and JS. Less convenient for use T5 developers though. On Wed, Dec 7, 2011 at 5:08 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: but doesn't it kinda have to be in the core so the core CSS can use it? On Dec 7, 2011, at 7:57 PM, Andreas Fink wrote: Please do not include this kind of technologies in the core. It took us long enough to get rid of prototype.js. Sure, it can be overridden but why not just offer it as part of an external CoolKidsJavascriptStack. Just my 2c. Andi. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
On Thu, 08 Dec 2011 12:31:35 -0200, Andreas Fink fink.a...@googlemail.com wrote: Sorry for my hasty and not well formulated rant. I was just thinking about the announcment of the Rails-team to switch to Coffeescript and what an impact that has on developers and existing apps. There is always that compromise between flexibility and high-level tools but as the server side of Tapestry focusses so much on flexibilty/modularity i think it would make sense to follow that route also for the browser side. In this case, it would be just an out-of-the-box support for a given package that wouldn't prevent support for other similar packages. In addition, it's quite probable that it would make it easier to add support for other similar packages. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Most of the support needed for Less and CoffeeScript is already present; the trick is finding a reliable Java-compatible library that can execute the necessary code transformations (which are generally written in Ruby or JavaScript). http://code.google.com/p/wro4j/wiki/Features looks promising, but is geared more for build-time conversions, rather than runtime. I just haven't had spare cycles to spare on this. On Thu, Dec 8, 2011 at 8:13 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Thu, 08 Dec 2011 12:31:35 -0200, Andreas Fink fink.a...@googlemail.com wrote: Sorry for my hasty and not well formulated rant. I was just thinking about the announcment of the Rails-team to switch to Coffeescript and what an impact that has on developers and existing apps. There is always that compromise between flexibility and high-level tools but as the server side of Tapestry focusses so much on flexibilty/modularity i think it would make sense to follow that route also for the browser side. In this case, it would be just an out-of-the-box support for a given package that wouldn't prevent support for other similar packages. In addition, it's quite probable that it would make it easier to add support for other similar packages. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
You can use both Less and CoffeeScript with Tapestry even today with my t5conduit https://github.com/cezary-biernacki/t5conduitlibrary. It works directly with Tapestry 5.3.0, and with help of t52transformershttps://github.com/cezary-biernacki/t52transformers also with 5.2.6. Best regards, Cezary On Thu, Dec 8, 2011 at 6:57 PM, Howard Lewis Ship hls...@gmail.com wrote: Most of the support needed for Less and CoffeeScript is already present; the trick is finding a reliable Java-compatible library that can execute the necessary code transformations (which are generally written in Ruby or JavaScript). http://code.google.com/p/wro4j/wiki/Features looks promising, but is geared more for build-time conversions, rather than runtime. I just haven't had spare cycles to spare on this. On Thu, Dec 8, 2011 at 8:13 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Thu, 08 Dec 2011 12:31:35 -0200, Andreas Fink fink.a...@googlemail.com wrote: Sorry for my hasty and not well formulated rant. I was just thinking about the announcment of the Rails-team to switch to Coffeescript and what an impact that has on developers and existing apps. There is always that compromise between flexibility and high-level tools but as the server side of Tapestry focusses so much on flexibilty/modularity i think it would make sense to follow that route also for the browser side. In this case, it would be just an out-of-the-box support for a given package that wouldn't prevent support for other similar packages. In addition, it's quite probable that it would make it easier to add support for other similar packages. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Awesome. Thank you!! On Dec 8, 2011, at 21:47 , Cezary Biernacki wrote: You can use both Less and CoffeeScript with Tapestry even today with my t5conduit https://github.com/cezary-biernacki/t5conduitlibrary. It works directly with Tapestry 5.3.0, and with help of t52transformershttps://github.com/cezary-biernacki/t52transformers also with 5.2.6. Best regards, Cezary On Thu, Dec 8, 2011 at 6:57 PM, Howard Lewis Ship hls...@gmail.com wrote: Most of the support needed for Less and CoffeeScript is already present; the trick is finding a reliable Java-compatible library that can execute the necessary code transformations (which are generally written in Ruby or JavaScript). http://code.google.com/p/wro4j/wiki/Features looks promising, but is geared more for build-time conversions, rather than runtime. I just haven't had spare cycles to spare on this. On Thu, Dec 8, 2011 at 8:13 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Thu, 08 Dec 2011 12:31:35 -0200, Andreas Fink fink.a...@googlemail.com wrote: Sorry for my hasty and not well formulated rant. I was just thinking about the announcment of the Rails-team to switch to Coffeescript and what an impact that has on developers and existing apps. There is always that compromise between flexibility and high-level tools but as the server side of Tapestry focusses so much on flexibilty/modularity i think it would make sense to follow that route also for the browser side. In this case, it would be just an out-of-the-box support for a given package that wouldn't prevent support for other similar packages. In addition, it's quite probable that it would make it easier to add support for other similar packages. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Cool! :) Why Just add uk.org.cezary.t52transformers.T52TransformersModule as a submodule to your AppModule (or equivalent) using @SubModule annotation. Haven't you tried to make your JAR so it adds the T52TransformersModule into the registry automatically (i.e. without using @SubModule)? http://tapestry.apache.org/autoloading-modules.html shows you how. ;) On Thu, 08 Dec 2011 18:47:16 -0200, Cezary Biernacki cezary...@gmail.com wrote: You can use both Less and CoffeeScript with Tapestry even today with my t5conduit https://github.com/cezary-biernacki/t5conduitlibrary. It works directly with Tapestry 5.3.0, and with help of t52transformershttps://github.com/cezary-biernacki/t52transformers also with 5.2.6. Best regards, Cezary On Thu, Dec 8, 2011 at 6:57 PM, Howard Lewis Ship hls...@gmail.com wrote: Most of the support needed for Less and CoffeeScript is already present; the trick is finding a reliable Java-compatible library that can execute the necessary code transformations (which are generally written in Ruby or JavaScript). http://code.google.com/p/wro4j/wiki/Features looks promising, but is geared more for build-time conversions, rather than runtime. I just haven't had spare cycles to spare on this. On Thu, Dec 8, 2011 at 8:13 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Thu, 08 Dec 2011 12:31:35 -0200, Andreas Fink fink.a...@googlemail.com wrote: Sorry for my hasty and not well formulated rant. I was just thinking about the announcment of the Rails-team to switch to Coffeescript and what an impact that has on developers and existing apps. There is always that compromise between flexibility and high-level tools but as the server side of Tapestry focusses so much on flexibilty/modularity i think it would make sense to follow that route also for the browser side. In this case, it would be just an out-of-the-box support for a given package that wouldn't prevent support for other similar packages. In addition, it's quite probable that it would make it easier to add support for other similar packages. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Actually it is geared for runtime solution as well. There is no difference in using less or coffeeScript (or sass, or any other available processors) for a runtime or build time solution. Cheers, Alex -- View this message in context: http://tapestry.1045711.n5.nabble.com/smarter-css-tp5051068p5060273.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Didn't describe things quite right; wro4j works as a filter at runtime, but still assumes a static description of what needs combining/transforming/compiling/etc. In a Tapestry application, that all needs to be figured out dynamically, on the fly, based on the what's in the framework, application, and 3rd party libraries. On Thu, Dec 8, 2011 at 2:33 PM, Alex Objelean alex.objel...@gmail.com wrote: Actually it is geared for runtime solution as well. There is no difference in using less or coffeeScript (or sass, or any other available processors) for a runtime or build time solution. Cheers, Alex -- View this message in context: http://tapestry.1045711.n5.nabble.com/smarter-css-tp5051068p5060273.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
One thing we need to do is support SASS (http://sass-lang.com/) so
that we can code concise configurable SASS stylesheets and let
Tapestry expand them into ugly, redundant CSS for the client web
browser.
On Tue, Dec 6, 2011 at 6:59 PM, Chris Collins chris...@me.com wrote:
Makes sense. Working in Java for too long has made me soft. I need to read
some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collins chris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped
standardize cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier IE's
with something that would throw in to the css another technique such as
using a gradient filled image file (in this example)? I don't think I
would want to throw in the technique of last resort because in the gradient
image case it would compete with the html5 technique right? For the
conditional method there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE.
Would that be correct? I am guessing from a browser laggard perspective the
only older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its not
just gradients.
So say I was trying to add browser specific css to my layout component
what would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not
perfectly accurate, but granted in some cases a necessary evil... avoid it
if you can. Its not uncommon to simply specify all the styles for the
various browsers because those that are not understood will simply be
ignored... be sure though that they are not understood or you might
encounter a nasty surprise or two. In your example there should be no need
for detection.
Cheers,
Peter
- Original Message -
From: Chris Collins chris...@me.com
To: Tapestry users users@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just things
like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background you
have to use different css properties per browser. So say I was trying to
add browser specific css to my layout component what would people suggest
as the best strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts of it
by browser right?
- Would you create a series of browser specific css assets then build
inject them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: smarter css
Hey Howard what about less?
On 08/12/11 04:49, Howard Lewis Ship wrote:
One thing we need to do is support SASS (http://sass-lang.com/) so
that we can code concise configurable SASS stylesheets and let
Tapestry expand them into ugly, redundant CSS for the client web
browser.
On Tue, Dec 6, 2011 at 6:59 PM, Chris Collinschris...@me.com wrote:
Makes sense. Working in Java for too long has made me soft. I need to read
some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collinschris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped standardize
cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier IE's
with something that would throw in to the css another technique such as using a
gradient filled image file (in this example)? I don't think I would want to
throw in the technique of last resort because in the gradient image case it
would compete with the html5 technique right? For the conditional method there
is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am talking
about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE. Would
that be correct? I am guessing from a browser laggard perspective the only
older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data crunching
like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its not just
gradients.
So say I was trying to add browser specific css to my layout component what
would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not perfectly
accurate, but granted in some cases a necessary evil... avoid it if you can.
Its not uncommon to simply specify all the styles for the various browsers
because those that are not understood will simply be ignored... be sure though
that they are not understood or you might encounter a nasty surprise or two. In
your example there should be no need for detection.
Cheers,
Peter
- Original Message -
From: Chris Collinschris...@me.com
To: Tapestry usersusers@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just things like
gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background you have to
use different css properties per browser. So say I was trying to add browser
specific css to my layout component what would people suggest as the best
strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts of it by
browser right?
- Would you create a series of browser specific css assets then build inject
them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Less or SCSS are both promising, but I'd love to see it integrated
into tapestry-core so that it could be used for Tapestry's default
stylesheet.
On Wed, Dec 7, 2011 at 3:32 PM, Greg Pagendam-Turner
g...@liftyourgame.com wrote:
Hey Howard what about less?
On 08/12/11 04:49, Howard Lewis Ship wrote:
One thing we need to do is support SASS (http://sass-lang.com/) so
that we can code concise configurable SASS stylesheets and let
Tapestry expand them into ugly, redundant CSS for the client web
browser.
On Tue, Dec 6, 2011 at 6:59 PM, Chris Collinschris...@me.com wrote:
Makes sense. Working in Java for too long has made me soft. I need to
read some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collinschris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped
standardize cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier
IE's with something that would throw in to the css another technique such
as
using a gradient filled image file (in this example)? I don't think I
would
want to throw in the technique of last resort because in the gradient
image
case it would compete with the html5 technique right? For the conditional
method there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE.
Would that be correct? I am guessing from a browser laggard perspective
the
only older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its
not just gradients.
So say I was trying to add browser specific css to my layout
component what would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not
perfectly accurate, but granted in some cases a necessary evil... avoid
it
if you can. Its not uncommon to simply specify all the styles for the
various browsers because those that are not understood will simply be
ignored... be sure though that they are not understood or you might
encounter a nasty surprise or two. In your example there should be no
need
for detection.
Cheers,
Peter
- Original Message -
From: Chris Collinschris...@me.com
To: Tapestry usersusers@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just
things like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background
you have to use different css properties per browser. So say I was
trying to
add browser specific css to my layout component what would people
suggest as
the best strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts
of it by browser right?
- Would you create a series of browser specific css assets then build
inject them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Please do not include this kind of technologies in the core.
It took us long enough to get rid of prototype.js.
Sure, it can be overridden but why not just offer it as part of an external
CoolKidsJavascriptStack.
Just my 2c.
Andi.
On Dec 8, 2011, at 1:15 , Howard Lewis Ship wrote:
Less or SCSS are both promising, but I'd love to see it integrated
into tapestry-core so that it could be used for Tapestry's default
stylesheet.
On Wed, Dec 7, 2011 at 3:32 PM, Greg Pagendam-Turner
g...@liftyourgame.com wrote:
Hey Howard what about less?
On 08/12/11 04:49, Howard Lewis Ship wrote:
One thing we need to do is support SASS (http://sass-lang.com/) so
that we can code concise configurable SASS stylesheets and let
Tapestry expand them into ugly, redundant CSS for the client web
browser.
On Tue, Dec 6, 2011 at 6:59 PM, Chris Collinschris...@me.com wrote:
Makes sense. Working in Java for too long has made me soft. I need to
read some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collinschris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped
standardize cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier
IE's with something that would throw in to the css another technique
such as
using a gradient filled image file (in this example)? I don't think I
would
want to throw in the technique of last resort because in the gradient
image
case it would compete with the html5 technique right? For the conditional
method there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE.
Would that be correct? I am guessing from a browser laggard perspective
the
only older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its
not just gradients.
So say I was trying to add browser specific css to my layout
component what would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not
perfectly accurate, but granted in some cases a necessary evil... avoid
it
if you can. Its not uncommon to simply specify all the styles for the
various browsers because those that are not understood will simply be
ignored... be sure though that they are not understood or you might
encounter a nasty surprise or two. In your example there should be no
need
for detection.
Cheers,
Peter
- Original Message -
From: Chris Collinschris...@me.com
To: Tapestry usersusers@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just
things like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background
you have to use different css properties per browser. So say I was
trying to
add browser specific css to my layout component what would people
suggest as
the best strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts
of it by browser right?
- Would you create a series of browser specific css assets then build
inject them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
but doesn't it kinda have to be in the core so the core CSS can use it? On Dec 7, 2011, at 7:57 PM, Andreas Fink wrote: Please do not include this kind of technologies in the core. It took us long enough to get rid of prototype.js. Sure, it can be overridden but why not just offer it as part of an external CoolKidsJavascriptStack. Just my 2c. Andi. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Is prototype a good comparison here? It seems that both the tools mentions
here somewhat become an extension to the template engine server side part of
the T5 equation.
After quickly playing with Tapestry-jquery it wasn't a case of getting rid of
prototype, but adding safely jquery. I certainly want to use javascript
libraries that use both prototype and jquery. I can imagine that one day there
maybe extensions for tapestry that incorporate not only these competing js
libraries but potentially leverage competing css macro languages like less and
sass. I guess I personally wouldn't care too much if it was one or the other
but it certainly would be nice if as a component of tapestry you could perhaps
have them as components that can co-exist in their own namespace.
1 1/2 cents worth.
C
On Dec 7, 2011, at 4:57 PM, Andreas Fink wrote:
Please do not include this kind of technologies in the core.
It took us long enough to get rid of prototype.js.
Sure, it can be overridden but why not just offer it as part of an external
CoolKidsJavascriptStack.
Just my 2c.
Andi.
On Dec 8, 2011, at 1:15 , Howard Lewis Ship wrote:
Less or SCSS are both promising, but I'd love to see it integrated
into tapestry-core so that it could be used for Tapestry's default
stylesheet.
On Wed, Dec 7, 2011 at 3:32 PM, Greg Pagendam-Turner
g...@liftyourgame.com wrote:
Hey Howard what about less?
On 08/12/11 04:49, Howard Lewis Ship wrote:
One thing we need to do is support SASS (http://sass-lang.com/) so
that we can code concise configurable SASS stylesheets and let
Tapestry expand them into ugly, redundant CSS for the client web
browser.
On Tue, Dec 6, 2011 at 6:59 PM, Chris Collinschris...@me.com wrote:
Makes sense. Working in Java for too long has made me soft. I need to
read some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collinschris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped
standardize cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier
IE's with something that would throw in to the css another technique
such as
using a gradient filled image file (in this example)? I don't think I
would
want to throw in the technique of last resort because in the gradient
image
case it would compete with the html5 technique right? For the
conditional
method there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE.
Would that be correct? I am guessing from a browser laggard perspective
the
only older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its
not just gradients.
So say I was trying to add browser specific css to my layout
component what would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not
perfectly accurate, but granted in some cases a necessary evil...
avoid it
if you can. Its not uncommon to simply specify all the styles for the
various browsers because those that are not understood will simply be
ignored... be sure though that they are not understood or you might
encounter a nasty surprise or two. In your example there should be no
need
for detection.
Cheers,
Peter
- Original Message -
From: Chris Collinschris...@me.com
To: Tapestry usersusers@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just
things like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background
you have to use different css properties per browser. So say I was
trying
Re: smarter css
Thanks Peter, makes total sense. I am so happy that css3 helped standardize cross browser support :-} So I probably would want to detect a non HTML5 browser such as earlier IE's with something that would throw in to the css another technique such as using a gradient filled image file (in this example)? I don't think I would want to throw in the technique of last resort because in the gradient image case it would compete with the html5 technique right? For the conditional method there is a technique proposed in: http://tapestry.apache.org/css.html Of course I am actually not literally talking about gradient fills I am talking about the general new vs old vs cross browser css challenge. This client side commenting conditional logic seems to be only for IE. Would that be correct? I am guessing from a browser laggard perspective the only older browsers people would care about would be IE in general? Sorry for all the novice questions, by day I normally do non ui data crunching like engineering :-} Best C On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote: Hi Chris, So when it comes to css3 is it really so ugly? If you really want an answer to that, unfortunately yes... and no its not just gradients. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Browser detection is pretty awful, as its a moving target and not perfectly accurate, but granted in some cases a necessary evil... avoid it if you can. Its not uncommon to simply specify all the styles for the various browsers because those that are not understood will simply be ignored... be sure though that they are not understood or you might encounter a nasty surprise or two. In your example there should be no need for detection. Cheers, Peter - Original Message - From: Chris Collins chris...@me.com To: Tapestry users users@tapestry.apache.org Sent: Tuesday, 6 December, 2011 7:48:57 AM Subject: smarter css So when it comes to css3 is it really so ugly? Ok perhaps its just things like gradients: http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html So in the microsoft example above for getting a gradient background you have to use different css properties per browser. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Random thoughts: - You can't tml-ify css, if you could then you could condition parts of it by browser right? - Would you create a series of browser specific css assets then build inject them directly into the layout page? Clearly I don't have a clue :-} again sorry for dumb questions. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collins chris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped standardize
cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier IE's
with something that would throw in to the css another technique such as using
a gradient filled image file (in this example)? I don't think I would want
to throw in the technique of last resort because in the gradient image case
it would compete with the html5 technique right? For the conditional method
there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE. Would
that be correct? I am guessing from a browser laggard perspective the only
older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its not
just gradients.
So say I was trying to add browser specific css to my layout component what
would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not perfectly
accurate, but granted in some cases a necessary evil... avoid it if you can.
Its not uncommon to simply specify all the styles for the various browsers
because those that are not understood will simply be ignored... be sure
though that they are not understood or you might encounter a nasty surprise
or two. In your example there should be no need for detection.
Cheers,
Peter
- Original Message -
From: Chris Collins chris...@me.com
To: Tapestry users users@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just things
like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background you have
to use different css properties per browser. So say I was trying to add
browser specific css to my layout component what would people suggest as the
best strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts of it
by browser right?
- Would you create a series of browser specific css assets then build inject
them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Makes sense. Working in Java for too long has made me soft. I need to read
some c code to repent for my sins ;-}
Thanks Bob.
C
On Dec 6, 2011, at 6:41 PM, Bob Harner wrote:
Rather than having separate IE-only style sheets, a technique I prefer
is to use IE conditional comments to add an additional div around the
body in my layout.tml, like this:
body
!--[if lt IE 9]
div class=ie-old
![endif]--
!--[if lt IE 9]
/div
![endif]--
/body
Once that's done, then it becomes trivially easy to add all sorts of
IE-specific CSS rules in your app's main (or only) style sheet file:
DIV.menu {
/* CSS rules for most browsers go here */
}
DIV.ie-old DIV.menu {
/* some IE-specific rules go here */
}
Hope this helps...
On Tue, Dec 6, 2011 at 12:10 PM, Chris Collins chris...@me.com wrote:
Thanks Peter, makes total sense. I am so happy that css3 helped standardize
cross browser support :-}
So I probably would want to detect a non HTML5 browser such as earlier IE's
with something that would throw in to the css another technique such as
using a gradient filled image file (in this example)? I don't think I would
want to throw in the technique of last resort because in the gradient image
case it would compete with the html5 technique right? For the conditional
method there is a technique proposed in:
http://tapestry.apache.org/css.html
Of course I am actually not literally talking about gradient fills I am
talking about the general new vs old vs cross browser css challenge.
This client side commenting conditional logic seems to be only for IE.
Would that be correct? I am guessing from a browser laggard perspective the
only older browsers people would care about would be IE in general?
Sorry for all the novice questions, by day I normally do non ui data
crunching like engineering :-}
Best
C
On Dec 5, 2011, at 11:23 PM, Peter Stavrinides wrote:
Hi Chris,
So when it comes to css3 is it really so ugly?
If you really want an answer to that, unfortunately yes... and no its not
just gradients.
So say I was trying to add browser specific css to my layout component
what would people suggest as the best strategy?
Browser detection is pretty awful, as its a moving target and not perfectly
accurate, but granted in some cases a necessary evil... avoid it if you
can. Its not uncommon to simply specify all the styles for the various
browsers because those that are not understood will simply be ignored... be
sure though that they are not understood or you might encounter a nasty
surprise or two. In your example there should be no need for detection.
Cheers,
Peter
- Original Message -
From: Chris Collins chris...@me.com
To: Tapestry users users@tapestry.apache.org
Sent: Tuesday, 6 December, 2011 7:48:57 AM
Subject: smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just things
like gradients:
http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html
So in the microsoft example above for getting a gradient background you
have to use different css properties per browser. So say I was trying to
add browser specific css to my layout component what would people suggest
as the best strategy?
Random thoughts:
- You can't tml-ify css, if you could then you could condition parts of it
by browser right?
- Would you create a series of browser specific css assets then build
inject them directly into the layout page?
Clearly I don't have a clue :-}
again sorry for dumb questions.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
smarter css
So when it comes to css3 is it really so ugly? Ok perhaps its just things like gradients: http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html So in the microsoft example above for getting a gradient background you have to use different css properties per browser. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Random thoughts: - You can't tml-ify css, if you could then you could condition parts of it by browser right? - Would you create a series of browser specific css assets then build inject them directly into the layout page? Clearly I don't have a clue :-} again sorry for dumb questions. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: smarter css
Hi Chris, So when it comes to css3 is it really so ugly? If you really want an answer to that, unfortunately yes... and no its not just gradients. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Browser detection is pretty awful, as its a moving target and not perfectly accurate, but granted in some cases a necessary evil... avoid it if you can. Its not uncommon to simply specify all the styles for the various browsers because those that are not understood will simply be ignored... be sure though that they are not understood or you might encounter a nasty surprise or two. In your example there should be no need for detection. Cheers, Peter - Original Message - From: Chris Collins chris...@me.com To: Tapestry users users@tapestry.apache.org Sent: Tuesday, 6 December, 2011 7:48:57 AM Subject: smarter css So when it comes to css3 is it really so ugly? Ok perhaps its just things like gradients: http://ie.microsoft.com/testdrive/graphics/cssgradientbackgroundmaker/default.html So in the microsoft example above for getting a gradient background you have to use different css properties per browser. So say I was trying to add browser specific css to my layout component what would people suggest as the best strategy? Random thoughts: - You can't tml-ify css, if you could then you could condition parts of it by browser right? - Would you create a series of browser specific css assets then build inject them directly into the layout page? Clearly I don't have a clue :-} again sorry for dumb questions. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
