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

> I think if I saw max-version: 5, I'd think that all minor versions of
> 5 would work, too.
> Otherwise, I would have written max-version: 5.0.
> - Jeanne
>
>
> Blake Sullivan wrote, On 4/17/2008 12:58 PM PT:
>> Andrew Robinson said the following On 4/17/2008 12:35 PM PT:
>>> So do I read this correctly that for #3, 8 means 8.x so a max-version
>>> of 8 means any browser agent with a major version of 8 or less an not
>>> even look at the minor version?
>>>  
>> I'm proposing that the version feature reflect the best floating
>> point version number we can calculate for the browser, which will
>> usually be a combination of the major and minor version, so the
>> version for IE 5.5 will be the floating point number 5.5
>>
>>
>> 8 is promoted to 8.0 and since max- means
>> less-than-or-equal-to:max-version:8 means
>>
>> version <= 8.0 == true
>>
>> -- Blake Sullivan
>>
>>> If so, I like 3 as well.
>>>
>>> -Andrew
>>>
>>> On Thu, Apr 17, 2008 at 1:31 PM, Blake Sullivan
>>> <blake.sullivan@...> wrote:
>>>  
>>>> 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
>>>>>>
>>>>>>
>>>>>>        
>>>>    
>>
>>
>