[Trinidad] added browser version support in skinning TRINIDAD-799

[Cristi Toth]

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Blake Sullivan]

Cristi,

I think that we should follow a subset of the syntax of CSS Media Queries for consistency as this is a CSS file.  If there are other standard syntaxes for CSS, we can use one of those instead.

Your rule below could be expressed in such a syntax as:

@agent ie and (min-version:5) and (max-version:7), gecko, safari

Assuming that we chose a convenient definition for ma-version (that it includes all version up to but not including an increment of the smallest specified digit.  so that max-version:7 really means version < 8,  while max-version 7.5 really means version < 7.6)

-- Blake Sullivan



Cristi Toth said the following On 4/16/2008 3:24 PM PT:

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Cristi Toth]

Hi Blake,

I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.

But it's a good idea to follow a (possible) future standard.
I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)

@Andrew
Currently (and in the XSS format) version is compared with TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed string.
I don't know what it means, but I assume it's very browser dependent.
But do you see a use-case  when you would need different css for minor versions?
Like a difference between IE 5.0 and 5.5 ?

It would be nice to get to a final conclusion,
so I can update this solution before the next release.

regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi,

I think that we should follow a subset of the syntax of CSS Media Queries for consistency as this is a CSS file.  If there are other standard syntaxes for CSS, we can use one of those instead.

Your rule below could be expressed in such a syntax as:

@agent ie and (min-version:5) and (max-version:7), gecko, safari

Assuming that we chose a convenient definition for ma-version (that it includes all version up to but not including an increment of the smallest specified digit.  so that max-version:7 really means version < 8,  while max-version 7.5 really means version < 7.6)

-- Blake Sullivan



Cristi Toth said the following On 4/16/2008 3:24 PM PT:

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Blake Sullivan]

Cristi Toth said the following On 4/16/2008 5:34 PM PT:

Hi Blake,

I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.

But it's a good idea to follow a (possible) future standard.

I agree. While still only a candidate recommendation, the goal of the Trinidad CSS syntax has always been to be forward looking (thus the use of CSS3-style namespaces).  As the media query syntax is by far the most likely syntax to be specified, we should go with that syntax over one  of our own design.  That both Opera and WebKit have bothered to implement the specification is also a good sign.

I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)

I didn't see one, but I don't think that you really want a list here anyway.  Don't you really want all versions of IE >= 5 and < 8?

I think my proposal for abusing a definition of max-version is weak (the specification discussion is pretty clear the "min-" prefix means >= and the "max-" prefix means <=).  So I think that a more explicit feature suffix would be better.  For example:

@agent ie and (min-version:5) and (max-version-less-than:8), gecko, safari

@Andrew
Currently (and in the XSS format) version is compared with TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed string.
I don't know what it means, but I assume it's very browser dependent.

Determining a floating point browser version isn't a technical problem and should be supported.  The Gecko engine is an example of an engine that adds CSS features in point releases 1.8 -> 1.9 for example.

-- Blake Sullivan

But do you see a use-case  when you would need different css for minor versions?
Like a difference between IE 5.0 and 5.5 ?

It would be nice to get to a final conclusion,
so I can update this solution before the next release.

regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi,

I think that we should follow a subset of the syntax of CSS Media Queries for consistency as this is a CSS file.  If there are other standard syntaxes for CSS, we can use one of those instead.

Your rule below could be expressed in such a syntax as:

@agent ie and (min-version:5) and (max-version:7), gecko, safari

Assuming that we chose a convenient definition for ma-version (that it includes all version up to but not including an increment of the smallest specified digit.  so that max-version:7 really means version < 8,  while max-version 7.5 really means version < 7.6)

-- Blake Sullivan



Cristi Toth said the following On 4/16/2008 3:24 PM PT:

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Cristi Toth]

On Thu, Apr 17, 2008 at 8:04 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi Toth said the following On 4/16/2008 5:34 PM PT:

Hi Blake,

I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.

But it's a good idea to follow a (possible) future standard.

