Re: [WSG] CSS Validation Error

2010-02-04 Thread James Ellis
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 render as rather than the naming, for instance
webkit allows elliptical curves while moz only allows regular curves:
http://www.css3.info/border-radius-apple-vs-mozilla/
Apparently, webkit more closely resembles the CSS3 spec. Mozilla may change
their interpretation leading to possibly unexpected results (which you can
then fix).

Opera is apparently going to be supporting 'border-radius' in an upcoming
Presto release.

The end-goal is for all the major browsers to switch to border-radius and
then ignore their vendor specifc version, to avoid conflicts.

There are plenty of options to create curve-edged boxes but the CSS method
is the easiest programatically to implement, followed by creating PNG
quadrants on the fly with Imagick or similar and positioning them using CSS.
Opera allows SVG backgrounds,
so they can be created on-the-fly as XML. Plenty of designers cap a box top
and bottom with two curved slices but that's a pain to implement in flexible
layouts.

To answer a question further back, yes border-radius should be last in the
list after the vendor extensions.

Cheers
James



> They aren't "guaranteed future-compatible".
>
> Vendor: We propose this feature and have implemented this as -vendor-foo
>
> Other Vendor: Well, it has these problems, what if ...
>
> Vendor: OK. We've changed the way it works.
>
> All the slightly older clients supporting the original implementation
> promptly break.
>
>
> How would this be implemented anyway?
>
> Anything that looks like a vendor prefix works?
>
> -moz-bowder-wadius:
>
> Congratulations! It is "valid"!
>
> "But why doesn't it work?"
>
> Or does someone try to maintain a list of all the different extensions? The
> CSS 2.1 specification lists 12 known vendors who use the vendor prefix. Who
> is going to maintain a central list of all proprietary extensions and the
> values they accept? How would they be versioned?
>
>


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] CSS Validation Error

2010-02-04 Thread David Dorward
 
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 both. The CSS 2.1 specification says "Authors should avoid 
>> vendor-specific extensions".
> 
> I agree vendor-specific extensions do not constitute acceptable
> vocabulary, but as the specification allows a grammatical means for
> their inclusion it seems counter-productive to flag them as errors.

It provides a means for vendors to experiment without conflicting with real 
CSS, and for authors to *test* those features.

> The specification assures authors and vendors that "An initial dash or
> underscore is guaranteed never to be used in a property or keyword by
> any current or future level of CSS" - and, accordingly, they are (and
> will remain) grammatically permissible / safe for use. The imperative
> to avoid these extensions lacks explanation and, while this list is
> (by virtue of our name!) perhaps not the place for such views, seems
> to stem from the desire to preserve the appearance of standardisation
> rather than maximising the utility and flexibility of the standard in
> question.

The appearance of standardisation? The whole point of vendor extensions is that 
they are non-standard. Some of them are experimental implementations of 
standard features, some of them are experimental implementations of proposed 
features which may appear in future standards, some of them are outright 
proprietary. They are not standard.

> As a counterpoint to this, of course, using standards-compliant
> techniques to achieve an outcome will more successfully preserve
> interoperability into the future. However, I would assert the advice
> to "avoid vendor-specific extensions" should be constrained by this,
> rather than suggesting that a guaranteed future-compatible (albeit
> potentially no longer functional, contingent on ongoing vendor
> support) identifier should be avoided unswervingly.

They aren't "guaranteed future-compatible". 

Vendor: We propose this feature and have implemented this as -vendor-foo

Other Vendor: Well, it has these problems, what if ...

Vendor: OK. We've changed the way it works.

All the slightly older clients supporting the original implementation promptly 
break.


How would this be implemented anyway?

Anything that looks like a vendor prefix works?

-moz-bowder-wadius: 

Congratulations! It is "valid"! 

"But why doesn't it work?"

Or does someone try to maintain a list of all the different extensions? The CSS 
2.1 specification lists 12 known vendors who use the vendor prefix. Who is 
going to maintain a central list of all proprietary extensions and the values 
they accept? How would they be versioned?


