Hi
I guess it's understand the consequences and use at your own risk. I doubt a
vendor will change the spelling and if they do, I'm pretty sure they'd
maintain BC by allowing both to work.
Using the example of *-radius, the vendor differences are more to do with
what the values selected will rende
On 4 Feb 2010, at 07:42, Joshua Street wrote:
>> The validator does correctly parse as per the spec. The spec defines a way
>> for vendor prefixes to exist without conflicting with anything in CSS, no
>> more. This makes them part of the grammar, not the vocabulary, and the
>> validator checks
On Thu, Feb 4, 2010 at 6:16 PM, David Dorward wrote:
> On 4 Feb 2010, at 03:29, Joshua Street wrote:
>>> The prefix may be "part of it" to address parsing issues, but - afaik - that
>>> does not make these extensions CSS properties.
>>
>> Indeed - yet therein lies the frustration at the validator
On 4 Feb 2010, at 03:29, Joshua Street wrote:
>>
>> The prefix may be "part of it" to address parsing issues, but - afaik - that
>> does not make these extensions CSS properties.
>
> Indeed - yet therein lies the frustration at the validator failing to
> correctly parse as per spec.
The valid
On Thu, Feb 4, 2010 at 1:22 PM, Thierry Koblentz
wrote:
>> On Thu, Feb 4, 2010 at 10:23 AM, Thierry Koblentz
>> wrote:
>> > -moz is a vendor prefix (not CSS3)
>>
>> Actually, vendor prefixes are a part of both CSS 2.1
>> http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords as well as the
>> CS
ius" come *last* in the declaration block
--
Regards,
Thierry | www.tjkdesign.com
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of James Ellis
Sent: Wednesday, February 03, 2010 6:10 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] CSS Validation Erro
> From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
> On Behalf Of Joshua Street
> Sent: Wednesday, February 03, 2010 5:59 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] CSS Validation Error
>
> On Thu, Feb 4, 2010 at 10:23 AM, Thierry Koblentz
*Daniel Anderson
> *Sent:* Wednesday, February 03, 2010 3:12 PM
> *To:* wsg
> *Subject:* [WSG] CSS Validation Error
>
>
>
> When I am validating a site that I am working on using the W3C Validator I
> get errors with *-moz-border-radius-bottomleft*.
>
> Is this becaus
On Thu, Feb 4, 2010 at 10:23 AM, Thierry Koblentz
wrote:
> -moz is a vendor prefix (not CSS3)
Actually, vendor prefixes are a part of both CSS 2.1
http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords as well as the
CSS3 working draft... they're for proprietary extensions, of course,
but it's a
-moz is a vendor prefix (not CSS3)
--
Regards,
Thierry | www.tjkdesign.com
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of Daniel Anderson
Sent: Wednesday, February 03, 2010 3:12 PM
To: wsg
Subject: [WSG] CSS Validation Error
When I am
When I am validating a site that I am working on using the W3C Validator I
get errors with *-moz-border-radius-bottomleft*.
Is this because it is CSS3?
Error Reads:
Property -moz-border-radius-bottomleft doesn't exist : 5px 5px
Cheers
Daniel
**
font: [italics/bold/etc] [size]/[line-height] ["two
words"],[fam2],[fam3],[etc];
Kevin Futter wrote:
My understanding was that there shouldn't be a comma in the shorthand font
selector after "Trebuchet MS" (but I could be wrong ...).
Cheers,
Kevin Futter
On 20/9/04 4:26 PM, "John Oxton" <[EMAIL P
It appears from another post that I am wrong! Oh well ...
Kevin Futter
On 21/9/04 8:56 AM, "Kevin Futter" <[EMAIL PROTECTED]> wrote:
> My understanding was that there shouldn't be a comma in the shorthand font
> selector after "Trebuchet MS" (but I could be wrong ...).
>
> Cheers,
> Kevin Futte
My understanding was that there shouldn't be a comma in the shorthand font
selector after "Trebuchet MS" (but I could be wrong ...).
Cheers,
Kevin Futter
On 20/9/04 4:26 PM, "John Oxton" <[EMAIL PROTECTED]> wrote:
> Maybe you could try not using the font shorthand to get it to validate,
> try it
Thanks John and Ryan - the problem was something to do with the menu
list item styles. It was way down the bottom of the page - I was going
crazy because I thought that error report referred to the body style
(which was at the top of the page). I only realised that must have been
the problem wh
I just checked out your CSS file, and it validates now. Whatever you did
to fix it worked :)
Just to touch base on that font shorthand:
font: [italics/bold/etc] [size]/[line-height] ["family
1"],[fam2],[fam3],[etc];
I haven't experiemented with what can be left in/out and still having it
valid
Maybe you could try not using the font shorthand to get it to validate,
try it as font-family etc. Could it be that there is something missing
from that rule? Certainly one I have had problem with before.
Cameron Muir wrote:
Thanks for pointing that out John - serves me right for not cleaning ou
Thanks for pointing that out John - serves me right for not cleaning out
disused styles.
However, I'm still getting the same error.
John Oxton wrote:
Hi Cameron,
You have this
.paymate {
position: relative:
top: 20px;
right: 10px;
}
the position:relative needs a semi colon and you sho
Hi Cameron,
You have this
.paymate {
position: relative:
top: 20px;
right: 10px;
}
the position:relative needs a semi colon and you should be on your way
Regards,
John,
Cameron Muir wrote:
Hello,
I can't work out why this is producing an error. I'm sure there must be
a simp
Hello,
I can't work out why this is producing an error. I'm sure there must be
a simple solution that I've missed.
body {
font: small "Trebuchet MS", sans-serif;
color: #66;
}
The error:
URI : http://design.quagma.net/themes/quagma/style.css
* Line: 0 Context : sans-serif
P
20 matches
Mail list logo