I agree. While still only a candidate recommendation, the goal of the Trinidad CSS syntax has always been to be forward looking (thus the use of CSS3-style namespaces).  As the media query syntax is by far the most likely syntax to be specified, we should go with that syntax over one  of our own design.  That both Opera and WebKit have bothered to implement the specification is also a good sign.

I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)

I didn't see one, but I don't think that you really want a list here anyway.  Don't you really want all versions of IE >= 5 and < 8?

Let's say that  any list could be defined  like several  intervals, but it would have been more flexible.

I think my proposal for abusing a definition of max-version is weak (the specification discussion is pretty clear the "min-" prefix means >= and the "max-" prefix means <=).  So I think that a more explicit feature suffix would be better.  For example:

@agent ie and (min-version:5) and (max-version-less-than:8), gecko, safari

max...less-than sounds a little bit redundant
maybe something like (version-lt:8) , in general 'version-' followed by an EL comparison operator (eq, ne, lt, le, gt, ge)?
what do you say ?

@Andrew
Currently (and in the XSS format) version is compared with TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed string.
I don't know what it means, but I assume it's very browser dependent.

Determining a floating point browser version isn't a technical problem and should be supported.  The Gecko engine is an example of an engine that adds CSS features in point releases 1.8 -> 1.9 for example.

At least what I could do for now is to support Double instead of Integer
but what if some agents have versions like dates or text?
I'm not aware of how most of the browsers define their version
and I wouldn't want to mess up TrinidadAgent right now, seeing that nobody asked for this feature until now.
My goal was only to add the feature that was supported in the XSS.
Does anyone know more details about agent's versions in general?

-- Blake Sullivan

But do you see a use-case  when you would need different css for minor versions?
Like a difference between IE 5.0 and 5.5 ?

It would be nice to get to a final conclusion,
so I can update this solution before the next release.

regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi,

I think that we should follow a subset of the syntax of CSS Media Queries for consistency as this is a CSS file.  If there are other standard syntaxes for CSS, we can use one of those instead.

Your rule below could be expressed in such a syntax as:

@agent ie and (min-version:5) and (max-version:7), gecko, safari

Assuming that we chose a convenient definition for ma-version (that it includes all version up to but not including an increment of the smallest specified digit.  so that max-version:7 really means version < 8,  while max-version 7.5 really means version < 7.6)

-- Blake Sullivan



Cristi Toth said the following On 4/16/2008 3:24 PM PT:

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Blake Sullivan]

Cristi Toth said the following On 4/16/2008 11:32 PM PT:

On Thu, Apr 17, 2008 at 8:04 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi Toth said the following On 4/16/2008 5:34 PM PT:

Hi Blake,

I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.

But it's a good idea to follow a (possible) future standard.

I agree. While still only a candidate recommendation, the goal of the Trinidad CSS syntax has always been to be forward looking (thus the use of CSS3-style namespaces).  As the media query syntax is by far the most likely syntax to be specified, we should go with that syntax over one  of our own design.  That both Opera and WebKit have bothered to implement the specification is also a good sign.

I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)

I didn't see one, but I don't think that you really want a list here anyway.  Don't you really want all versions of IE >= 5 and < 8?

Let's say that  any list could be defined  like several  intervals, but it would have been more flexible.

I think my proposal for abusing a definition of max-version is weak (the specification discussion is pretty clear the "min-" prefix means >= and the "max-" prefix means <=).  So I think that a more explicit feature suffix would be better.  For example:

@agent ie and (min-version:5) and (max-version-less-than:8), gecko, safari

max...less-than sounds a little bit redundant
maybe something like (version-lt:8) , in general 'version-' followed by an EL comparison operator (eq, ne, lt, le, gt, ge)?
what do you say ?

that sounds fine, though -eq,-le, and -ge are all rendundant with specified syntax.

--Blake Sullivan

@Andrew
Currently (and in the XSS format) version is compared with TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed string.
I don't know what it means, but I assume it's very browser dependent.

Determining a floating point browser version isn't a technical problem and should be supported.  The Gecko engine is an example of an engine that adds CSS features in point releases 1.8 -> 1.9 for example.