-- 
David Dorward
http://dorward.me.uk



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] CSS Validation Error

2010-02-03 Thread Joshua Street
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 failing to
>> correctly parse as per spec.
>
> 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 both. The CSS 2.1 specification says "Authors should avoid 
> vendor-specific extensions".

I agree vendor-specific extensions do not constitute acceptable
vocabulary, but as the specification allows a grammatical means for
their inclusion it seems counter-productive to flag them as errors.

The specification assures authors and vendors that "An initial dash or
underscore is guaranteed never to be used in a property or keyword by
any current or future level of CSS" - and, accordingly, they are (and
will remain) grammatically permissible / safe for use. The imperative
to avoid these extensions lacks explanation and, while this list is
(by virtue of our name!) perhaps not the place for such views, seems
to stem from the desire to preserve the appearance of standardisation
rather than maximising the utility and flexibility of the standard in
question.

As a counterpoint to this, of course, using standards-compliant
techniques to achieve an outcome will more successfully preserve
interoperability into the future. However, I would assert the advice
to "avoid vendor-specific extensions" should be constrained by this,
rather than suggesting that a guaranteed future-compatible (albeit
potentially no longer functional, contingent on ongoing vendor
support) identifier should be avoided unswervingly.

So I guess my problem is with the language of the specification as
much as with the validator - but I feel there is probably enough
ambiguity in the specification around this (i.e. why introduce a
feature only to advise authors to avoid implementations applying this
feature?!) that the validator should, on the basis of grammar, accept
flexible vocabulary following this dash (-) or underscore (_) prefix.

There are good, pragmatic reasons for both approaches - but erring on
the side of flexibility here does nothing to damage the abilities of
compliant user-agents, or the fabric of the standards-based web.
Particularly in seasons where we wait for finalisation of good and
important features into usable, non-draft-form standards, the
validator's interpretation remains unhelpful.

-- 
Josh Street

http://josh.st/
+61 (0) 425 808 469


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] CSS Validation Error

2010-02-03 Thread David Dorward
 
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 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 both. The CSS 2.1 specification says "Authors should avoid 
vendor-specific extensions".

-- 
David Dorward
http://dorward.me.uk



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] CSS Validation Error

2010-02-03 Thread Joshua Street
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
>> CSS3 working draft... they're for proprietary extensions, of course,
>> but it's always seemed odd to me that the validator doesn't recognise
>> a vendor-prefix as per spec (irrespective of the specific vendor
>> extension) and ignore it accordingly.
>
> 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.

-- 
Josh Street

http://josh.st/
+61 (0) 425 808 469


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] CSS Validation Error

2010-02-03 Thread Thierry Koblentz
> #blob {
> border-radius : 5px;
> -webkit-border-radius : 5px;/* safari, chrome, arora etc */
> -moz-border-radius : 5px;/* firefox and pals*/
> -khtml-border-radius : 5px;/* konquerer */
> }


I believe it would make more sense to reverse that order and have
"border-radius" 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 Error

Hi

You can safely ignore any -prefix validation errors (-moz, -webkit, -opera)
- they are never going to validate on the W3C validator. The point of the
vendor specific rules is to do stuff the W3C haven't standardised yet.

The validator should probably ignore them as well. If you really must have a
valid stylesheet then you can stick vendor specific stuff in a vendor.css
and not validate it (because it won't).

#blob {
 border-radius : 5px;
 -webkit-border-radius : 5px;/* safari, chrome, arora etc */
 -moz-border-radius : 5px;/* firefox and pals*/
 -khtml-border-radius : 5px;/* konquerer */
}

Noting that webkit and moz have different names for the rules, watch out for
that.

Theoretically, when a browser supports border-radius, it should switch from
its vendor specific rule to the standard rule.

Cheers
James

On Thu, Feb 4, 2010 at 10:23 AM, Thierry Koblentz
 wrote:
-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 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



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] CSS Validation Error

2010-02-03 Thread Thierry Koblentz
> 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
>  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 always seemed odd to me that the validator doesn't recognise
> a vendor-prefix as per spec (irrespective of the specific vendor
> extension) and ignore it accordingly.

