Actually, I take that back. I think if I saw max-version: 5, I'd think 5.0.
The reason is people talk about versions, like, 2.0.0.10 and 2.0.0.4,
etc, so if I saw 2.0, I'd think 2.0.0.0
Otherwise I like #3.
Jeanne Waldman wrote, On 4/17/2008 2:43 PM PT:
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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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