At least what I could do for now is to support Double instead of Integer
but what if some agents have versions like dates or text?
I'm not aware of how most of the browsers define their version
and I wouldn't want to mess up TrinidadAgent right now, seeing that nobody asked for this feature until now.
My goal was only to add the feature that was supported in the XSS.
Does anyone know more details about agent's versions in general?

-- Blake Sullivan

But do you see a use-case  when you would need different css for minor versions?
Like a difference between IE 5.0 and 5.5 ?

It would be nice to get to a final conclusion,
so I can update this solution before the next release.

regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan <blake.sullivan@...> wrote:

Cristi,

I think that we should follow a subset of the syntax of CSS Media Queries for consistency as this is a CSS file.  If there are other standard syntaxes for CSS, we can use one of those instead.

Your rule below could be expressed in such a syntax as:

@agent ie and (min-version:5) and (max-version:7), gecko, safari

Assuming that we chose a convenient definition for ma-version (that it includes all version up to but not including an increment of the smallest specified digit.  so that max-version:7 really means version < 8,  while max-version 7.5 really means version < 7.6)

-- Blake Sullivan



Cristi Toth said the following On 4/16/2008 3:24 PM PT:

Hi guys,

I finally added browser version support in skinning, but using a different format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I have chosen to use this format:

@ agent ie 5 6 7, gecko,safari {....}

So each agent definition separated by comma and the versions a space separated list following the browser type.

Also in the code I replaced :
int[] browsers
int[] versions
with :
Map <Integer, Set<Integer>> browsers

this represents browser types mapped to their versions set.


If you have any objections on this, please reopen the issue and add some comments

Regards,
--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

--
Cristi Toth

-------------
Codebeat
www.codebeat.ro

[Andrew Robinson-5]

I would like to have:

1) Major and Major.Minor support
2) A syntax that is already supported by CSS @ styles in at least one
browser or as close as we can come
3) Range, greater than and less than if possible

#2 I think is really important so that skinning feels familiar to CSS
developers.

If the solution meets those needs, I will be very happy, but others
can decide on the exact syntax, I'm flexible

-Andrew

On Thu, Apr 17, 2008 at 12:51 AM, Blake Sullivan
<blake.sullivan@...> wrote:

>
>  Cristi Toth said the following On 4/16/2008 11:32 PM PT:
>
>
> On Thu, Apr 17, 2008 at 8:04 AM, Blake Sullivan <blake.sullivan@...>
> wrote:
>
> >
> > Cristi Toth said the following On 4/16/2008 5:34 PM PT:
> >
> > Hi Blake,
> >
> > I wanted to be backwards compatible with what the XSS offered.
> > So I assumed that we's want just a list (not necessarily an interval)
> > And I picked the easiest to parse format.
> >
> > But it's a good idea to follow a (possible) future standard.
> > I agree. While still only a candidate recommendation, the goal of the
> Trinidad CSS syntax has always been to be forward looking (thus the use of
> CSS3-style namespaces).  As the media query syntax is by far the most likely
> syntax to be specified, we should go with that syntax over one  of our own
> design.  That both Opera and WebKit have bothered to implement the
> specification is also a good sign.
> >
> >
> > I had a quick look over it's syntax, but not enough.
> > Isn't there a way to have a list of numbers?
> > smth like : @agent ie (version: 5 7)
> > I didn't see one, but I don't think that you really want a list here
> anyway.  Don't you really want all versions of IE >= 5 and < 8?
> >
>
>
>  Let's say that  any list could be defined  like several  intervals, but it
> would have been more flexible.
>
> >
> >
> > I think my proposal for abusing a definition of max-version is weak (the
> specification discussion is pretty clear the "min-" prefix means >= and the
> "max-" prefix means <=).  So I think that a more explicit feature suffix
> would be better.  For example:
> >
> > @agent ie and (min-version:5) and (max-version-less-than:8), gecko, safari
>
>
>  max...less-than sounds a little bit redundant
>  maybe something like (version-lt:8) , in general 'version-' followed by an
> EL comparison operator (eq, ne, lt, le, gt, ge)?
>  what do you say ?
>  that sounds fine, though -eq,-le, and -ge are all rendundant with specified
> syntax.
>
>  --Blake Sullivan
>
>
>
>
>
>
> >
> >
> >
> >
> > @Andrew
> > Currently (and in the XSS format) version is compared with
> TrinidadAgent.getAgentMajorVersion()
> > it also has a getAgentVersion() method that returns the full unparsed
> string.
> > I don't know what it means, but I assume it's very browser dependent.
> >
>
> >
> > Determining a floating point browser version isn't a technical problem and
> should be supported.  The Gecko engine is an example of an engine that adds
> CSS features in point releases 1.8 -> 1.9 for example.
> >
>
> At least what I could do for now is to support Double instead of Integer
>  but what if some agents have versions like dates or text?
>  I'm not aware of how most of the browsers define their version
>  and I wouldn't want to mess up TrinidadAgent right now, seeing that nobody
> asked for this feature until now.
>  My goal was only to add the feature that was supported in the XSS.
>  Does anyone know more details about agent's versions in general?
>
>
> >
> >
> > -- Blake Sullivan
> >
> >
> >
> > But do you see a use-case  when you would need different css for minor
> versions?
> > Like a difference between IE 5.0 and 5.5 ?
> >
> > It would be nice to get to a final conclusion,
> > so I can update this solution before the next release.
> >
> > regards,
> > --
> > Cristi Toth
> >
> > -------------
> > Codebeat
> > www.codebeat.ro
> >
> > On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan
> <blake.sullivan@...> wrote:
> >
> > >
> > > Cristi,
> > >
> > > I think that we should follow a subset of the syntax of CSS Media
> Queries for consistency as this is a CSS file.  If there are other standard
> syntaxes for CSS, we can use one of those instead.
> > >
> > > Your rule below could be expressed in such a syntax as:
> > >
> > > @agent ie and (min-version:5) and (max-version:7), gecko, safari
> > >
> > > Assuming that we chose a convenient definition for ma-version (that it
> includes all version up to but not including an increment of the smallest
> specified digit.  so that max-version:7 really means version < 8,  while
> max-version 7.5 really means version < 7.6)
> > >
> > > -- Blake Sullivan
> > >
> > >
> > >
> > > Cristi Toth said the following On 4/16/2008 3:24 PM PT:
> > >
> > >
> > > Hi guys,
> > >
> > > I finally added browser version support in skinning, but using a
> different format than first suggested.
> > > As we needed to support multiple browsers, each with multiple versions,
> I have chosen to use this format:
> > >
> > > @ agent ie 5 6 7, gecko,safari {....}
> > >
> > > So each agent definition separated by comma and the versions a space
> separated list following the browser type.
> > >
> > > Also in the code I replaced :
> > > int[] browsers
> > > int[] versions
> > > with :
> > > Map <Integer, Set<Integer>> browsers
> > >
> > > this represents browser types mapped to their versions set.
> > >
> > >
> > > If you have any objections on this, please reopen the issue and add some
> comments
> > >
> > > Regards,
> > > --
> > > Cristi Toth
> > >
> > > -------------
> > > Codebeat
> > > www.codebeat.ro
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>  --
>  Cristi Toth
>
>  -------------
>  Codebeat
>  www.codebeat.ro
>

[Andy Schwartz]

On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
<andrew.rw.robinson@...> wrote:
> I would like to have:
>
>  1) Major and Major.Minor support
>  2) A syntax that is already supported by CSS @ styles in at least one
>  browser or as close as we can come
>  3) Range, greater than and less than if possible

These all sound good to me.  The underlying style handling layer (the
old XSS stuff) was never designed to support #1 or #3, but think it
would be worthwhile to see what we can do to address these.

>
>  #2 I think is really important so that skinning feels familiar to CSS
>  developers.
>
>  If the solution meets those needs, I will be very happy, but others
>  can decide on the exact syntax, I'm flexible

I've got a process question here, which I am a bit hesitant to ask
given our recent "discussions", but, well, what the heck... Shouldn't
we be discussing/reviewing such requirements/API additions before the
changes are committed to the trunks?  Not that I am not grateful that
Cristi has invested the time on providing a solution (thanks for doing
this Cristi!).  I am just wondering whether in general it would be
better to review/agree on new APIs before they get committed.

