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

> 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
>>>>    
>>
>>
>
>