You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Steve Mactaggart <st...@golftime.com.au> on 2004/09/08 02:31:46 UTC

RE: EnhancedHTMLAppender

Long time no speak,

I've been very slack on this front and as it seems that 1.3 is gathering
steam to get released I hope to get the EnhancedHTMLAppender completed in
the next week.

After leaving it so long, and having to re-read the discussion to work out
where we were up to I think its time to solve this CSS issue.

My suggestion is to hard-code styles into the top of the style sheet and
provide the user a property to change a link to override the default styles,
as suggested here:

> ><HEAD>
> >   <STYLE TYPE="text/css">
> >     <!--
> >       BODY { background-color: white }
> >     -->
> >   </STYLE>
> >   <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css" 
> > TITLE="Basic"/>
> ></HEAD>

I'll update the code over the next few days to support this and get an
update file posted back to the list.

Sorry for the HUGE delay,

Steve


> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com] 
> Sent: Saturday, 5 June 2004 9:51 AM
> To: Log4J Developers List
> Subject: RE: EnhancedHTMLAppender
> 
> At 02:51 PM 6/4/2004 +0200, you wrote:
> >Hi Jacob,
> >
> >I very much like the solution you outlined.
> 
> Happy to hear :-)
> 
> >As you mentioned, my observation also show that the order in which
> >styles are listed has its importance.
> >
> >For example, in the following sample, the output will be white as the
> >embedded style listed last overrides the external style sheet listed
> >first
> >
> ><HEAD>
> >   <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css" 
> > TITLE="Basic"/>
> >
> >   <STYLE TYPE="text/css">
> >     <!--
> >      BODY { background-color: white }
> >     -->
> >   </STYLE>
> ></HEAD>
> >
> >Similarly, in the following sample, the output will be yellow as the
> >external style listed last overrides the embedded style sheet listed
> >first
> >
> ><HEAD>
> >   <STYLE TYPE="text/css">
> >     <!--
> >       BODY { background-color: white }
> >     -->
> >   </STYLE>
> >   <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css" 
> > TITLE="Basic"/>
> ></HEAD>
> 
> Yep
> 
> >Is this precedence rule documented somewhere?
> 
> Actually, this is the definition of the cascade.
> http://www.w3.org/TR/CSS21/cascade.html#cascade
> 
> Here's a more clear order of the cascade presented by Ian 
> Hixson, one of 
> the CSS spec authors
> http://bugzilla.mozilla.org/show_bug.cgi?id=43220#c105
> 
> For our purposes, the main thing we need to remember is rule 
> #4 of the spec:
> 
> "Finally, sort by order specified: if two rules have the same weight, 
> origin and specificity, the latter specified wins. Rules in 
> imported style 
> sheets are considered to be before any rules in the style 
> sheet itself. "
> 
> As long as the user specified style sheet writes rules with 
> at least the 
> same weight and specificity of the default style sheet, the 
> user specified 
> style sheet will successfully override the default if it 
> comes last in the 
> cascading order.
> 
> 
> Jake
> 
> 
> >If take the precedence rule for granted, then as you suggested, we
> >could embed a default style in the HTML and override it with a custom
> >style specified by the user.
> >
> >We could even have:
> >
> ><HEAD>
> >   <STYLE TYPE="text/css">
> >     <!--
> >       default style here
> >     -->
> >   </STYLE>
> >   <LINK REL=StyleSheet 
> HREF="http://logging.apache.org/css/default.css" 
> > TITLE="Default style"/>
> >   <LINK REL=StyleSheet HREF="user specified css" 
> TITLE="User defined"/>
> ></HEAD>
> >
> >In summary, we should be able to provide robust solutions as long as
> >the precedence rules are clearly understood.
> 
> Yep, and they certainly are well understood.  This is a good 
> solution.  BTW, what "default style" would you provide in the 
> default.css 
> that the inline <style> wouldn't already have?  I see that as 
> redundant.  However, having a style sheet with media="print" defining 
> styles to be used only when printing might be valuable to link from 
> logging.apache.org.
> 
> 
> Jake
> 
> 
> 
> >At 06:07 AM 6/4/2004, Jacob Kjome wrote:
> >
> >>I have to imagine that the style stuff for 
> EnhancedHTMLLayout would be 
> >>pretty sparse.  The structure of the document will be pretty 
> >>standard.  In-lining styles (meaning <sometag style="">) in 
> this case 
> >>would be tantamount to using <font> tags given the sheer 
> amount of markup 
> >>written.  However, one can add a style for the whole 
> document in the head 
> >>without having to import it which solves both the redundant 
> style="" and 
> >>non-existent external file issues.  In fact, that can be 
> the default 
> >>stylesheet and a linked one can be added later in the 
> cascade to provide 
> >>an override for anyone to utilize.  If the linked one 
> doesn't exist, only 
> >>the default applies.  If the linked one exists, then that 
> linked css file 
> >>has the ability to override and extend the styles.  For instance...
> >>
> >><style type="text/css">
> >>html, body { ... }
> >>a { .... }
> >>...
> >>...
> >>...
> >></style>
> >><link rel="Stylesheet" type="text/css" href="[user defined 
> path set via 
> >>some property of layout]/log4jhtmllayout.css" title="Custom Style">
> >>
> >>One can also provide alternate style sheets or even ones 
> specifically for 
> >>printing.  These can be either always provided with 
> standard css file 
> >>names and only used in the cascade if they exist (as is 
> shown above) or 
> >><link> tags can be written as they are set via some property of the 
> >>Layout class.
> >>
> >>Thoughts?
> >>
> >>Jake
> >
> >--
> >Ceki Gülcü
> >
> >      For log4j documentation consider "The complete log4j manual"
> >      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Ceki Gülcü <ce...@qos.ch>.
At 01:26 PM 9/13/2004, Steve Mactaggart wrote:

>I agree with all of that comment, but I would refer to the previous emails
>about making and keeping the base styles very basic.
>
>I was thinking of defining styles for the default font, alternating lines,
>and styles for each level.
>
>I understand the discussion in relation to the complexity of css, but agree
>with previous statements that if we make the defaults work well, then there
>won't be a major reason to override them.
>
>My styles for the layout would be:
>
>.text {}
>.debug {}
>.debug2 {}
>.info {}
>.info2 {}
>.warn {}
>.warn2 {}
>.error {}
>.error2 {}
>.fatal {}
>.fatal2 {}

If the rows alternate between even and odd rows, we can specify an odd
debug line as <tr "class="odd debug">...</tr> and an even line as <tr
class="even debug">...</tr>. So the above list becomes:

debug {}
info  {}
warn  {}
error {}
fatal {}
even  {}
odd   {}

See http://www.w3.org/TR/REC-CSS2/selector.html for the exact details.

>I think this basic list would be simple to overwrite if the user felt the
>need to.

Given that the default rules will used in most cases, there will be 
pressure to make the default rules look pretty and pleasant to the eye. 
Thus, we cannot conclude that the default rules will be necessarily 
simple.  The point I am trying to make is that is that if the default rules are
embedded within the generated html file, then it will be hard, or at
least very confusing, for a non-expert user to override the defaults
css rules.


>Steve

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Jacob Kjome <ho...@visi.com>.
Hi Ceki,

Quoting Ceki Gülcü <ce...@qos.ch>:

> At 07:46 PM 9/10/2004, Jacob Kjome wrote:
>
> >If the defaults are clearly defined, then it is simple to override those
> >properties.
>
> That is simply not true. Let me give you an example:
>

I think we have a different idea of the definition of "simplicity" and how one
would normally use CSS.  Normally, default rules provide base minimum defaults
and are applied widely.  Customizing is generally done within the context (and
with knowledge) of the inherited CSS rules.

Keep in mind what I've said: If we define rules in a way that one has to
override each and every last one of them to get things looking their own way,
then we've written the rules poorly, in which case we'd want to make sure the
defaults are reasonable.

Either way, if one has knowledge of the defaults, one can always override them. 
In your case below, one could very well make a copy of that and modify/extend
as needed.  Again, the fact that one would need to do this means the defaults
were written poorly.  However, there is nothing complex here if you have half
an understanding of CSS.  Anyone that would bother to take the time to override
defaults would probably understand this anyway.  Otherwise, the idea is for the
defaults to be sane and general enough to stand on their own with only a need
to override, say..., colors or font.