Does Trinidad (or MyFaces) have any policy/guidelines on how new
API/feature additions should be handled?  Not picking on Cristi here -
I recently added some new skinning features myself and wasn't sure
whether there were some specific steps that I needed to follow.

Andy

[Matthias Wessendorf-4]

Hi,

On Thu, Apr 17, 2008 at 5:47 PM, Andy Schwartz
<andy.g.schwartz@...> wrote:

> On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
>  <andrew.rw.robinson@...> wrote:
>  > I would like to have:
>  >
>  >  1) Major and Major.Minor support
>  >  2) A syntax that is already supported by CSS @ styles in at least one
>  >  browser or as close as we can come
>  >  3) Range, greater than and less than if possible
>
>  These all sound good to me.  The underlying style handling layer (the
>  old XSS stuff) was never designed to support #1 or #3, but think it
>  would be worthwhile to see what we can do to address these.
>
>
>  >
>  >  #2 I think is really important so that skinning feels familiar to CSS
>  >  developers.
>  >
>  >  If the solution meets those needs, I will be very happy, but others
>  >  can decide on the exact syntax, I'm flexible
>
>  I've got a process question here, which I am a bit hesitant to ask
>  given our recent "discussions", but, well, what the heck... Shouldn't
>  we be discussing/reviewing such requirements/API additions before the
>  changes are committed to the trunks?  Not that I am not grateful that

at least (I personally think) having a "I am about to commit this" is not a
bad thing (tm)

>  Cristi has invested the time on providing a solution (thanks for doing
>  this Cristi!).  I am just wondering whether in general it would be
>  better to review/agree on new APIs before they get committed.
>
>  Does Trinidad (or MyFaces) have any policy/guidelines on how new
>  API/feature additions should be handled?  Not picking on Cristi here -

Nope. Not that I know. Some other Apache projects have; some not.
I think that for adding new APIs, we might want that we at least get
an alert before :-)

>  I recently added some new skinning features myself and wasn't sure
>  whether there were some specific steps that I needed to follow.

haven't you ping the mailing list? If not, go ahead !

If it is just still in jira, well... it can be
there for a while. Bug trackers aren't that cool for discussions. Mailing
list are (I hate forums)

-M
>
>  Andy
>

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Scott O'Bryan]

MyFaces Core and the Portlet Bridge have an API policy in that the API
is dictated by a Portlet Bridge spec.  They don't have any guidelines in
IMPL though.  I think the majority of the projects rely on the
committeers to review and test any additions.

But like Matthias said, it's a good idea to bring it up in an email.  
Stuff tends to be better when the community is involved.

Scott

Matthias Wessendorf wrote:

> Hi,
>
> On Thu, Apr 17, 2008 at 5:47 PM, Andy Schwartz
> <andy.g.schwartz@...> wrote:
>  
>> On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
>>  <andrew.rw.robinson@...> wrote:
>>  > I would like to have:
>>  >
>>  >  1) Major and Major.Minor support
>>  >  2) A syntax that is already supported by CSS @ styles in at least one
>>  >  browser or as close as we can come
>>  >  3) Range, greater than and less than if possible
>>
>>  These all sound good to me.  The underlying style handling layer (the
>>  old XSS stuff) was never designed to support #1 or #3, but think it
>>  would be worthwhile to see what we can do to address these.
>>
>>
>>  >
>>  >  #2 I think is really important so that skinning feels familiar to CSS
>>  >  developers.
>>  >
>>  >  If the solution meets those needs, I will be very happy, but others
>>  >  can decide on the exact syntax, I'm flexible
>>
>>  I've got a process question here, which I am a bit hesitant to ask
>>  given our recent "discussions", but, well, what the heck... Shouldn't
>>  we be discussing/reviewing such requirements/API additions before the
>>  changes are committed to the trunks?  Not that I am not grateful that
>>    
>
> at least (I personally think) having a "I am about to commit this" is not a
> bad thing (tm)
>
>  
>>  Cristi has invested the time on providing a solution (thanks for doing
>>  this Cristi!).  I am just wondering whether in general it would be
>>  better to review/agree on new APIs before they get committed.
>>
>>  Does Trinidad (or MyFaces) have any policy/guidelines on how new
>>  API/feature additions should be handled?  Not picking on Cristi here -
>>    
>
> Nope. Not that I know. Some other Apache projects have; some not.
> I think that for adding new APIs, we might want that we at least get
> an alert before :-)
>
>  
>>  I recently added some new skinning features myself and wasn't sure
>>  whether there were some specific steps that I needed to follow.
>>    
>
> haven't you ping the mailing list? If not, go ahead !
>
> If it is just still in jira, well... it can be
> there for a while. Bug trackers aren't that cool for discussions. Mailing
> list are (I hate forums)
>
> -M
>  
>>  Andy
>>
>>    
>
>  