The prefix may be "part of it" to address parsing issues, but - afaik - that
does not make these extensions CSS properties. 


--
Regards,
Thierry | www.tjkdesign.com






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] CSS Validation Error

2010-02-03 Thread James Ellis
Hi

You can safely ignore any -prefix validation errors (-moz, -webkit, -opera)
- they are never going to validate on the W3C validator. The point of the
vendor specific rules is to do stuff the W3C haven't standardised yet.

The validator should probably ignore them as well. If you really must have a
valid stylesheet then you can stick vendor specific stuff in a vendor.css
and not validate it (because it won't).

#blob {
 border-radius : 5px;
 -webkit-border-radius : 5px;/* safari, chrome, arora etc */
 -moz-border-radius : 5px;/* firefox and pals*/
 -khtml-border-radius : 5px;/* konquerer */
}

Noting that webkit and moz have different names for the rules, watch out for
that.

Theoretically, when a browser supports border-radius, it should switch from
its vendor specific rule to the standard rule.

Cheers
James


On Thu, Feb 4, 2010 at 10:23 AM, Thierry Koblentz <
thierry.koble...@gmail.com> wrote:

>  -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 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
>
>


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] CSS Validation Error

2010-02-03 Thread Joshua Street
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 always seemed odd to me that the validator doesn't recognise
a vendor-prefix as per spec (irrespective of the specific vendor
extension) and ignore it accordingly.

-- 
Josh Street

http://josh.st/
+61 (0) 425 808 469


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] CSS Validation Error

2010-02-03 Thread Thierry Koblentz
-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 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

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] css validation error

2004-09-20 Thread Ryan Christie
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 PROTECTED]> wrote:

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 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 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 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
Parse Error - : Trebuchet MS
  * Line: 0 Context : sans-serif
Parse Error - sans-serif;
  * Line: 0 Context : sans-serif
Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**



**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
 Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


Re: [WSG] css validation error

2004-09-20 Thread Kevin Futter
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 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 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 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 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 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
> 
>  Parse Error - : Trebuchet MS
> 
>* Line: 0 Context : sans-serif
> 
>  Parse Error - sans-serif;
> 
>* Line: 0 Context : sans-serif
> 
>  Parse error - Unrecognized : { }
> 
> 
> The site:
> http://design.quagma.net
> **
> The discussion list for  http://webstandardsgroup.org/
> 
> Proud presenters of Web Essentials 04 http://we04.com/
> Web standards, accessibility, inspiration, knowledge
> To be held in Sydney, September 30 and October 1, 2004
> 
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> **
> 
> 
> 
 **
 The discussion list for  http://webstandardsgroup.org/
 
 Proud presenters of Web Essentials 04 http://we04.com/
 Web standards, accessibility, inspiration, knowledge
 To be held in Sydney, September 30 and October 1, 2004
 
 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help
 **
 
 
 
 
>>> 
>>> **
>>> The discussion list for  http://webstandardsgroup.org/
>>> 
>>> Proud presenters of Web Essentials 04 http://we04.com/
>>> Web standards, accessibility, inspiration, knowledge
>>> To be held in Sydney, September 30 and October 1, 2004
>>> 
>>> See http://webstandardsgroup.org/mail/guidelines.cfm
>>> for some hints on posting to the list & getting help
>>> **
>>> 
>>> 
>>> 
>> **
>> The discussion list for  http://webstandardsgroup.org/
>> 
>> Proud presenters of Web Essentials 04 http://we04.com/
>>  Web standards, accessibility, inspiration, knowledge
>> To be held in Sydney, September 30 and October 1, 2004
>> 
>>  See http://webstandardsgroup.org/mail/guidelines.cfm
>>  for some hints on posting to the list & getting help
>> **
>> 
>> 
> 
> 
> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
> Proud presenters of Web Essentials 04 http://we04.com/
>  Web standards, accessibility, inspiration, knowledge
> To be held in Sydney, September 30 and October 1, 2004
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 



**
The discussion list for  http://webstandardsgroup.org/

