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

[Blake Sullivan]

OK, how about

option 5)  the version feature is a String that matches the native
"major.minor.whatever" format of the browser's engine.  If the browser's
engine uses non "." for separating versions, "." is used instead.

For matches, the "*" character is allowed in any version section.
For comparisons, the "*"  is always a valid match regardless of <, >, or
=  comparison

For comparisons where the comparison side contains fewer version
sections than the actual browser version, the comparison side is padded
with * version sections and the comparison occurs as above.

For comparisons where the comparison side contains more version sections
than the actual browser version, the browser version is padded with 0
version sections and the comparison occurs as above.

// user wants to match IE 5, actual browser version ie 5.5
@agent ie and (version:5)

matches because version:5 expands to version 5.* and 5.* matches 5.5

@agent ie and (min-version:5)

matches because version:5 expands to version 5.* and 5.*  < 5.5 = true

@agent ie and (max-version:5)

matches because version:5 expands to version 5.* and 5.* > 5.5 = true

// actual browser version gecko 1.9
@agent gecko and (min-version:1.9.2)

does not match because the browser version 1.9 expands to 1.9.0 and
1.9.2 is > than 1.9.0

// actual browser version gecko 1.9
@agent gecko and (min-version:1.9.*)

 matches because the browser version 1.9 expands to 1.9.0 and 1.9.* == 1.9.0

-- Blake Sullivan





Blake Sullivan said the following On 4/17/2008 12:31 PM PT:

> If we agree that we like the we like the media query syntax and that
> the only issue is how to handle less than (as opposed the <=) for the
> max-version, then we can just collect up the proposals and pick one:
>
> 1) The verbose and explicit  (max-version-less-than:8).
> 2) Define that for the version feature, max-version means < not <=.  
> Inconsistent with other uses of max (max-version:8)
> 3) Let the skinning author provide enough precision to avoid the need
> to distinguish between < 8 and <= a number that apporaches 8
> (max-version:7.99)
> 4) Add an operator suffix (max-version-lt:8)
>
> 1) is gross
> 2) is potentially confusing due to inconsistency
> 3) might not be immediately obvious and could theoretically have
> precision problems
> 4) is not immediately obvious either but incredibly flexible
>
> I vote for 3) since it gets the job done and doesn't preclude doing
> more later.
>
> -- Blake Sullivan
>
>
>
>
> Andrew Robinson said the following On 4/17/2008 11:53 AM PT:
>> http://www.w3.org/TR/REC-CSS2/media.html
>>
>> @import url("loudvoice.css") aural;
>>
>> so here are multiple groups of characters that show that spaces are
>> acceptable (import url and aural keywords in one "bunch")
>>
>> url("loudvoice.css")
>> shows that parenthesis with at least one argument is acceptable
>>
>> @media screen, print {
>> Shown that a comma separated list, unlike normal CSS selectors applies
>> to the whole @ (meaning that it wasn't "@meda screen, @media print")
>>
>> From css3 (http://www.w3.org/TR/css3-reader/):
>> @import "my-print-style.css" print;
>> here, a quoted string is permissible (goes with the url values in CSS
>> rules)
>>
>> <?xml-stylesheet href="style1.css" type="text/css"
>>   media="screen and (color) and (max-width: 400px"?>
>> <?xml-stylesheet href="style2.css" type="text/css"
>>   media="reader and (max-device-ratio: 1/1)"?>
>> Hmmm.... interesting, but do we want to reuse something that relates
>> to CSS but is not in a CSS file?
>>
>> @media reader and (grid: 0)
>> Ah, now we are talking. This looks like what Blake was referring to
>>
>> From http://www.css3.info/preview/media-queries/:
>> @media all and (min-width: 640px) {
>> Even better, showing an "all" keyword and having "normal CSS
>> properties" in parens.
>>
>> http://www.css3.info/preview/attribute-selectors/:
>> Do we dare take RegExp like syntax from attr. selectors and apply them
>> to @agent rules?
>>
>>
>> So I can see Blake's suggestion being backed by these, but IMO
>> "max-version-less-than:8" is too long to remember.
>>
>> Perhaps just:
>> IE 5.5 or greater:
>> @agent ie and (min-version: 5.5)
>>
>> IE 5.0 or greater:
>> @agent ie and (min-version: 5)
>>
>> IE >= 5.0 and < 6.0:
>> @agent ie and (version: 5)
>> or (I like this one less):
>> @agent ie and (major-version: 5)
>>
>> IE <= 6.0:
>> @agent ie and (max-version: 6)
>>
>> IE < 6:
>> @agent ie and (max-version: 5.9)
>>
>> IE >= 6.0 and < 8.0:
>> @agent ie and (min-version: 6) and (max-version: 7.9)
>> same as:
>> @agent ie and (min-version: 6) and (max-version: 7)
>>
>> IE >= 6.0 and <= 8.0:
>> @agent ie and (min-version: 6) and (max-version: 8.0)
>>
>> IE >= 6.0 and <= 8.x:
>> @agent ie and (min-version: 6) and (max-version: 8)
>>
>> So x.y (ie 5.5) means precisely that, no vagueness and x (ie 6) means
>> major version x regardless of minor version. If it is too hard to
>> parse the decimal and remember it, "max-major-version",
>> "min-major-version" and "major-version" could be used for integer only
>> comparison with the major version and "max-version", "min-version" and
>> "version" could be used for full major.minor comparison.
>>
>> I think using something like 7.9 or  7.99 could theoretically be used
>> for less than but not equal to. I think the fewer number of keywords
>> the clearer it will be to use. Just my opinion.
>>
>> Just adding some thoughts to chew on since concrete ideas were asked
>> for.
>>
>> -Andrew
>>
>>
>> On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth <cristi.toth@...>
>> wrote:
>>  
>>> Hi guys,
>>>
>>> You're right, I should have discussed the format before committing it.
>>> I started fixing the issue using the format that was specified there...
>>> (there weren't to many comments on that issue btw...)
>>>  During I was fixing it, I noticed that XSS suppported multiple
>>> versions,
>>> so I adapted what was suggested on the issue to support that too.
>>>
>>> Anyway, lets get this subject out in a new thread
>>> and stick here to discussing the format.
>>>
>>> Guys, those of you that suggested some general guidelines, they all
>>> sound
>>> good,
>>> but please try to think of some concrete format that comply with those
>>> guidelines.
>>>
>>> If we decide a final format and implement it until its get released,
>>> then no
>>> big harm done.
>>>  So please be constructive ;)
>>>
>>> Thanks for any feedback!
>>>
>>> cheers,
>>> --
>>>
>>> Cristi Toth
>>>
>>> -------------
>>> Codebeat
>>> www.codebeat.ro
>>>    
>
>

[Blake Sullivan]

Cristi Toth said the following On 4/18/2008 2:58 PM PT:

I like this too
does the list of space separated numbers comply to that CSS future spec we were talking about?

I don't think it does.

-- Blake Sullivan

On Fri, Apr 18, 2008 at 11:43 PM, Scott O'Bryan <darkarena@...> wrote:

Hmm, that's an interresting format.

Glauco P. Gomes wrote:

@agent ie (versions: 4 5. 6)

where 4 = 4
and 5. = 5, 5.5, 5.6, 5.6.2 ...
and 5.5 = 5.5
and 5.5. = 5.5, 5.5.3 ...

Glauco P. Gomes

Scott O'Bryan escreveu:

@agent id (version: 8-SNAPSHOT)..  :)

Andrew Robinson wrote:

Could we leverage maven version parsing algorithms? Maven seems to be
able to parse a lot of crap :)

-Andrew

On Fri, Apr 18, 2008 at 1:09 PM, Matt Cooper <matt.faces@...> wrote:
 

I agree, full agent "version" matching is troublesome.  With this approach:


 @agent ie and (min-major-version: 6) and (min-minor-version: 1) and
 (max-major-version: 6) {
 /* styles for IE agent version 6.1 through 6.x (inclusive) */
 }

 We could go up to as many decimal tokens as we wish, e.g.
 *-major-version, *-minor-version, *-maintenance-version,
 *-build-version for "major.minor.maintenance.build" tokens.

 ----

 The question I would have then is what should we do with non-numeric
 values like you pointed out; do we really care about skinning for
 alphabetical versions?

 My proposal would be to take the raw version String and split it into
 up into tokens based on the dot character.  We should decide how many
 tokens we want to support and then we should ignore any further tokens
 in the String.
 For each token, we turn it into an integer.  If the token contains
 something other than decimal characters, keep only up to the first
 non-decimal character.  Here are some examples:
 a.) "0b5" would become "0"
 b.)  "b5" would become "" which we'd treat as "0"

 Regards,
 Matt

 On Fri, Apr 18, 2008 at 12:55 PM, Andrew Robinson