[Matthias Wessendorf-4]

> MyFaces Core and the Portlet Bridge have an API policy in that the API is
> dictated by a Portlet Bridge spec.  They don't have any guidelines in IMPL

yeah, spec impls (at least their APIs don't count).
It's time for a new lifecycle phase... :D

> though.  I think the majority of the projects rely on the committeers to
> review and test any additions.
yeah, less or more. Maven is pretty picky, so is Lucene.
But at the old job, we never had issues with incompatibility with
Lucene updates.

>  But like Matthias said, it's a good idea to bring it up in an email.  Stuff
> tends to be better when the community is involved.

yeah, jira is a bad discussion platform (at least for me)

-Matthias

>
>  Scott
>
>
>
>  Matthias Wessendorf wrote:
>
> > Hi,
> >
> > On Thu, Apr 17, 2008 at 5:47 PM, Andy Schwartz
> > <andy.g.schwartz@...> wrote:
> >
> >
> > > On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
> > >  <andrew.rw.robinson@...> wrote:
> > >  > I would like to have:
> > >  >
> > >  >  1) Major and Major.Minor support
> > >  >  2) A syntax that is already supported by CSS @ styles in at least
> one
> > >  >  browser or as close as we can come
> > >  >  3) Range, greater than and less than if possible
> > >
> > >  These all sound good to me.  The underlying style handling layer (the
> > >  old XSS stuff) was never designed to support #1 or #3, but think it
> > >  would be worthwhile to see what we can do to address these.
> > >
> > >
> > >  >
> > >  >  #2 I think is really important so that skinning feels familiar to
> CSS
> > >  >  developers.
> > >  >
> > >  >  If the solution meets those needs, I will be very happy, but others
> > >  >  can decide on the exact syntax, I'm flexible
> > >
> > >  I've got a process question here, which I am a bit hesitant to ask
> > >  given our recent "discussions", but, well, what the heck... Shouldn't
> > >  we be discussing/reviewing such requirements/API additions before the
> > >  changes are committed to the trunks?  Not that I am not grateful that
> > >
> > >
> >
> > at least (I personally think) having a "I am about to commit this" is not
> a
> > bad thing (tm)
> >
> >
> >
> > >  Cristi has invested the time on providing a solution (thanks for doing
> > >  this Cristi!).  I am just wondering whether in general it would be
> > >  better to review/agree on new APIs before they get committed.
> > >
> > >  Does Trinidad (or MyFaces) have any policy/guidelines on how new
> > >  API/feature additions should be handled?  Not picking on Cristi here -
> > >
> > >
> >
> > Nope. Not that I know. Some other Apache projects have; some not.
> > I think that for adding new APIs, we might want that we at least get
> > an alert before :-)
> >
> >
> >
> > >  I recently added some new skinning features myself and wasn't sure
> > >  whether there were some specific steps that I needed to follow.
> > >
> > >
> >
> > haven't you ping the mailing list? If not, go ahead !
> >
> > If it is just still in jira, well... it can be
> > there for a while. Bug trackers aren't that cool for discussions. Mailing
> > list are (I hate forums)
> >
> > -M
> >
> >
> > >  Andy
> > >
> > >
> > >
> >
> >
> >
>
>

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Scott O'Bryan]

