You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Bojan Smojver <bo...@binarix.com> on 2001/08/29 06:23:18 UTC
Re: floating point types (The CSS twist)
The CSS 1 and CSS 2 specifications talk about this:
----------------------------------------------------
<p style="font-size: 1.5em">This is important!</p>
----------------------------------------------------
What I'm getting at here is the fact that the floating point number is
being used to describe a purely presentation layer property. So, one can
expect from a web designer to do something like:
----------------------------------------------------
#set ($baseFontSize = 1.1)
#set ($importantFactor = 1.5)
#set ($veryImportantFactor = 2.0)
and then just use those numbers later:
#set ($importantFontSize = $baseFontSize * $importantFactor)
#set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
----------------------------------------------------
and then in HTML:
----------------------------------------------------
<p style="font-size: ${importantFontSize}em">This is important!</p>
<p style="font-size: ${veryImportantFontSize}em">This is very
important!</p>
----------------------------------------------------
This can (obviously) be rewritten in many different ways, but one could
argue that floating point arithmetic is important for presentation
layer, since otherwise an engineer would have to write a multiplication
tool for something that doesn't belong into business logic at all.
Personally, I've never had a need to use floating point numbers in
Velocity, so I won't miss it much if it isn't there. What would be the
rationale for not enabling the above?
Bojan
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
Jon Stevens wrote:
>
> on 8/28/01 11:10 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
> >
> > Bojan
>
> He is.
>
> The Tigris site was done before he was hired. The next revision of the
> Tigris site will use the unified CSS between Scarab and our core product
> which Tigris is an installation of.
>
> Needless to say, I still haven't been convinced of the need to add float's
> and the more I think about it and the more examples people give, the less
> inclined I am to give it a positive vote.
As far as I can tell, your main objections are along the lines of
increased complexity of Velocity, MVC screwups, type casting issues etc.
Typing problems come from the fact the Java is a strongly typed language
and float != int != long != double != short. Totally understandable and
I don't think anything like that should be introduced.
I think a few people hit it with suggestions that there shouldn't be
floats, doubles, ints, longs etc. but just numbers (along the lines of
other weakly typed languages like Javascript). That's where my (stupid)
BigDecimal suggestion was coming from.
The other approach would be even 'softer', kind of like a shell, where
any Velocity reference would be able to participate in arithmetic
operations. For instance:
----------------------------------------
#set ($a = "3.0")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or:
----------------------------------------
#set ($a = "3")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or:
----------------------------------------
#set ($a = 3)
#set ($b = 4.0)
#set ($c = $a / $b)
----------------------------------------
If you screw yourself up and write:
----------------------------------------
#set ($a = "not a number")
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
or even more stupid:
----------------------------------------
#set ($a = $ref.getThatWrongHashtable())
#set ($b = "4.0")
#set ($c = $a / $b)
----------------------------------------
value of $c just becomes 'NaN' or something, and then even integers can
be dropped (I hope Geir doesn't live close to Sydney :-)
As I said before, I can live with or without it...
Bojan
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 11:10 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
>
> Bojan
He is.
The Tigris site was done before he was hired. The next revision of the
Tigris site will use the unified CSS between Scarab and our core product
which Tigris is an installation of.
Needless to say, I still haven't been convinced of the need to add float's
and the more I think about it and the more examples people give, the less
inclined I am to give it a positive vote.
thanks,
-jon
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
Jon Stevens wrote:
>
> on 8/28/01 10:26 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > And yet, it doesn't pass neither CSS nor HTML validation.
> >
> > http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.or
> > g%2Fbranding%2Fstyle.css&warning=1&profile=none
> >
> > http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=In
> > line
>
> Sigh. You are trying to validate the wrong file. That is the tigris.org
> site, not Scarab's (the applications CSS) file.
>
> I just validated Scarab's and it only has minor warnings.
>
> <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
>
> -jon
Time to assign the Scarab guy to Tigris site... Just teasing... ;-)
Bojan
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/01 10:26 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> And yet, it doesn't pass neither CSS nor HTML validation.
>
> http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.or
> g%2Fbranding%2Fstyle.css&warning=1&profile=none
>
> http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=In
> line
Sigh. You are trying to validate the wrong file. That is the tigris.org
site, not Scarab's (the applications CSS) file.
I just validated Scarab's and it only has minor warnings.
<http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
-jon
Re: floating point types (The CSS twist)
Posted by Bojan Smojver <bo...@binarix.com>.
And yet, it doesn't pass neither CSS nor HTML validation.
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fscarab.tigris.org%2Fbranding%2Fstyle.css&warning=1&profile=none
http://validator.w3.org/check?uri=http%3A%2F%2Fscarab.tigris.org%2F&doctype=Inline
Though who knows what would happen if the expert had floating point
numbers available... :-))
Bojan
Jon Stevens wrote:
>
> Nice try, but Scarab has a very advanced CSS stylesheet done by a CSS expert
> and it doesn't seem to need any of that.
>
> :-)
>
> -jon
>
> on 8/28/01 9:23 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > The CSS 1 and CSS 2 specifications talk about this:
> >
> > ----------------------------------------------------
> > <p style="font-size: 1.5em">This is important!</p>
> > ----------------------------------------------------
> >
> > What I'm getting at here is the fact that the floating point number is
> > being used to describe a purely presentation layer property. So, one can
> > expect from a web designer to do something like:
> >
> > ----------------------------------------------------
> > #set ($baseFontSize = 1.1)
> >
> > #set ($importantFactor = 1.5)
> > #set ($veryImportantFactor = 2.0)
> >
> > and then just use those numbers later:
> >
> > #set ($importantFontSize = $baseFontSize * $importantFactor)
> > #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> > ----------------------------------------------------
> >
> > and then in HTML:
> >
> > ----------------------------------------------------
> > <p style="font-size: ${importantFontSize}em">This is important!</p>
> > <p style="font-size: ${veryImportantFontSize}em">This is very
> > important!</p>
> > ----------------------------------------------------
> >
> > This can (obviously) be rewritten in many different ways, but one could
> > argue that floating point arithmetic is important for presentation
> > layer, since otherwise an engineer would have to write a multiplication
> > tool for something that doesn't belong into business logic at all.
> >
> > Personally, I've never had a need to use floating point numbers in
> > Velocity, so I won't miss it much if it isn't there. What would be the
> > rationale for not enabling the above?
> >
> > Bojan
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: floating point types (The CSS twist)
Posted by Jon Stevens <jo...@latchkey.com>.
Nice try, but Scarab has a very advanced CSS stylesheet done by a CSS expert
and it doesn't seem to need any of that.
:-)
-jon
on 8/28/01 9:23 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> The CSS 1 and CSS 2 specifications talk about this:
>
> ----------------------------------------------------
> <p style="font-size: 1.5em">This is important!</p>
> ----------------------------------------------------
>
> What I'm getting at here is the fact that the floating point number is
> being used to describe a purely presentation layer property. So, one can
> expect from a web designer to do something like:
>
> ----------------------------------------------------
> #set ($baseFontSize = 1.1)
>
> #set ($importantFactor = 1.5)
> #set ($veryImportantFactor = 2.0)
>
> and then just use those numbers later:
>
> #set ($importantFontSize = $baseFontSize * $importantFactor)
> #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> ----------------------------------------------------
>
> and then in HTML:
>
> ----------------------------------------------------
> <p style="font-size: ${importantFontSize}em">This is important!</p>
> <p style="font-size: ${veryImportantFontSize}em">This is very
> important!</p>
> ----------------------------------------------------
>
> This can (obviously) be rewritten in many different ways, but one could
> argue that floating point arithmetic is important for presentation
> layer, since otherwise an engineer would have to write a multiplication
> tool for something that doesn't belong into business logic at all.
>
> Personally, I've never had a need to use floating point numbers in
> Velocity, so I won't miss it much if it isn't there. What would be the
> rationale for not enabling the above?
>
> Bojan
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: OT: css stuff (was Re: floating point types (The CSS twist))
Posted by Bojan Smojver <bo...@binarix.com>.
todd fahrner wrote:
>
> On Tuesday, August 28, 2001, at 09:23 , Bojan Smojver wrote:
>
> > The CSS 1 and CSS 2 specifications talk about this:
> >
> > ----------------------------------------------------
> > <p style="font-size: 1.5em">This is important!</p>
> > ----------------------------------------------------
> >
> > What I'm getting at here is the fact that the floating point number is
> > being used to describe a purely presentation layer property. So, one can
> > expect from a web designer to do something like:
> >
> > ----------------------------------------------------
> > #set ($baseFontSize = 1.1)
>
> that wouldn't be very smart as a value for a "base" font size in em units,
> at least not if applied to elements that might find themselves in a
> parent-child relationship, such as TD in the case of nested tables.
> Because the font-size value of the nested TD would then work out to 1.21x
> of the first TD. Which itself might be nested in a div or in body or
> whatever. Applied to font-size, em units are relative to the font size of
> the parent element, not, as commonly asserted, to the size selected by the
> user in UA prefs. It's a special case that 1em = the user-selected size.
>
> > #set ($importantFactor = 1.5)
> > #set ($veryImportantFactor = 2.0)
> >
> > and then just use those numbers later:
> >
> > #set ($importantFontSize = $baseFontSize * $importantFactor)
> > #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> > ----------------------------------------------------
> >
> > and then in HTML:
> >
> > ----------------------------------------------------
> > <p style="font-size: ${importantFontSize}em">This is important!</p>
> > <p style="font-size: ${veryImportantFontSize}em">This is very
> > important!</p>
>
> If you're going to embed the formatting inline like that, instead of in an
> external stylesheet, it would be less verbose and more portable just to
> use presentational HTML attrs/elements, like BIG, SMALL, FONT, etc, or,
> better yet, elements with semantics like EM or STRONG (for important and
> very important, respectively). You could use Velocity to do some
> non-redundant things in CSS per se, though, like symbolic constants. For
> instance, Scarab's stylesheet sets many background and foreground colors
> on various selections redundantly. These could become, e.g., $bgcolor_a,
> $color_a, $bgcolor_b, $color_b, etc., for easier maintenance. Not that
> manual maintenance of most CSS files is too hard.
>
> as for the warnings W3C's CSS Validator throws about Scarab's CSS, I paste
> part of a reply to Jon, who alerted me to this thread:
As I said, this can be done in many different ways, which is obvious.
Never claimed that it was good style, correct or anything like that. It
is presentation and it uses floating point numbers, that's all. This
could have been a CAD system that needed a zoom factor calculation,
which is presentation as well. Totally irrelevant.
> > 1. the "errors" below reflect the limitations of the QA software and the
> > highly debatable opinions of its designers. they are absolutely not
> > errors in any chapter-and-verse sense.
> >
>
> > <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
> >
> > Line : 66 Level : 1 You have no color with your background-color : .docs
> > .toc
> >
> > The opinion reflected in this message is that you should never specify
> > background or foreground colors alone for any selected element, since
> > user or UA stylesheets might lead to contrast failures. For instance, you
> > shouldn't say that paragraph text should be black without also specifying
> > that paragraph backgrounds should be some color sufficiently lighter than
> > black. Nevermind that you are careful to set the parent elements of
> > paragraphs (like BODY) to have a suitably contrasting color - the QA
> > software author thinks you need to specify such things redundantly on
> > every single selected element! Why? because users or UAs might have
> > stylesheets that set paragraph text to white without specifying a
> > background color, and the merged result will be white on white. Phooey:
> > the 12 users in the world who use personal stylesheets know better, and
> > they will be careful to take care of all such dependencies. It is the
> > author-stylesheet designers' (our) responsibility to write lean,
> > accessible, maintainable, cool-looking sheets more than to defend
> > verbosely against such sloppy edge-case user-stylesheet authoring!
>
> --
> todd fahrner
Dunno what you talking about here, the failed stylesheets from Tigris
site produce this:
--------------------------------------------
Line: 8 Context : .Header
Property bottom-margin doesn't exist : 4px
Line: 9 Context : .ProjectNameHeader
Property bottom-margin doesn't exist : 4px
Line: 12 Context : .Download
Invalid number : color66666 is not a valid color 3 or 6 hexadecimals
numbers : #66666
Line: 24 Context : .NewsDateTable
Invalid number : colorParse Error - #
Line: 25 Context : .SiteHeader
Property bottom-margin doesn't exist : 4px
Line: 36 Context : .Warning
Property bottom-margin doesn't exist : 4px
--------------------------------------------
Mostly 'bottom-margin' (which doesn't exist in CSS) instead of
'margin-bottom'. But good for having fun... :-)
Bojan
OT: css stuff (was Re: floating point types (The CSS twist))
Posted by todd fahrner <tf...@collab.net>.
On Tuesday, August 28, 2001, at 09:23 , Bojan Smojver wrote:
> The CSS 1 and CSS 2 specifications talk about this:
>
> ----------------------------------------------------
> <p style="font-size: 1.5em">This is important!</p>
> ----------------------------------------------------
>
> What I'm getting at here is the fact that the floating point number is
> being used to describe a purely presentation layer property. So, one can
> expect from a web designer to do something like:
>
> ----------------------------------------------------
> #set ($baseFontSize = 1.1)
that wouldn't be very smart as a value for a "base" font size in em units,
at least not if applied to elements that might find themselves in a
parent-child relationship, such as TD in the case of nested tables.
Because the font-size value of the nested TD would then work out to 1.21x
of the first TD. Which itself might be nested in a div or in body or
whatever. Applied to font-size, em units are relative to the font size of
the parent element, not, as commonly asserted, to the size selected by the
user in UA prefs. It's a special case that 1em = the user-selected size.
> #set ($importantFactor = 1.5)
> #set ($veryImportantFactor = 2.0)
>
> and then just use those numbers later:
>
> #set ($importantFontSize = $baseFontSize * $importantFactor)
> #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> ----------------------------------------------------
>
> and then in HTML:
>
> ----------------------------------------------------
> <p style="font-size: ${importantFontSize}em">This is important!</p>
> <p style="font-size: ${veryImportantFontSize}em">This is very
> important!</p>
If you're going to embed the formatting inline like that, instead of in an
external stylesheet, it would be less verbose and more portable just to
use presentational HTML attrs/elements, like BIG, SMALL, FONT, etc, or,
better yet, elements with semantics like EM or STRONG (for important and
very important, respectively). You could use Velocity to do some
non-redundant things in CSS per se, though, like symbolic constants. For
instance, Scarab's stylesheet sets many background and foreground colors
on various selections redundantly. These could become, e.g., $bgcolor_a,
$color_a, $bgcolor_b, $color_b, etc., for easier maintenance. Not that
manual maintenance of most CSS files is too hard.
as for the warnings W3C's CSS Validator throws about Scarab's CSS, I paste
part of a reply to Jon, who alerted me to this thread:
> 1. the "errors" below reflect the limitations of the QA software and the
> highly debatable opinions of its designers. they are absolutely not
> errors in any chapter-and-verse sense.
>
> <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
>
> Line : 66 Level : 1 You have no color with your background-color : .docs
> .toc
>
> The opinion reflected in this message is that you should never specify
> background or foreground colors alone for any selected element, since
> user or UA stylesheets might lead to contrast failures. For instance, you
> shouldn't say that paragraph text should be black without also specifying
> that paragraph backgrounds should be some color sufficiently lighter than
> black. Nevermind that you are careful to set the parent elements of
> paragraphs (like BODY) to have a suitably contrasting color - the QA
> software author thinks you need to specify such things redundantly on
> every single selected element! Why? because users or UAs might have
> stylesheets that set paragraph text to white without specifying a
> background color, and the merged result will be white on white. Phooey:
> the 12 users in the world who use personal stylesheets know better, and
> they will be careful to take care of all such dependencies. It is the
> author-stylesheet designers' (our) responsibility to write lean,
> accessible, maintainable, cool-looking sheets more than to defend
> verbosely against such sloppy edge-case user-stylesheet authoring!
--
todd fahrner