myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cristi Toth" <cristi.t...@gmail.com>
Subject Re: [Trinidad] added browser version support in skinning TRINIDAD-799
Date Sat, 19 Apr 2008 10:51:43 GMT
or @agent ie and (version:6) and (version:8)

On Sat, Apr 19, 2008 at 1:31 AM, Blake Sullivan <blake.sullivan@oracle.com>
wrote:

>  Glauco P. Gomes said the following On 4/18/2008 4:28 PM PT:
>
> I think that I'm not expressed correctly, what I wanted to say was not
> sequencial major versions.
> Eg.:
> @agent ie and (version: 6 and 8) {
>    /* styles for all 6.*, and 8.* versions of the IE agent versions */
> }
>
> @agent ie and (version:6), ie and (version:8)
>
> -- Blake Sullivan
>
>
>
> Or this doesn't make sense?
>
> Glauco P. Gomes
>
> Matt Cooper escreveu:
>
> 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@yahoo.com.br> <glaucopgomes@yahoo.com.br>
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)
>
>
>   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@gmail.com> <cristi.toth@gmail.com> 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
>
> -------------
> Codebeatwww.codebeat.ro
>
>
>
>
>


-- 
Cristi Toth

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

Mime
View raw message