If you disagree with this then you disagree with the CSS spec authors and I
won't continue an argument of this point.  We'll have to agree to disagree and
a decision will have to be made about who's point of view is going to work best
for the EnhancedHTMLAppender.  Obviously I think mine will work better, but the
final decision isn't up to me.  I leave it to you and the community.

Jake

> Assume that the following CSS rule is *embedded* in the output of
> EnhancedHTMLAppender. The embedded rules are what you would call the
> default rules.
>
> H1.someclass {
>    text-decoration: none;
>    font-family: Helvetica, sans-serif;
>    font-weight: bold;
>    background: #DDD;
>    color: #0066CC;
>    border: 3px solid green;
>    padding-left: 1em;
>    padding-right: 1em;
>    padding-top: 3px;
>    padding-bottom: 0px;
> }
>
> Let the user include a CSS file (with the intent of overriding the
> default rules). Let that CSS file contain the following rule:
>
>
> H1.someclass {
>    background: black;
>    color: white;
>    border-bottom: 1px solid red;
> }
>
> The actual applicable rule will be a combination of the embedded rule
> *and* the rule from the CSS file. If the embedded rule is mentioned
> before the CSS file, then the output will have a black back ground,
> white font and a red border-border but it will also rendered in bold,
> Helvetica font, with 3px green border at the top, left and right, in
> addition to the padding rules from the embedded CSS.
>
> CSS rules do not combine simply, far from it.
>
>
> --
> Ceki Gülcü
>
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Steve Mactaggart <st...@golftime.com.au>.
> 
> >If the defaults are clearly defined, then it is simple to 
> override those
> >properties.
> 
> That is simply not true. Let me give you an example:
> 
> Assume that the following CSS rule is *embedded* in the output of
> EnhancedHTMLAppender. The embedded rules are what you would call the
> default rules.
> 
> H1.someclass {
>    text-decoration: none;
>    font-family: Helvetica, sans-serif;
>    font-weight: bold;
>    background: #DDD;
>    color: #0066CC;
>    border: 3px solid green;
>    padding-left: 1em;
>    padding-right: 1em;
>    padding-top: 3px;
>    padding-bottom: 0px;
> }
> 
> Let the user include a CSS file (with the intent of overriding the
> default rules). Let that CSS file contain the following rule:
> 
> 
> H1.someclass {
>    background: black;
>    color: white;
>    border-bottom: 1px solid red;
> }
> 
> The actual applicable rule will be a combination of the embedded rule
> *and* the rule from the CSS file. If the embedded rule is mentioned
> before the CSS file, then the output will have a black back ground,
> white font and a red border-border but it will also rendered in bold,
> Helvetica font, with 3px green border at the top, left and right, in
> addition to the padding rules from the embedded CSS.
> 
> CSS rules do not combine simply, far from it.
> 

I agree with all of that comment, but I would refer to the previous emails
about making and keeping the base styles very basic.

I was thinking of defining styles for the default font, alternating lines,
and styles for each level.

I understand the discussion in relation to the complexity of css, but agree
with previous statements that if we make the defaults work well, then there
won't be a major reason to override them. 

My styles for the layout would be:

.text {}
.debug {}
.debug2 {}
.info {}
.info2 {}
.warn {}
.warn2 {}
.error {}
.error2 {}
.fatal {}
.fatal2 {}

I think this basic list would be simple to overwrite if the user felt the
need to.

Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:46 PM 9/10/2004, Jacob Kjome wrote:

>If the defaults are clearly defined, then it is simple to override those
>properties.

That is simply not true. Let me give you an example:

Assume that the following CSS rule is *embedded* in the output of
EnhancedHTMLAppender. The embedded rules are what you would call the
default rules.

H1.someclass {
   text-decoration: none;
   font-family: Helvetica, sans-serif;
   font-weight: bold;
   background: #DDD;
   color: #0066CC;
   border: 3px solid green;
   padding-left: 1em;
   padding-right: 1em;
   padding-top: 3px;
   padding-bottom: 0px;
}

Let the user include a CSS file (with the intent of overriding the
default rules). Let that CSS file contain the following rule:


H1.someclass {
   background: black;
   color: white;
   border-bottom: 1px solid red;
}

The actual applicable rule will be a combination of the embedded rule
*and* the rule from the CSS file. If the embedded rule is mentioned
before the CSS file, then the output will have a black back ground,
white font and a red border-border but it will also rendered in bold,
Helvetica font, with 3px green border at the top, left and right, in
addition to the padding rules from the embedded CSS.

CSS rules do not combine simply, far from it.


-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:

> Hi Steve,
>
> At 02:31 AM 9/8/2004, you wrote:
> >Long time no speak,
> >
> >I've been very slack on this front and as it seems that 1.3 is gathering
> >steam to get released I hope to get the EnhancedHTMLAppender completed in
> >the next week.
> >
> >After leaving it so long, and having to re-read the discussion to work out
> >where we were up to I think its time to solve this CSS issue.
> >
> >My suggestion is to hard-code styles into the top of the style sheet and
> >provide the user a property to change a link to override the default styles,
> >as suggested here:
> >
> > > ><HEAD>
> > > >   <STYLE TYPE="text/css">
> > > >     <!--
> > > >       BODY { background-color: white }
> > > >     -->
> > > >   </STYLE>
> > > >   <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > > > TITLE="Basic"/>
> > > ></HEAD>
>
> Well, the above probably not such a good idea because the rules for style
> cascades are not that simple. Later rules add up on earlier rules except if
> they contain already existing properties in which case they mask older
> properties. In short, if there are more than one source for styles most
> users are likely to get very confused. We don't want to mislead or confuse
> users whenever we can help it.
>

If the defaults are clearly defined, then it is simple to override those
properties.  The defaults don't have to be overly complex, but there ought to
be some defaults.  Users creating custom stylesheets would simply read the docs
to see what the default styles are.  Even then, if sane defaults are used,
there shouldn't be any reason for the user to override most of them.  But if
they really wanted to, it would be simple to do so.  Logging configuration is,
by far, more complex than this.


> The best solution I can think of consist of linking to a style located at a
> well-known URL by default but allow the user to override that default by
> specifying an alternative URL if need be. This approach will work out of
> the box in 95% of the cases and still allow developers to handle
> exceptional cases when necessary.
>

...except in the case where you are offline, then you won't have any styling
whatsoever unless you configured a custom local location for the css file. 
Seriously, the defaults shouldn't be confusing.  If they are, then the styles
weren't written properly.  That's a development issue, not a user issue.  The
linked stylesheet should only be for overriding defaults.  The HTML file ought
to be able to be used in standalone mode rather than counting on an external
resource for any formatting.


>
> --
> Ceki Gülcü


Jake

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


RE: EnhancedHTMLAppender

Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Steve,

At 02:31 AM 9/8/2004, you wrote:
>Long time no speak,
>
>I've been very slack on this front and as it seems that 1.3 is gathering
>steam to get released I hope to get the EnhancedHTMLAppender completed in
>the next week.
>
>After leaving it so long, and having to re-read the discussion to work out
>where we were up to I think its time to solve this CSS issue.
>
>My suggestion is to hard-code styles into the top of the style sheet and
>provide the user a property to change a link to override the default styles,
>as suggested here:
>
> > ><HEAD>
> > >   <STYLE TYPE="text/css">
> > >     <!--
> > >       BODY { background-color: white }
> > >     -->
> > >   </STYLE>
> > >   <LINK REL=StyleSheet HREF="http://apache.org/~ceki/yellow.css"
> > > TITLE="Basic"/>
> > ></HEAD>

Well, the above probably not such a good idea because the rules for style 
cascades are not that simple. Later rules add up on earlier rules except if 
they contain already existing properties in which case they mask older 
properties. In short, if there are more than one source for styles most 
users are likely to get very confused. We don't want to mislead or confuse 
users whenever we can help it.

The best solution I can think of consist of linking to a style located at a 
well-known URL by default but allow the user to override that default by 
specifying an alternative URL if need be. This approach will work out of 
the box in 95% of the cases and still allow developers to handle 
exceptional cases when necessary.


>I'll update the code over the next few days to support this and get an
>update file posted back to the list.
>
>Sorry for the HUGE delay,
>
>Steve

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org