Jira is nice if you want some comments to be kept with the bug.  This is
useful for commenting on tickets that do not have patches (and may not
for some time) so that when people finally do get around to it, they
have the information they need.

It is also good for documenting WHY something was done or maybe a
synopsis of the discussion (like a link or something), but the mailing
lists are absolutely the right place to do it.

Scott

Matthias Wessendorf wrote:

>> MyFaces Core and the Portlet Bridge have an API policy in that the API is
>> dictated by a Portlet Bridge spec.  They don't have any guidelines in IMPL
>>    
>
> yeah, spec impls (at least their APIs don't count).
> It's time for a new lifecycle phase... :D
>
>  
>> though.  I think the majority of the projects rely on the committeers to
>> review and test any additions.
>>    
> yeah, less or more. Maven is pretty picky, so is Lucene.
> But at the old job, we never had issues with incompatibility with
> Lucene updates.
>
>  
>>  But like Matthias said, it's a good idea to bring it up in an email.  Stuff
>> tends to be better when the community is involved.
>>    
>
> yeah, jira is a bad discussion platform (at least for me)
>
> -Matthias
>
>  
>>  Scott
>>
>>
>>
>>  Matthias Wessendorf wrote:
>>
>>    
>>> Hi,
>>>
>>> On Thu, Apr 17, 2008 at 5:47 PM, Andy Schwartz
>>> <andy.g.schwartz@...> wrote:
>>>
>>>
>>>      
>>>> On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
>>>>  <andrew.rw.robinson@...> wrote:
>>>>  > I would like to have:
>>>>  >
>>>>  >  1) Major and Major.Minor support
>>>>  >  2) A syntax that is already supported by CSS @ styles in at least
>>>>        
>> one
>>    
>>>>  >  browser or as close as we can come
>>>>  >  3) Range, greater than and less than if possible
>>>>
>>>>  These all sound good to me.  The underlying style handling layer (the
>>>>  old XSS stuff) was never designed to support #1 or #3, but think it
>>>>  would be worthwhile to see what we can do to address these.
>>>>
>>>>
>>>>  >
>>>>  >  #2 I think is really important so that skinning feels familiar to
>>>>        
>> CSS
>>    
>>>>  >  developers.
>>>>  >
>>>>  >  If the solution meets those needs, I will be very happy, but others
>>>>  >  can decide on the exact syntax, I'm flexible
>>>>
>>>>  I've got a process question here, which I am a bit hesitant to ask
>>>>  given our recent "discussions", but, well, what the heck... Shouldn't
>>>>  we be discussing/reviewing such requirements/API additions before the
>>>>  changes are committed to the trunks?  Not that I am not grateful that
>>>>
>>>>
>>>>        
>>> at least (I personally think) having a "I am about to commit this" is not
>>>      
>> a
>>    
>>> bad thing (tm)
>>>
>>>
>>>
>>>      
>>>>  Cristi has invested the time on providing a solution (thanks for doing
>>>>  this Cristi!).  I am just wondering whether in general it would be
>>>>  better to review/agree on new APIs before they get committed.
>>>>
>>>>  Does Trinidad (or MyFaces) have any policy/guidelines on how new
>>>>  API/feature additions should be handled?  Not picking on Cristi here -
>>>>
>>>>
>>>>        
>>> Nope. Not that I know. Some other Apache projects have; some not.
>>> I think that for adding new APIs, we might want that we at least get
>>> an alert before :-)
>>>
>>>
>>>
>>>      
>>>>  I recently added some new skinning features myself and wasn't sure
>>>>  whether there were some specific steps that I needed to follow.
>>>>
>>>>
>>>>        
>>> haven't you ping the mailing list? If not, go ahead !
>>>
>>> If it is just still in jira, well... it can be
>>> there for a while. Bug trackers aren't that cool for discussions. Mailing
>>> list are (I hate forums)
>>>
>>> -M
>>>
>>>
>>>      
>>>>  Andy
>>>>
>>>>
>>>>
>>>>        
>>>
>>>      
>>    
>
>
>
>