<andrew.rw.robinson@...> wrote:
 > Perhaps matching the full agent string is a bad idea. I'd hate to have
 >  to parse many variations of things like:
 >
 >  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5)
 >  Gecko/2008032620 Firefox/3.0b5
 >
 >  -Andrew
 >
 >  On Fri, Apr 18, 2008 at 12:46 PM, Andrew Robinson
 >
 >
 > <andrew.rw.robinson@...> wrote:
 >  > The problem already brought up is that minor version may not be
 >  >  enough. In a 3 part version (ie 2.0.10) the minor of 0 isn't helpful
 >  >  if you want to do something based on the 10 value
 >  >
 >  >  -Andrew
 >  >
 >  >
 >  >
 >  >  On Fri, Apr 18, 2008 at 12:40 PM, Matt Cooper <matt.faces@...> wrote:
 >  >  > Hi all,
 >  >  >
 >  >  >  The regex would be powerful though I'm afraid that it would not as
 >  >  >  obvious or easy to use for non-technical designers/skinners.
 >  >  >
 >  >  >  I think something like this would be clearer:
 >  >  >
 >  >  >  @agent ie and (min-major-version: 6) and (min-minor-version: 1) and
 >  >  >  (max-major-version: 6) {
 >  >  >   /* styles for IE agent version 6.1 through 6.x (inclusive) */
 >  >  >  }
 >  >  >
 >  >  >  Regards,
 >  >  >  Matt
 >  >  >
 >  >  >  On Fri, Apr 18, 2008 at 12:30 PM, Andrew Robinson
 >  >  >
 >  >  >
 >  >  > <andrew.rw.robinson@...> wrote:
 >  >  >  > Well that is difficult isn't it? Perhaps what I suggested a long time
 >  >  >  >  back in my bug is best and allow regexp:
 >  >  >  >
 >  >  >  >  @agent blah and (matches-version: /someRegExp/)
 >  >  >  >
 >  >  >  >  example to match 6.x through 7.x:
 >  >  >  >  @agent ie and (matches-version: /[67](\.\d)*/)
 >  >  >  >
 >  >  >  >  yeah it is harder to write, but then we can write it once and it
 >  >  >  >  handles pretty much all use cases.
 >  >  >  >
 >  >  >  >  The other twist is to give the code entire user agent string:
 >  >  >  >
 >  >  >  >  @agent matches(/MSIE\s+[67]/)
 >  >  >  >
 >  >  >  >  This really gives the user all the control they need and it is pretty
 >  >  >  >  easy to parse without having to code many syntax improvements over
 >  >  >  >  time as new requirements come up.
 >  >  >  >
 >  >  >  >  -Andrew
 >  >  >  >
 >  >  >  >  On Fri, Apr 18, 2008 at 12:10 PM, Andy Schwartz
 >  >  >  >
 >  >  >  > <andy.g.schwartz@...> wrote:
 >  >  >  >
 >  >  >  >
 >  >  >  > > On Thu, Apr 17, 2008 at 9:21 PM, Andrew Robinson
 >  >  >  >  >
 >  >  >  >  > <andrew.rw.robinson@...> wrote:
 >  >  >  >  >
 >  >  >  >  > > I'll be happy either way, but I think I now bend to the below
 >  >  >  >  >  >  explanation of 5 == 5.0 from Jeanne's reasoning
 >  >  >  >  >
 >  >  >  >  >  FWIW, I actually agree with Jeanne's first opinion. :-)
 >  >  >  >  >
 >  >  >  >  >  That is, I think of "5" as "5.*".  "5.0" as "5.0.*", etc.
 >  >  >  >  >
 >  >  >  >  >  Regarding the use of floating points to represent versions...  I was
 >  >  >  >  >  wondering whether we should avoid this since it would prevents us from
 >  >  >  >  >  supporting "major.minor.reallyminor" version strings.  I don't know
 >  >  >  >  >  that we will ever need to go further than major.minor, though the
 >  >  >  >  >  Gecko versions use the third digit, so perhaps we should pick a
 >  >  >  >  >  solution that doesn't preclude us from supporting this?
 >  >  >  >  >
 >  >  >  >  >  (BTW, sorry all about my little digression earlier on the thread...)
 >  >  >  >  >
 >  >  >  >  >  Andy
 >  >  >  >  >
 >  >  >  >
 >  >  >
 >  >
 >

   