Proud presenters of Web Essentials 04 http://we04.com/
 Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help
**



Re: [WSG] css validation error

2004-09-20 Thread Kevin Futter
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 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 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 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 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
 
  Parse Error - : Trebuchet MS
 
* Line: 0 Context : sans-serif
 
  Parse Error - sans-serif;
 
* Line: 0 Context : sans-serif
 
  Parse error - Unrecognized : { }
 
 
 The site:
 http://design.quagma.net
 **
 The discussion list for  http://webstandardsgroup.org/
 
 Proud presenters of Web Essentials 04 http://we04.com/
 Web standards, accessibility, inspiration, knowledge
 To be held in Sydney, September 30 and October 1, 2004
 
 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help
 **
 
 
 
>>> **
>>> The discussion list for  http://webstandardsgroup.org/
>>> 
>>> Proud presenters of Web Essentials 04 http://we04.com/
>>> Web standards, accessibility, inspiration, knowledge
>>> To be held in Sydney, September 30 and October 1, 2004
>>> 
>>> See http://webstandardsgroup.org/mail/guidelines.cfm
>>> for some hints on posting to the list & getting help
>>> **
>>> 
>>> 
>>> 
>>> 
>> 
>> **
>> The discussion list for  http://webstandardsgroup.org/
>> 
>> Proud presenters of Web Essentials 04 http://we04.com/
>> Web standards, accessibility, inspiration, knowledge
>> To be held in Sydney, September 30 and October 1, 2004
>> 
>> See http://webstandardsgroup.org/mail/guidelines.cfm
>> for some hints on posting to the list & getting help
>> **
>> 
>> 
>> 
> **
> The discussion list for  http://webstandardsgroup.org/
> 
> Proud presenters of Web Essentials 04 http://we04.com/
>  Web standards, accessibility, inspiration, knowledge
> To be held in Sydney, September 30 and October 1, 2004
> 
>  See http://webstandardsgroup.org/mail/guidelines.cfm
>  for some hints on posting to the list & getting help
> **
> 
> 



**
The discussion list for  http://webstandardsgroup.org/

Proud presenters of Web Essentials 04 http://we04.com/
 Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help
**



Re: [WSG] css validation error

2004-09-20 Thread Cameron Muir
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 when I noticed the font family for the menu list item was 
unneccessarily specified and removed it - after that it validated. I 
could have left out a bracket or colon, I don't know, but it worked when 
it was gone.

regards,
cameron.
Ryan Christie wrote:
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 validate, but i would imagine any element as long as they appear in 
the correct order.

John Oxton wrote:
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 
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 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 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
 Parse Error - : Trebuchet MS
   * Line: 0 Context : sans-serif
 Parse Error - sans-serif;
   * Line: 0 Context : sans-serif
 Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


Re: [WSG] css validation error

2004-09-20 Thread Ryan Christie
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 
validate, but i would imagine any element as long as they appear in the 
correct order.

John Oxton wrote:
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 
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 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 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
 Parse Error - : Trebuchet MS
   * Line: 0 Context : sans-serif
 Parse Error - sans-serif;
   * Line: 0 Context : sans-serif
 Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


Re: [WSG] css validation error

2004-09-19 Thread John Oxton
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 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 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 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
 Parse Error - : Trebuchet MS
   * Line: 0 Context : sans-serif
 Parse Error - sans-serif;
   * Line: 0 Context : sans-serif
 Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


Re: [WSG] css validation error

2004-09-19 Thread Cameron Muir
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 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 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
 Parse Error - : Trebuchet MS
   * Line: 0 Context : sans-serif
 Parse Error - sans-serif;
   * Line: 0 Context : sans-serif
 Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**


Re: [WSG] css validation error

2004-09-19 Thread John Oxton
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 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
 Parse Error - : Trebuchet MS
   * Line: 0 Context : sans-serif
 Parse Error - sans-serif;
   * Line: 0 Context : sans-serif
 Parse error - Unrecognized : { }
The site:
http://design.quagma.net
**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

**
The discussion list for  http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**