Cristi Toth said the following On 4/19/2008 10:58 AM PT:
:) yep, I forgot about the "and"
is "or" valid in those CSS rules?
No. That's what the comma is for.
-- Blake Sullivan
On Sat, Apr 19, 2008 at 6:44 PM, Blake Sullivan
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Cristi Toth said the following On 4/19/2008 3:51 AM PT:
or @agent ie and (version:6) and (version:8)
This rule would never be true because it is asserting that the
agent must match IE and the version must match both 6.* and 8.*
-- Blake Sullivan
On Sat, Apr 19, 2008 at 1:31 AM, Blake Sullivan
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> <mailto:[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 <http://www.codebeat.ro>
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro <http://www.codebeat.ro>
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro <http://www.codebeat.ro>