--
Cristi Toth

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

[Andy Schwartz]

On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
<blake.sullivan@...> wrote:
> OK, how about
>
>  option 5)

I like option 5.

Andy

[Andrew Robinson-5]

+1

On Fri, Apr 18, 2008 at 4:19 PM, Andy Schwartz
<andy.g.schwartz@...> wrote:

> On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
>
> <blake.sullivan@...> wrote:
>
> > OK, how about
>  >
>  >  option 5)
>
>  I like option 5.
>
>  Andy
>

[Cristi Toth]

I have to admit it's +1 from me to option 5)  :)

On Sat, Apr 19, 2008 at 12:21 AM, Andrew Robinson <andrew.rw.robinson@...> wrote:

+1

On Fri, Apr 18, 2008 at 4:19 PM, Andy Schwartz

<andy.g.schwartz@...> wrote:

> On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
>
> <blake.sullivan@...> wrote:
>
> > OK, how about
>  >
>  >  option 5)
>
>  I like option 5.
>
>  Andy
>

--
Cristi Toth

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

[Matt Cooper]

+1 to option 5

On Fri, Apr 18, 2008 at 4:21 PM, Andrew Robinson
<andrew.rw.robinson@...> wrote:

> +1
>
>  On Fri, Apr 18, 2008 at 4:19 PM, Andy Schwartz
>
> <andy.g.schwartz@...> wrote:
>
>
> > On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
>  >
>  > <blake.sullivan@...> wrote:
>  >
>  > > OK, how about
>  >  >
>  >  >  option 5)
>  >
>  >  I like option 5.
>  >
>  >  Andy
>  >
>

[Blake Sullivan]

I'm in favor as well.  I think that rather than making this a String it would be clearer if we added a Version class and embedded the comparison rules in the class implementation.

 -- Blake Sullivan

Andy Schwartz said the following On 4/18/2008 3:19 PM PT:

On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
blake.sullivan@... wrote:
  

OK, how about

 option 5)
    

I like option 5.

Andy
  

[Glauco P. Gomes]

I like this option, but what hapens if the user wants to match the
version 5? (Only 5, not 5.5)

Glauco P. Gomes

Blake Sullivan escreveu:

> OK, how about
>
> option 5)  the version feature is a String that matches the native
> "major.minor.whatever" format of the browser's engine.  If the
> browser's engine uses non "." for separating versions, "." is used
> instead.
>
> For matches, the "*" character is allowed in any version section.
> For comparisons, the "*"  is always a valid match regardless of <, >,
> or =  comparison
>
> For comparisons where the comparison side contains fewer version
> sections than the actual browser version, the comparison side is
> padded with * version sections and the comparison occurs as above.
>
> For comparisons where the comparison side contains more version
> sections than the actual browser version, the browser version is
> padded with 0 version sections and the comparison occurs as above.
>
> // user wants to match IE 5, actual browser version ie 5.5
> @agent ie and (version:5)
>
> matches because version:5 expands to version 5.* and 5.* matches 5.5
>
> @agent ie and (min-version:5)
>
> matches because version:5 expands to version 5.* and 5.*  < 5.5 = true
>
> @agent ie and (max-version:5)
>
> matches because version:5 expands to version 5.* and 5.* > 5.5 = true
>
> // actual browser version gecko 1.9
> @agent gecko and (min-version:1.9.2)
>
> does not match because the browser version 1.9 expands to 1.9.0 and
> 1.9.2 is > than 1.9.0
>
> // actual browser version gecko 1.9
> @agent gecko and (min-version:1.9.*)
>
> matches because the browser version 1.9 expands to 1.9.0 and 1.9.* ==
> 1.9.0
>
> -- Blake Sullivan
>
>
>
>
>
> Blake Sullivan said the following On 4/17/2008 12:31 PM PT:
>> If we agree that we like the we like the media query syntax and that
>> the only issue is how to handle less than (as opposed the <=) for the
>> max-version, then we can just collect up the proposals and pick one:
>>
>> 1) The verbose and explicit  (max-version-less-than:8).
>> 2) Define that for the version feature, max-version means < not <=.  
>> Inconsistent with other uses of max (max-version:8)
>> 3) Let the skinning author provide enough precision to avoid the need
>> to distinguish between < 8 and <= a number that apporaches 8
>> (max-version:7.99)
>> 4) Add an operator suffix (max-version-lt:8)
>>
>> 1) is gross
>> 2) is potentially confusing due to inconsistency
>> 3) might not be immediately obvious and could theoretically have
>> precision problems
>> 4) is not immediately obvious either but incredibly flexible
>>
>> I vote for 3) since it gets the job done and doesn't preclude doing
>> more later.
>>
>> -- Blake Sullivan
>>
>>
>>
>>
>> Andrew Robinson said the following On 4/17/2008 11:53 AM PT:
>>> http://www.w3.org/TR/REC-CSS2/media.html
>>>
>>> @import url("loudvoice.css") aural;
>>>
>>> so here are multiple groups of characters that show that spaces are
>>> acceptable (import url and aural keywords in one "bunch")
>>>
>>> url("loudvoice.css")
>>> shows that parenthesis with at least one argument is acceptable
>>>
>>> @media screen, print {
>>> Shown that a comma separated list, unlike normal CSS selectors applies
>>> to the whole @ (meaning that it wasn't "@meda screen, @media print")
>>>
>>> From css3 (http://www.w3.org/TR/css3-reader/):
>>> @import "my-print-style.css" print;
>>> here, a quoted string is permissible (goes with the url values in
>>> CSS rules)
>>>
>>> <?xml-stylesheet href="style1.css" type="text/css"
>>>   media="screen and (color) and (max-width: 400px"?>
>>> <?xml-stylesheet href="style2.css" type="text/css"
>>>   media="reader and (max-device-ratio: 1/1)"?>
>>> Hmmm.... interesting, but do we want to reuse something that relates
>>> to CSS but is not in a CSS file?
>>>
>>> @media reader and (grid: 0)
>>> Ah, now we are talking. This looks like what Blake was referring to
>>>
>>> From http://www.css3.info/preview/media-queries/:
>>> @media all and (min-width: 640px) {
>>> Even better, showing an "all" keyword and having "normal CSS
>>> properties" in parens.
>>>
>>> http://www.css3.info/preview/attribute-selectors/:
>>> Do we dare take RegExp like syntax from attr. selectors and apply them
>>> to @agent rules?
>>>
>>>
>>> So I can see Blake's suggestion being backed by these, but IMO
>>> "max-version-less-than:8" is too long to remember.
>>>
>>> Perhaps just:
>>> IE 5.5 or greater:
>>> @agent ie and (min-version: 5.5)
>>>
>>> IE 5.0 or greater:
>>> @agent ie and (min-version: 5)
>>>
>>> IE >= 5.0 and < 6.0:
>>> @agent ie and (version: 5)
>>> or (I like this one less):
>>> @agent ie and (major-version: 5)
>>>
>>> IE <= 6.0:
>>> @agent ie and (max-version: 6)
>>>
>>> IE < 6:
>>> @agent ie and (max-version: 5.9)
>>>
>>> IE >= 6.0 and < 8.0:
>>> @agent ie and (min-version: 6) and (max-version: 7.9)
>>> same as:
>>> @agent ie and (min-version: 6) and (max-version: 7)
>>>
>>> IE >= 6.0 and <= 8.0:
>>> @agent ie and (min-version: 6) and (max-version: 8.0)
>>>
>>> IE >= 6.0 and <= 8.x:
>>> @agent ie and (min-version: 6) and (max-version: 8)
>>>
>>> So x.y (ie 5.5) means precisely that, no vagueness and x (ie 6) means
>>> major version x regardless of minor version. If it is too hard to
>>> parse the decimal and remember it, "max-major-version",
>>> "min-major-version" and "major-version" could be used for integer only
>>> comparison with the major version and "max-version", "min-version" and
>>> "version" could be used for full major.minor comparison.
>>>
>>> I think using something like 7.9 or  7.99 could theoretically be used
>>> for less than but not equal to. I think the fewer number of keywords
>>> the clearer it will be to use. Just my opinion.
>>>
>>> Just adding some thoughts to chew on since concrete ideas were asked
>>> for.
>>>
>>> -Andrew
>>>
>>>
>>> On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth
>>> <cristi.toth@...> wrote:
>>>  
>>>> Hi guys,
>>>>
>>>> You're right, I should have discussed the format before committing it.
>>>> I started fixing the issue using the format that was specified
>>>> there...
>>>> (there weren't to many comments on that issue btw...)
>>>>  During I was fixing it, I noticed that XSS suppported multiple
>>>> versions,
>>>> so I adapted what was suggested on the issue to support that too.
>>>>
>>>> Anyway, lets get this subject out in a new thread
>>>> and stick here to discussing the format.
>>>>
>>>> Guys, those of you that suggested some general guidelines, they all
>>>> sound
>>>> good,
>>>> but please try to think of some concrete format that comply with those
>>>> guidelines.
>>>>
>>>> If we decide a final format and implement it until its get
>>>> released, then no
>>>> big harm done.
>>>>  So please be constructive ;)
>>>>
>>>> Thanks for any feedback!
>>>>
>>>> cheers,
>>>> --
>>>>
>>>> Cristi Toth
>>>>
>>>> -------------
>>>> Codebeat
>>>> www.codebeat.ro
>>>>    
>>
>>
>
>

[Blake Sullivan]

Glauco P. Gomes said the following On 4/18/2008 3:45 PM PT:
> I like this option, but what hapens if the user wants to match the
> version 5? (Only 5, not 5.5)
@agent ie and (version:5.0)

That will match version 5.0.* but that's probably what he wants

-- Blake Sullivan

>
> Glauco P. Gomes
>
> Blake Sullivan escreveu:
>> OK, how about
>>
>> option 5)  the version feature is a String that matches the native
>> "major.minor.whatever" format of the browser's engine.  If the
>> browser's engine uses non "." for separating versions, "." is used
>> instead.
>>
>> For matches, the "*" character is allowed in any version section.
>> For comparisons, the "*"  is always a valid match regardless of <, >,
>> or =  comparison
>>
>> For comparisons where the comparison side contains fewer version
>> sections than the actual browser version, the comparison side is
>> padded with * version sections and the comparison occurs as above.
>>
>> For comparisons where the comparison side contains more version
>> sections than the actual browser version, the browser version is
>> padded with 0 version sections and the comparison occurs as above.
>>
>> // user wants to match IE 5, actual browser version ie 5.5
>> @agent ie and (version:5)
>>
>> matches because version:5 expands to version 5.* and 5.* matches 5.5
>>
>> @agent ie and (min-version:5)
>>
>> matches because version:5 expands to version 5.* and 5.*  < 5.5 = true
>>
>> @agent ie and (max-version:5)
>>
>> matches because version:5 expands to version 5.* and 5.* > 5.5 = true
>>
>> // actual browser version gecko 1.9
>> @agent gecko and (min-version:1.9.2)
>>
>> does not match because the browser version 1.9 expands to 1.9.0 and
>> 1.9.2 is > than 1.9.0
>>
>> // actual browser version gecko 1.9
>> @agent gecko and (min-version:1.9.*)
>>
>> matches because the browser version 1.9 expands to 1.9.0 and 1.9.* ==
>> 1.9.0
>>
>> -- Blake Sullivan
>>
>>
>>
>>
>>
>> Blake Sullivan said the following On 4/17/2008 12:31 PM PT:
>>> If we agree that we like the we like the media query syntax and that
>>> the only issue is how to handle less than (as opposed the <=) for
>>> the max-version, then we can just collect up the proposals and pick
>>> one:
>>>
>>> 1) The verbose and explicit  (max-version-less-than:8).
>>> 2) Define that for the version feature, max-version means < not <=.  
>>> Inconsistent with other uses of max (max-version:8)
>>> 3) Let the skinning author provide enough precision to avoid the
>>> need to distinguish between < 8 and <= a number that apporaches 8
>>> (max-version:7.99)
>>> 4) Add an operator suffix (max-version-lt:8)
>>>
>>> 1) is gross
>>> 2) is potentially confusing due to inconsistency
>>> 3) might not be immediately obvious and could theoretically have
>>> precision problems
>>> 4) is not immediately obvious either but incredibly flexible
>>>
>>> I vote for 3) since it gets the job done and doesn't preclude doing
>>> more later.
>>>
>>> -- Blake Sullivan
>>>
>>>
>>>
>>>
>>> Andrew Robinson said the following On 4/17/2008 11:53 AM PT:
>>>> http://www.w3.org/TR/REC-CSS2/media.html
>>>>
>>>> @import url("loudvoice.css") aural;
>>>>
>>>> so here are multiple groups of characters that show that spaces are
>>>> acceptable (import url and aural keywords in one "bunch")
>>>>
>>>> url("loudvoice.css")
>>>> shows that parenthesis with at least one argument is acceptable
>>>>
>>>> @media screen, print {
>>>> Shown that a comma separated list, unlike normal CSS selectors applies
>>>> to the whole @ (meaning that it wasn't "@meda screen, @media print")
>>>>
>>>> From css3 (http://www.w3.org/TR/css3-reader/):
>>>> @import "my-print-style.css" print;
>>>> here, a quoted string is permissible (goes with the url values in
>>>> CSS rules)
>>>>
>>>> <?xml-stylesheet href="style1.css" type="text/css"
>>>>   media="screen and (color) and (max-width: 400px"?>
>>>> <?xml-stylesheet href="style2.css" type="text/css"
>>>>   media="reader and (max-device-ratio: 1/1)"?>
>>>> Hmmm.... interesting, but do we want to reuse something that relates
>>>> to CSS but is not in a CSS file?
>>>>
>>>> @media reader and (grid: 0)
>>>> Ah, now we are talking. This looks like what Blake was referring to
>>>>
>>>> From http://www.css3.info/preview/media-queries/:
>>>> @media all and (min-width: 640px) {
>>>> Even better, showing an "all" keyword and having "normal CSS
>>>> properties" in parens.
>>>>
>>>> http://www.css3.info/preview/attribute-selectors/:
>>>> Do we dare take RegExp like syntax from attr. selectors and apply them
>>>> to @agent rules?
>>>>
>>>>
>>>> So I can see Blake's suggestion being backed by these, but IMO
>>>> "max-version-less-than:8" is too long to remember.
>>>>
>>>> Perhaps just:
>>>> IE 5.5 or greater:
>>>> @agent ie and (min-version: 5.5)
>>>>
>>>> IE 5.0 or greater:
>>>> @agent ie and (min-version: 5)
>>>>
>>>> IE >= 5.0 and < 6.0:
>>>> @agent ie and (version: 5)
>>>> or (I like this one less):
>>>> @agent ie and (major-version: 5)
>>>>
>>>> IE <= 6.0:
>>>> @agent ie and (max-version: 6)
>>>>
>>>> IE < 6:
>>>> @agent ie and (max-version: 5.9)
>>>>
>>>> IE >= 6.0 and < 8.0:
>>>> @agent ie and (min-version: 6) and (max-version: 7.9)
>>>> same as:
>>>> @agent ie and (min-version: 6) and (max-version: 7)
>>>>
>>>> IE >= 6.0 and <= 8.0:
>>>> @agent ie and (min-version: 6) and (max-version: 8.0)
>>>>
>>>> IE >= 6.0 and <= 8.x:
>>>> @agent ie and (min-version: 6) and (max-version: 8)
>>>>
>>>> So x.y (ie 5.5) means precisely that, no vagueness and x (ie 6) means
>>>> major version x regardless of minor version. If it is too hard to
>>>> parse the decimal and remember it, "max-major-version",
>>>> "min-major-version" and "major-version" could be used for integer only
>>>> comparison with the major version and "max-version", "min-version" and
>>>> "version" could be used for full major.minor comparison.
>>>>
>>>> I think using something like 7.9 or  7.99 could theoretically be used
>>>> for less than but not equal to. I think the fewer number of keywords
>>>> the clearer it will be to use. Just my opinion.
>>>>
>>>> Just adding some thoughts to chew on since concrete ideas were
>>>> asked for.
>>>>
>>>> -Andrew
>>>>
>>>>
>>>> On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth
>>>> <cristi.toth@...> wrote:
>>>>  
>>>>> Hi guys,
>>>>>
>>>>> You're right, I should have discussed the format before committing
>>>>> it.
>>>>> I started fixing the issue using the format that was specified
>>>>> there...
>>>>> (there weren't to many comments on that issue btw...)
>>>>>  During I was fixing it, I noticed that XSS suppported multiple
>>>>> versions,
>>>>> so I adapted what was suggested on the issue to support that too.
>>>>>
>>>>> Anyway, lets get this subject out in a new thread
>>>>> and stick here to discussing the format.
>>>>>
>>>>> Guys, those of you that suggested some general guidelines, they
>>>>> all sound
>>>>> good,
>>>>> but please try to think of some concrete format that comply with
>>>>> those
>>>>> guidelines.
>>>>>
>>>>> If we decide a final format and implement it until its get
>>>>> released, then no
>>>>> big harm done.
>>>>>  So please be constructive ;)
>>>>>
>>>>> Thanks for any feedback!
>>>>>
>>>>> cheers,
>>>>> --
>>>>>
>>>>> Cristi Toth
>>>>>
>>>>> -------------
>>>>> Codebeat
>>>>> www.codebeat.ro
>>>>>    
>>>
>>>
>>
>>
>

[Glauco P. Gomes]

+1 if this includes multiple major versions (5, 6, 7)

Glauco P. Gomes

Blake Sullivan escreveu:

> Glauco P. Gomes said the following On 4/18/2008 3:45 PM PT:
>> I like this option, but what hapens if the user wants to match the
>> version 5? (Only 5, not 5.5)
> @agent ie and (version:5.0)
>
> That will match version 5.0.* but that's probably what he wants
>
> -- Blake Sullivan
>
>>
>> Glauco P. Gomes
>>
>> Blake Sullivan escreveu:
>>> OK, how about
>>>
>>> option 5)  the version feature is a String that matches the native
>>> "major.minor.whatever" format of the browser's engine.  If the
>>> browser's engine uses non "." for separating versions, "." is used
>>> instead.
>>>
>>> For matches, the "*" character is allowed in any version section.
>>> For comparisons, the "*"  is always a valid match regardless of <,
>>> >, or =  comparison
>>>
>>> For comparisons where the comparison side contains fewer version
>>> sections than the actual browser version, the comparison side is
>>> padded with * version sections and the comparison occurs as above.
>>>
>>> For comparisons where the comparison side contains more version
>>> sections than the actual browser version, the browser version is
>>> padded with 0 version sections and the comparison occurs as above.
>>>
>>> // user wants to match IE 5, actual browser version ie 5.5
>>> @agent ie and (version:5)
>>>
>>> matches because version:5 expands to version 5.* and 5.* matches 5.5
>>>
>>> @agent ie and (min-version:5)
>>>
>>> matches because version:5 expands to version 5.* and 5.*  < 5.5 = true
>>>
>>> @agent ie and (max-version:5)
>>>
>>> matches because version:5 expands to version 5.* and 5.* > 5.5 = true
>>>
>>> // actual browser version gecko 1.9
>>> @agent gecko and (min-version:1.9.2)
>>>
>>> does not match because the browser version 1.9 expands to 1.9.0 and
>>> 1.9.2 is > than 1.9.0
>>>
>>> // actual browser version gecko 1.9
>>> @agent gecko and (min-version:1.9.*)
>>>
>>> matches because the browser version 1.9 expands to 1.9.0 and 1.9.*
>>> == 1.9.0
>>>
>>> -- Blake Sullivan
>>>
>>>
>>>
>>>
>>>
>>> Blake Sullivan said the following On 4/17/2008 12:31 PM PT:
>>>> If we agree that we like the we like the media query syntax and
>>>> that the only issue is how to handle less than (as opposed the <=)
>>>> for the max-version, then we can just collect up the proposals and
>>>> pick one:
>>>>
>>>> 1) The verbose and explicit  (max-version-less-than:8).
>>>> 2) Define that for the version feature, max-version means < not
>>>> <=.  Inconsistent with other uses of max (max-version:8)
>>>> 3) Let the skinning author provide enough precision to avoid the
>>>> need to distinguish between < 8 and <= a number that apporaches 8
>>>> (max-version:7.99)
>>>> 4) Add an operator suffix (max-version-lt:8)
>>>>
>>>> 1) is gross
>>>> 2) is potentially confusing due to inconsistency
>>>> 3) might not be immediately obvious and could theoretically have
>>>> precision problems
>>>> 4) is not immediately obvious either but incredibly flexible
>>>>
>>>> I vote for 3) since it gets the job done and doesn't preclude doing
>>>> more later.
>>>>
>>>> -- Blake Sullivan
>>>>
>>>>
>>>>
>>>>
>>>> Andrew Robinson said the following On 4/17/2008 11:53 AM PT:
>>>>> http://www.w3.org/TR/REC-CSS2/media.html
>>>>>
>>>>> @import url("loudvoice.css") aural;
>>>>>
>>>>> so here are multiple groups of characters that show that spaces are
>>>>> acceptable (import url and aural keywords in one "bunch")
>>>>>
>>>>> url("loudvoice.css")
>>>>> shows that parenthesis with at least one argument is acceptable
>>>>>
>>>>> @media screen, print {
>>>>> Shown that a comma separated list, unlike normal CSS selectors
>>>>> applies
>>>>> to the whole @ (meaning that it wasn't "@meda screen, @media print")
>>>>>
>>>>> From css3 (http://www.w3.org/TR/css3-reader/):
>>>>> @import "my-print-style.css" print;
>>>>> here, a quoted string is permissible (goes with the url values in
>>>>> CSS rules)
>>>>>
>>>>> <?xml-stylesheet href="style1.css" type="text/css"
>>>>>   media="screen and (color) and (max-width: 400px"?>
>>>>> <?xml-stylesheet href="style2.css" type="text/css"
>>>>>   media="reader and (max-device-ratio: 1/1)"?>
>>>>> Hmmm.... interesting, but do we want to reuse something that relates
>>>>> to CSS but is not in a CSS file?
>>>>>
>>>>> @media reader and (grid: 0)
>>>>> Ah, now we are talking. This looks like what Blake was referring to
>>>>>
>>>>> From http://www.css3.info/preview/media-queries/:
>>>>> @media all and (min-width: 640px) {
>>>>> Even better, showing an "all" keyword and having "normal CSS
>>>>> properties" in parens.
>>>>>
>>>>> http://www.css3.info/preview/attribute-selectors/:
>>>>> Do we dare take RegExp like syntax from attr. selectors and apply
>>>>> them
>>>>> to @agent rules?
>>>>>
>>>>>
>>>>> So I can see Blake's suggestion being backed by these, but IMO
>>>>> "max-version-less-than:8" is too long to remember.
>>>>>
>>>>> Perhaps just:
>>>>> IE 5.5 or greater:
>>>>> @agent ie and (min-version: 5.5)
>>>>>
>>>>> IE 5.0 or greater:
>>>>> @agent ie and (min-version: 5)
>>>>>
>>>>> IE >= 5.0 and < 6.0:
>>>>> @agent ie and (version: 5)
>>>>> or (I like this one less):
>>>>> @agent ie and (major-version: 5)
>>>>>
>>>>> IE <= 6.0:
>>>>> @agent ie and (max-version: 6)
>>>>>
>>>>> IE < 6:
>>>>> @agent ie and (max-version: 5.9)
>>>>>
>>>>> IE >= 6.0 and < 8.0:
>>>>> @agent ie and (min-version: 6) and (max-version: 7.9)
>>>>> same as:
>>>>> @agent ie and (min-version: 6) and (max-version: 7)
>>>>>
>>>>> IE >= 6.0 and <= 8.0:
>>>>> @agent ie and (min-version: 6) and (max-version: 8.0)
>>>>>
>>>>> IE >= 6.0 and <= 8.x:
>>>>> @agent ie and (min-version: 6) and (max-version: 8)
>>>>>
>>>>> So x.y (ie 5.5) means precisely that, no vagueness and x (ie 6) means
>>>>> major version x regardless of minor version. If it is too hard to
>>>>> parse the decimal and remember it, "max-major-version",
>>>>> "min-major-version" and "major-version" could be used for integer
>>>>> only
>>>>> comparison with the major version and "max-version", "min-version"
>>>>> and
>>>>> "version" could be used for full major.minor comparison.
>>>>>
>>>>> I think using something like 7.9 or  7.99 could theoretically be used
>>>>> for less than but not equal to. I think the fewer number of keywords
>>>>> the clearer it will be to use. Just my opinion.
>>>>>
>>>>> Just adding some thoughts to chew on since concrete ideas were
>>>>> asked for.
>>>>>
>>>>> -Andrew
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth
>>>>> <cristi.toth@...> wrote:
>>>>>  
>>>>>> Hi guys,
>>>>>>
>>>>>> You're right, I should have discussed the format before
>>>>>> committing it.
>>>>>> I started fixing the issue using the format that was specified
>>>>>> there...
>>>>>> (there weren't to many comments on that issue btw...)
>>>>>>  During I was fixing it, I noticed that XSS suppported multiple
>>>>>> versions,
>>>>>> so I adapted what was suggested on the issue to support that too.
>>>>>>
>>>>>> Anyway, lets get this subject out in a new thread
>>>>>> and stick here to discussing the format.
>>>>>>
>>>>>> Guys, those of you that suggested some general guidelines, they
>>>>>> all sound
>>>>>> good,
>>>>>> but please try to think of some concrete format that comply with
>>>>>> those
>>>>>> guidelines.
>>>>>>
>>>>>> If we decide a final format and implement it until its get
>>>>>> released, then no
>>>>>> big harm done.
>>>>>>  So please be constructive ;)
>>>>>>
>>>>>> Thanks for any feedback!
>>>>>>
>>>>>> cheers,
>>>>>> --
>>>>>>
>>>>>> Cristi Toth
>>>>>>
>>>>>> -------------
>>>>>> Codebeat
>>>>>> www.codebeat.ro
>>>>>>    
>>>>
>>>>
>>>
>>>
>>
>
>

[Matt Cooper]

It does:

@agent ie and (min-version:5) and (max-version:7) {
  /* styles for all 5.*, 6.*, and 7.* versions of the IE agent versions */
}

Regards,
Matt

On Fri, Apr 18, 2008 at 5:02 PM, Glauco P. Gomes
<glaucopgomes@...> wrote:

> +1 if this includes multiple major versions (5, 6, 7)
>
>
>
>  Glauco P. Gomes
>
>  Blake Sullivan escreveu:
>
> > Glauco P. Gomes said the following On 4/18/2008 3:45 PM PT:
> >
> > > I like this option, but what hapens if the user wants to match the
> version 5? (Only 5, not 5.5)
> > >
> > @agent ie and (version:5.0)
> >
> > That will match version 5.0.* but that's probably what he wants
> >
> > -- Blake Sullivan
> >
> >
> > >
> > > Glauco P. Gomes
> > >
> > > Blake Sullivan escreveu:
> > >
> > > > OK, how about
> > > >
> > > > option 5)  the version feature is a String that matches the native
> "major.minor.whatever" format of the browser's engine.  If the browser's
> engine uses non "." for separating versions, "." is used instead.
> > > >
> > > > For matches, the "*" character is allowed in any version section.
> > > > For comparisons, the "*"  is always a valid match regardless of <, >,
> or =  comparison
> > > >
> > > > For comparisons where the comparison side contains fewer version
> sections than the actual browser version, the comparison side is padded with
> * version sections and the comparison occurs as above.
> > > >
> > > > For comparisons where the comparison side contains more version
> sections than the actual browser version, the browser version is padded with
> 0 version sections and the comparison occurs as above.
> > > >
> > > > // user wants to match IE 5, actual browser version ie 5.5
> > > > @agent ie and (version:5)
> > > >
> > > > matches because version:5 expands to version 5.* and 5.* matches 5.5
> > > >
> > > > @agent ie and (min-version:5)
> > > >
> > > > matches because version:5 expands to version 5.* and 5.*  < 5.5 = true
> > > >
> > > > @agent ie and (max-version:5)
> > > >
> > > > matches because version:5 expands to version 5.* and 5.* > 5.5 = true
> > > >
> > > > // actual browser version gecko 1.9
> > > > @agent gecko and (min-version:1.9.2)
> > > >
> > > > does not match because the browser version 1.9 expands to 1.9.0 and
> 1.9.2 is > than 1.9.0
> > > >
> > > > // actual browser version gecko 1.9
> > > > @agent gecko and (min-version:1.9.*)
> > > >
> > > > matches because the browser version 1.9 expands to 1.9.0 and 1.9.* ==
> 1.9.0
> > > >
> > > > -- Blake Sullivan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Blake Sullivan said the following On 4/17/2008 12:31 PM PT:
> > > >
> > > > > If we agree that we like the we like the media query syntax and that
> the only issue is how to handle less than (as opposed the <=) for the
> max-version, then we can just collect up the proposals and pick one:
> > > > >
> > > > > 1) The verbose and explicit  (max-version-less-than:8).
> > > > > 2) Define that for the version feature, max-version means < not <=.
> Inconsistent with other uses of max (max-version:8)
> > > > > 3) Let the skinning author provide enough precision to avoid the
> need to distinguish between < 8 and <= a number that apporaches 8
> (max-version:7.99)