You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Bert Van Kets <be...@dream-models.com> on 2002/05/23 11:25:55 UTC
HTML/CSS and graphics
Just checked out the primer doc. Wow, you guys have moved fast. Got to
keep this version in archives (with the smiley) ;-)
I saw forrest is looking for "Graphical whizzkids for true cross-browser
HTML/CSS development"
Although I'm not a kid at age 35 I do have a LOT of HTML, CSS experiance
and a graphical background (incl. 3D). I guess my pretty young experience
with Cocoon might help too. I'm very familiar with XSLT, but haven't done
any *real* Java programming in Cocoon yet. That's planned for the late summer.
I'll keep lurking on the list and see what I can help with.
Keep up the good work.
Bert
RE: HTML/CSS and graphics
Posted by Steven Noels <st...@outerthought.org>.
> From: Bert Van Kets [mailto:bert@dream-models.com]
>
> P.S. Were are you from. I'm working in Leuven, but live in Bonheiden
Ghent.
Cheers,
</Steven>
RE: HTML/CSS and graphics
Posted by Bert Van Kets <be...@dream-models.com>.
I guess Rob is on this list too. I'll leave it up to Rob to contact me,
since he was first. In the mean time I'll try to figure out what exists and
what still needs to be done. If I can get Frederic Robesyn (see my other
mail) engaged too, things will move pretty quickly in the graphical, HTML way.
Bert
P.S. Were are you from. I'm working in Leuven, but live in Bonheiden
At 12:21 23/05/2002 +0200, you wrote:
> > From: Bert Van Kets [mailto:bert@dream-models.com]
>
> > Although I'm not a kid at age 35 I do have a LOT of HTML, CSS
> > experiance
> > and a graphical background (incl. 3D). I guess my pretty
> > young experience
> > with Cocoon might help too. I'm very familiar with XSLT, but
> > haven't done
> > any *real* Java programming in Cocoon yet. That's planned
> > for the late summer.
> >
> > I'll keep lurking on the list and see what I can help with.
>
>Another idea is to get in touch with Rob Koberg (rob@koberg.com), who
>has agreed yesterday to work on the main Forrest skin "when time
>permitted". Maybe the two of you can work on that time permission
>together ;-)
>
>Nice to (almost) have another Belgian guy on board :-)
>
></Steven>
Re: HTML/CSS and graphics
Posted by Bert Van Kets <be...@vankets.com>.
At 14:03 24/05/2002 +1000, you wrote:
>Bert Van Kets wrote:
> > <snip/>
> >
> > >Am I to understand that the design is not final and can be changed?
> >
> > From what I understand the current forrest skin is a mere pure html/scc
> > version and needs to be updated using the provided PSD files (design from
> > Stefano and girl friend).
> >
> > I volunteered for this job. What are your ideas on this task?
> > Bert
>
>The initial design from Stefano was to get something started
>and provide a bit of direction. We can do whatever we like.
>There is no need to stick entirely to that design. The general
>principles apply though.
>
>There is a lot of discussion about this in forrest-dev email
>archives. Here is one ...
> Re: [LAYOUT] page.html created
> http://marc.theaimsgroup.com/?l=forrest-dev&m=101645858210693
>... other discussion in early-March to mid-March.
>
>My ideas for this task are to ensure clean and fast pages
>that do not use too much CSS trickery that fails on older
>browsers.
>--David
My thoughts exactly! If you add perceptive download speed (the speed a
user perceives the page, not the exact total download speed), we're
there. If I can get 1 Java problem solved soon I'm starting on my forrest
work.
Bert
Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS
and graphics
Posted by Bert Van Kets <be...@vankets.com>.
At 02:51 24/05/2002 -0700, you wrote:
>Hi folks,
>
>Steven Noels wrote:
>
>>On Thu, 23 May 2002, Robert Koberg wrote:
>>
>>
>>
>>>>If they can create their own XSLT, perhaps there should be
>>>>xml-apache-rules (already in place?) about xsl:include vs. xsl:import
>>>>and/or using a priority attribute on a template rule to override the
>>>>base set of XSL.
>>>>
>>
>>We should be cautious on xsl:import/include since this conflicts with
>>stylesheet caching... same with the document() function - to be avoided
>>if possible. Think about this before choosing a direction.
>
>I have been looking for a way to use componetized XSLTs without
>include/import. I see how Forrest uses book2menu which does an inital
>transformation producing a new result which is then transformed again. Is
>this considered the correct way to handle component XSLT?
>
>Someone on the user list suggested that I use a pipeline to aggregate the
>XSLT, is there an example or thread you can point me to (I cannot find
>info and can't find it in my hacking)?
IMHO The best way of putting things together in Cocoon (Forrest is a Cocoon
implementation/application) is using pipelines. The docs section of the
Cocoon site is built up this way. Check out the sitemap in the
Cocoon/documentation directory.
If you really need to merge XSLT's you need to have a look at
<map:transform src="cocoon:/yourpipeline"/> where "yourpipeline" points to
a pipeline called "yourpipeline". In that pipeline you aggregate the
different XSLT's. XSLT is after all a form of XML.
Bert
Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and
graphics
Posted by Robert Koberg <ro...@koberg.com>.
Yes, I quickly skimmed a great deal of pages looking for something that
talked about using multiple XSLT on the same source file. I see how and
understand what is happening in forrest. I just don't see the benefit of
transforming into several intermediate stages.
I just wanted to give some XSLT to the group. I probably need to back
down and learn more about cocoon before providing any more files. I was
thinking I could get up and running faster...
Wondering out loud.... why do I need to know about the sitemap to patch
XSLT? Where is the separation of concerns?
best,
-Rob
Steven Noels wrote:
>Rob,
>
>
>
>>From: Robert Koberg [mailto:rob@koberg.com]
>>
>>
>
><snip/>
>
>
>
>>I must be missing something. What is the best (Forrest) way to bring
>>together component XSLT?
>>
>>
>
>be sure you have read and understood
>http://xml.apache.org/cocoon/userdocs/concepts/index.html and
>http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (especially
>the section on Aggregation and Resources) prior to go in and try to
>patch Forrest. The Forrest Primer
>(http://xml.apache.org/forrest/primer.html) might help, also.
>
>Sitemap aggregation and XSLT import/include have nothing to do with each
>other.
>
></Steven>
>
>
>
RE: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics
Posted by Steven Noels <st...@outerthought.org>.
Rob,
> From: Robert Koberg [mailto:rob@koberg.com]
<snip/>
> I must be missing something. What is the best (Forrest) way to bring
> together component XSLT?
be sure you have read and understood
http://xml.apache.org/cocoon/userdocs/concepts/index.html and
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (especially
the section on Aggregation and Resources) prior to go in and try to
patch Forrest. The Forrest Primer
(http://xml.apache.org/forrest/primer.html) might help, also.
Sitemap aggregation and XSLT import/include have nothing to do with each
other.
</Steven>
Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and
graphics
Posted by Robert Koberg <ro...@koberg.com>.
Hi folks,
Steven Noels wrote:
>On Thu, 23 May 2002, Robert Koberg wrote:
>
>
>
>>>If they can create their own XSLT, perhaps there should be
>>>xml-apache-rules (already in place?) about xsl:include vs. xsl:import
>>>and/or using a priority attribute on a template rule to override the
>>>base set of XSL.
>>>
>>>
>
>We should be cautious on xsl:import/include since this conflicts with
>stylesheet caching... same with the document() function - to be avoided if
>possible. Think about this before choosing a direction.
>
I have been looking for a way to use componetized XSLTs without
include/import. I see how Forrest uses book2menu which does an inital
transformation producing a new result which is then transformed again.
Is this considered the correct way to handle component XSLT?
Someone on the user list suggested that I use a pipeline to aggregate
the XSLT, is there an example or thread you can point me to (I cannot
find info and can't find it in my hacking)?
At this time, I am seeing this as a perfect job for include or import. I
assume the problem is that it is considered combining concerns. But
performing multiple transformations, all the while producing new XML for
the next transformation seems confusing, especially if there were
several XSLT components.
I must be missing something. What is the best (Forrest) way to bring
together component XSLT?
thanks for any info,
-Rob
Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and
graphics
Posted by Steven Noels <st...@outerthought.org>.
On Thu, 23 May 2002, Robert Koberg wrote:
> nevermind... I am ready the docs and checking out the directories - my
> questions are being answered... sorry for the bother
There are some interesting thoughts in it however, so let me please try to
comment on them.
> > Will xml.apache.org projects create their own look and feel? Will all
> > xml.apache.org projects use the same XSL?
One of the design goals is to have a consistent look & feel for the entire
XML apache site, so yes, let's assume this. I am preparing a forrest.xml
descriptor file however, and I am assuming we have non-Forrest
documentation parts, too (static HTML, i.e. JavaDoc as long as we don't do
something with it ourselves). Another option would be that projects can
choose their own skin, but that's in contrast with the original goals.
Anyone comments on that? What about non-XML Apache projects?
My position would be to say: they have to build a Forrest *skin* if they
don't like what we provide - not just a loose collection of XSLT
stylesheets. We have to make sure skins external to Forrest can be used,
too.
> > If used across all xml-projects, and if they create their own L&F,
> > what can they change (just CSS? XSL?)?
See above. Skin will be the unit of containment.
> > If they can create their own XSLT, perhaps there should be
> > xml-apache-rules (already in place?) about xsl:include vs. xsl:import
> > and/or using a priority attribute on a template rule to override the
> > base set of XSL.
We should be cautious on xsl:import/include since this conflicts with
stylesheet caching... same with the document() function - to be avoided if
possible. Think about this before choosing a direction.
> > -- xsl:include used for things that should never be changed (examples:
> > copyright, nav)
> > -- xsl:import used for things that can be overriden
> > -- or, perhaps just have the project create a high priority on a
> > template rule so they override the base set. This makes me think of
> > another question:
> > Is there some facility in place (or planned) to check a project
> > directory and see if they have XSL that should be used to override the
> > base set?
As above, I will add a skin parameter to forrest.xml to addresses this.
> > -- (perhaps this has already been said??) I suggest including a
> > 'global_definitions.xsl' (or named whatever) from each of the project
> > sites into a base set of XSL. A project has control over the file and
> > can include/import/prioritize anyway they want - within the rules.
> > -- there would also be a global_defintions.xsl for each of the
> > projects in the base set of XSL. These import/include all of the
> > common XSL. make sense?
> >
</Steven>
Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and
graphics
Posted by Robert Koberg <ro...@koberg.com>.
nevermind... I am ready the docs and checking out the directories - my
questions are being answered... sorry for the bother
-Rob
Robert Koberg wrote:
> Hi all,
>
> Bert Van Kets wrote:
>
>>
>> I volunteered for this job. What are your ideas on this task?
>
>
> ------- General XSL Structure ---------
>
> Will xml.apache.org projects create their own look and feel? Will all
> xml.apache.org projects use the same XSL?
> If used across all xml-projects, and if they create their own L&F,
> what can they change (just CSS? XSL?)?
> If they can create their own XSLT, perhaps there should be
> xml-apache-rules (already in place?) about xsl:include vs. xsl:import
> and/or using a priority attribute on a template rule to override the
> base set of XSL.
> -- xsl:include used for things that should never be changed (examples:
> copyright, nav)
> -- xsl:import used for things that can be overriden
> -- or, perhaps just have the project create a high priority on a
> template rule so they override the base set. This makes me think of
> another question:
> Is there some facility in place (or planned) to check a project
> directory and see if they have XSL that should be used to override the
> base set?
> -- (perhaps this has already been said??) I suggest including a
> 'global_definitions.xsl' (or named whatever) from each of the project
> sites into a base set of XSL. A project has control over the file and
> can include/import/prioritize anyway they want - within the rules.
> -- there would also be a global_defintions.xsl for each of the
> projects in the base set of XSL. These import/include all of the
> common XSL. make sense?
>
> what do you think?
>
> -Rob
>
>
>
>
>
>
>
>
[RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics
Posted by Robert Koberg <ro...@koberg.com>.
Hi all,
Bert Van Kets wrote:
>
> I volunteered for this job. What are your ideas on this task?
------- General XSL Structure ---------
Will xml.apache.org projects create their own look and feel? Will all
xml.apache.org projects use the same XSL?
If used across all xml-projects, and if they create their own L&F, what
can they change (just CSS? XSL?)?
If they can create their own XSLT, perhaps there should be
xml-apache-rules (already in place?) about xsl:include vs. xsl:import
and/or using a priority attribute on a template rule to override the
base set of XSL.
-- xsl:include used for things that should never be changed (examples:
copyright, nav)
-- xsl:import used for things that can be overriden
-- or, perhaps just have the project create a high priority on a
template rule so they override the base set. This makes me think of
another question:
Is there some facility in place (or planned) to check a project
directory and see if they have XSL that should be used to override the
base set?
-- (perhaps this has already been said??) I suggest including a
'global_definitions.xsl' (or named whatever) from each of the project
sites into a base set of XSL. A project has control over the file and
can include/import/prioritize anyway they want - within the rules.
-- there would also be a global_defintions.xsl for each of the projects
in the base set of XSL. These import/include all of the common XSL. make
sense?
what do you think?
-Rob
Re: HTML/CSS and graphics
Posted by David Crossley <cr...@indexgeo.com.au>.
Bert Van Kets wrote:
> <snip/>
>
> >Am I to understand that the design is not final and can be changed?
>
> From what I understand the current forrest skin is a mere pure html/scc
> version and needs to be updated using the provided PSD files (design from
> Stefano and girl friend).
>
> I volunteered for this job. What are your ideas on this task?
> Bert
The initial design from Stefano was to get something started
and provide a bit of direction. We can do whatever we like.
There is no need to stick entirely to that design. The general
principles apply though.
There is a lot of discussion about this in forrest-dev email
archives. Here is one ...
Re: [LAYOUT] page.html created
http://marc.theaimsgroup.com/?l=forrest-dev&m=101645858210693
... other discussion in early-March to mid-March.
My ideas for this task are to ensure clean and fast pages
that do not use too much CSS trickery that fails on older
browsers.
--David
Re: HTML/CSS and graphics
Posted by Bert Van Kets <be...@vankets.com>.
<snip/>
>just waking up... you euro's always post at the wrong time of day :-D
Who says we are waking up too early??? :-D
>I have some learning to do. I am going to spend the day (as much as
>possible) on this. Was not able to do anything last night. I have talked
>to my partner (/ boss /girlfriend) and we agred it is time to get more
>involved with cocoon. So the user list will probably be seeing some dumb
>questions from me.
>
>Am I to understand that the design is not final and can be changed?
From what I understand the current forrest skin is a mere pure html/scc
version and needs to be updated using the provided PSD files (design from
Stefano and girl friend).
I volunteered for this job. What are your ideas on this task?
Bert
Re: HTML/CSS and graphics
Posted by Robert Koberg <ro...@koberg.com>.
Steven Noels wrote:
>>From: Bert Van Kets [mailto:bert@dream-models.com]
>>
>>
>
>
>
>>Although I'm not a kid at age 35 I do have a LOT of HTML, CSS
>>experiance
>>and a graphical background (incl. 3D). I guess my pretty
>>young experience
>>with Cocoon might help too. I'm very familiar with XSLT, but
>>haven't done
>>any *real* Java programming in Cocoon yet. That's planned
>>for the late summer.
>>
>>I'll keep lurking on the list and see what I can help with.
>>
>>
>
>Another idea is to get in touch with Rob Koberg (rob@koberg.com), who
>has agreed yesterday to work on the main Forrest skin "when time
>permitted". Maybe the two of you can work on that time permission
>together ;-)
>
just waking up... you euro's always post at the wrong time of day :-D
I have some learning to do. I am going to spend the day (as much as
possible) on this. Was not able to do anything last night. I have talked
to my partner (/ boss /girlfriend) and we agred it is time to get more
involved with cocoon. So the user list will probably be seeing some dumb
questions from me.
Am I to understand that the design is not final and can be changed?
best,
-Rob
RE: HTML/CSS and graphics
Posted by Steven Noels <st...@outerthought.org>.
> From: Bert Van Kets [mailto:bert@dream-models.com]
> Although I'm not a kid at age 35 I do have a LOT of HTML, CSS
> experiance
> and a graphical background (incl. 3D). I guess my pretty
> young experience
> with Cocoon might help too. I'm very familiar with XSLT, but
> haven't done
> any *real* Java programming in Cocoon yet. That's planned
> for the late summer.
>
> I'll keep lurking on the list and see what I can help with.
Another idea is to get in touch with Rob Koberg (rob@koberg.com), who
has agreed yesterday to work on the main Forrest skin "when time
permitted". Maybe the two of you can work on that time permission
together ;-)
Nice to (almost) have another Belgian guy on board :-)
</Steven>