Re: [WSG] When is invalid CSS okay?

[Stuart Foulstone]

If it's name was "Sheraton Center" that's how it should be spelt.

-- 
Stuart Foulstone.
http://www.bigeasyweb.co.uk
BigEasy Web Design
69 Flockton Court
Rockingham Street
Sheffield
S1 4EB

Tel. 07751 413451

On Wed, August 22, 2007 6:07 pm, David Hucklesby wrote:
> On Wed, 22 Aug 2007 11:27:11 +0100, Rick Lecoat wrote:
> [...]
>>
>> So, is it considered 'okay', in a web standards sense, to have a non-
>> valid "bug-fixes"
>> stylesheet working alongside your perfect, pristine, uiber-valid main
>> stylesheet?
>>
> Personally, after working with separate style sheets for IE, I found
> them difficult to maintain. I am now experimenting with a single style
> sheet for everything (including print styles). So far I like it.
>
> My view on validation is that it is as essential as a spell checker.
> Like a spell check, I think you need to use common sense with it.
> After all, if I write about the Sheraton Centre in Manhattan, my
> U.S. spell checker tells me I misspelled "Centre". So do I change
> the spelling? I think not.
>
> Cordially,
> David
> --
>
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
>
>



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Looking for feedback on a Fireworks plugin for generating accessible sprite navigation

[Andrew Ingram]

Hi all,

Half of this is a plug and half of this is a call for testing and 
suggestions for improvement.


I've been developing a command panel for Fireworks that generates the 
HTML and CSS for a horizontal menu that uses the sprite-background 
technique for hover/active states. Obvious examples being 
http://veerle.duoh.com/ and http://www.apple.com. It's a simple enough 
technique but can involve a few fiddly calculations and is not exactly 
fun, the plugin essentially makes the whole process much faster.


I've only been able to test this on a couple of my own examples so 
there's probably a few bugs that i'm keen to track down.


I'm mostly looking for input on the quality of the outputted HTML and 
CSS, I think I've done it fairly well but another set (or sets) of eyes 
might spot something I've missed. The obvious accessibility issue is 
that I'm hiding the text but everything else seems alright to me.


Basically you load your navigation matrix image in Fireworks, add guides 
to separate the different menu items and states then run the plugin - 
more information at 
http://www.andrewingram.net/articles/generating_sprite_navigation_from_fireworks/ 
if you want to try it out.


I was hoping to make this for Photoshop too but there are some annoying 
limitations.


Thanks

- Andrew Ingram



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[Rick Lecoat]

On 22/8/07 (20:15) Andrew said:

>I may be mistaken here, but I think the "gunk" can be dispensed with  
>by using "Save For Web" rather than simply "Save" or "Save As".

I believe that a PNG's gamma information is retained in a Save For Web
operation -- certainly I've seen colour casts in PNGs that I've used in
web pages (eg. a flat hex colour in a PNG placed beside the same hex
colour specified in the CSS), the PNG having been saved for web in
Photoshop (I can't always be bothered going via ImageReady). 
Other things such embedded icon information /are/ removed, however, and
can mean considerable savings in file size.

>Although it may be gunk on the web, this information is essential to  
>achieving consistent high quality in print.

Indeed, primarily colour profiles.

-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[Andrew Maben]

On Aug 22, 2007, at 1:00 PM, David Hucklesby wrote:


...all the gunk
with which Adobe products infest PNG files.


I may be mistaken here, but I think the "gunk" can be dispensed with  
by using "Save For Web" rather than simply "Save" or "Save As".


Although it may be gunk on the web, this information is essential to  
achieving consistent high quality in print.


Andrew







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Nick Gleitzman]

On 23 Aug 2007, at 3:07 AM, David Hucklesby wrote:


After all, if I write about the Sheraton Centre in Manhattan, my
U.S. spell checker tells me I misspelled "Centre". So do I change
the spelling? I think not.


Hmm. Interesting example. 'Sheraton Center' is a placename - a proper 
noun.


Have you ever tried to use 'text-align: centre'?

N
___
omnivision. websight.
http://www.omnivision.com.au/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[David Hucklesby]

On Wed, 22 Aug 2007 11:27:11 +0100, Rick Lecoat wrote:
[...]
>
> So, is it considered 'okay', in a web standards sense, to have a non- valid 
> "bug-fixes"
> stylesheet working alongside your perfect, pristine, uiber-valid main 
> stylesheet?
>
Personally, after working with separate style sheets for IE, I found
them difficult to maintain. I am now experimenting with a single style
sheet for everything (including print styles). So far I like it.

My view on validation is that it is as essential as a spell checker.
Like a spell check, I think you need to use common sense with it.
After all, if I write about the Sheraton Centre in Manhattan, my
U.S. spell checker tells me I misspelled "Centre". So do I change
the spelling? I think not.

Cordially,
David
--



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[David Hucklesby]

> On 21/8/07 (04:02) Joseph said:
>
>> Safari will sometimes show a different hue of your color than other browsers 
>> will
>> when .png images set as backgrounds.
>>
On Wed, 22 Aug 2007 1, Rick Lecoat replied:
> /Slightly/ off-thread, but...
> >
> I believe that this is a product of PNGs containing a built-in gamma profile; 
> many
> browsers ignore it (as they ignore other colour profile info) but Safari (and 
> maybe
> some others?) adjust the colour render accordingly, meaning that the image is 
> displayed
> with a slightly different gamma to 'non-gamma' elements (eg. GIFs and 
> background
> colours set in HTML/CSS).
>
> A solution to this is reported to be GammaSlamma  
> which
> strips out the gamma information. I say 'reportedly' because although I've 
> downloaded
> it and plan to give it a whirl, I have not, as yet, had opportunity to try it 
> out.
>
> But just thought in case it helps anybody.

In the same spirit, I can tell you that PNGOUTWin also removes this
gamma information. Out of the box, it also safely removes all the gunk
with which Adobe products infest PNG files.

Cordially,
David
--



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[David Hucklesby]

> On 21/8/07 (04:02) Joseph said:
>
>> Safari will sometimes show a different hue of your color than other browsers 
>> will
>> when .png images set as backgrounds.
>>
On Wed, 22 Aug 2007 1, Rick Lecoat replied:
> /Slightly/ off-thread, but...
> >
> I believe that this is a product of PNGs containing a built-in gamma profile; 
> many
> browsers ignore it (as they ignore other colour profile info) but Safari (and 
> maybe
> some others?) adjust the colour render accordingly, meaning that the image is 
> displayed
> with a slightly different gamma to 'non-gamma' elements (eg. GIFs and 
> background
> colours set in HTML/CSS).
>
> A solution to this is reported to be GammaSlamma  
> which
> strips out the gamma information. I say 'reportedly' because although I've 
> downloaded
> it and plan to give it a whirl, I have not, as yet, had opportunity to try it 
> out.
>
> But just thought in case it helps anybody.

In the same spirit, I can tell you that PNGOUTWin also removes this
gamma information. Out of the box, it also safely removes all the gunk
with which Adobe products infest PNG files.

Cordially,
David
--



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Rick Lecoat]

On 22/8/07 (14:41) Georg said:

>The real reason for me to not use 'CC' for separation, is that the
>versioning goes on on HTML level and adds unnecessary garbage to every
>single page.

That's a very good point. 

And, I was about to follow it up with "I wish there was a way to use
conditional comments inside CSS" when I read further down your message
and  discovered that you'd answered it for me. Cheers.

In fact, once I read it I suddenly remembered (doh!) that I used
something very similar a few months ago, but had completely forgotten
about it:

  @import url("allBrowsersStyle.css");
  /* The following (non-valid) import rule will be seen by IE (Win) 5-7*/
  @import ieWin-fixes.css;

The IEWin5-7 import hack was culled from this page:


I must be tired.

-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] When is invalid CSS okay?

[Philip Kiff]

Gunlaug Sørtun wrote:
> The real reason for me to not use 'CC' for separation, is that the
> versioning goes on on HTML level and adds unnecessary garbage to every
> single page.

If you happen to be designing an XHTML site and decide you want to use
server-side scripting to deliver your pages as XHTML/xml-application to
standards-compliant browsers and as HTML/text to MSIE, then you can
selectively include your various Conditional Comments into only the HTML,
dumbed-down-for-MSIE version.  Then the "unnecessary garbage" CC's will not
even show up in your "pristine" XHTML/CSS version.  This is probably not
that practical in most real-world cases, but it does take the separation
idea to its logical conclusion.  And for those who really want "pristine",
separated code, it is a viable solution.

I like the CC method because it is easy to understand and it should be easy
for a different developer to understand five years from now.  CSS hacks, on
the other hand, require a bit of arcane knowledge that may be difficult to
understand for a newbie five years from now, even with explanatory comments
added.  But I agree with Gunlaug that the down-side of CC's is that it
requires adding unnecessary garbage to every single X/HTML page's head
section.

Phil.




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Gunlaug Sørtun]

Rick Lecoat wrote:

[..] However, I'm curious about why your personal preference is for 
NOT using Conditional Comments; you seem to equate them with trying 
to hide embarrassing non-valid code, and I'm sure that some designers

 might use them for that.


The "hiding" effect gained by 'CC' is used by many to justify hacking
and to declare their solutions valid - because the validator doesn't
complain.
To me, such "valid" claims are nonsensical, and cloud the issue that we
_have to_ hack our way around IE weaknesses one way or another.
To me, a working hack to make IE behave isn't embarrassing at all,
although it may be embarrassing for the creators of that browser.

The real reason for me to not use 'CC' for separation, is that the
versioning goes on on HTML level and adds unnecessary garbage to every
single page.
I prefer to separate on CSS level so the amount of garbage is kept to a
minimum, and so that I can limit creation and updating of workarounds to
a few lines in a stylesheet.


Most often I just add the necessary workarounds in the main stylesheets
- and just test to make sure the workarounds don't disturb other
browsers. This works for all browsers - with a bit of care.
The fact that the validator flags non-valid workarounds is a real
time-saver during upgrading, as I don't have to comment these
workarounds in order to find them later on.

At times I use IE's own CSS bugs to feed it a "fake" stylesheet while
feeding non-IE browsers a real stylesheet. This is true separation.
This method does indeed hide both valid and non-valid workarounds for IE
from the validator - same as with a 'CC', but this "hiding" effect can't
be avoided and I can live with it :-)

The latter method is described here...

...and is used throughout that private site. I won't recommend this
method, but it works just fine - with a bit of care.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] inability to line up elements in a print style sheet

[michael.brockington]

You may want to double-check you maths - I make it around 800px high at
72dpi:
295mm / 25.4mm  = 11 inches  * 72 dpi  ~ 800px after margins.
 
Mike




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rachel Campbell
Sent: Wednesday, August 22, 2007 2:02 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] inability to line up elements in a print style
sheet



Hi List

http://actemp.sipu.anglia.ac.uk/steve/transcript/d59.html
 

My colleague is trying to produce a print style sheet for IE
only for a page of student results which will vary considerably in
length from one student to another.  He's using JS to work out how much
of the table can be displayed on each page, and has marked the follow up
page with the place where he'd like the continuing table to start on
page 2.  He's using absolute positioning to position the elements and
has calculated that at 72dpi and A4, the page is exactly 1040px high, so
if it printed reliably, he'd be able to position everything exactly.

Needless to say, it isn't working.  Does anyone have any ideas
whether this can be achieved using css (or any other method)?

Many thanks for any suggestions

Rachel

-

Rachel Campbell

C&ITS

Cambridge

0845 196 2026

[EMAIL PROTECTED] 




This e-mail and any attachments are intended for the above named
recipient(s) only and may be privileged. If they have come to you in
error you must take no action based on them, nor must you copy or show
them to anyone: please reply to this e-mail to highlight the error and
then immediately delete the e-mail from your system. 

Any opinions expressed are solely those of the author and do not
necessarily represent the views or opinions of Anglia Ruskin University.


Although measures have been taken to ensure that this e-mail and
attachments are free from any virus we advise that, in keeping with good
computing practice, the recipient should ensure they are actually virus
free. Please note that this message has been sent over public networks
which may not be a 100% secure communications 



***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]

*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] inability to line up elements in a print style sheet

[Rachel Campbell]

Hi List

http://actemp.sipu.anglia.ac.uk/steve/transcript/d59.html

My colleague is trying to produce a print style sheet for IE only for a page
of student results which will vary considerably in length from one student to
another.  He's using JS to work out how much of the table can be displayed on
each page, and has marked the follow up page with the place where he'd like
the continuing table to start on page 2.  He's using absolute positioning to
position the elements and has calculated that at 72dpi and A4, the page is
exactly 1040px high, so if it printed reliably, he'd be able to position
everything exactly.

Needless to say, it isn't working.  Does anyone have any ideas whether this
can be achieved using css (or any other method)?

Many thanks for any suggestions
Rachel

-
Rachel Campbell
C&ITS
Cambridge

0845 196 2026
[EMAIL PROTECTED] 



This e-mail and any attachments are intended for the above named recipient(s) 
only and may be privileged. If they have come to you in error you must take no 
action based on them, nor must you copy or show them to anyone: please reply to 
this e-mail to highlight the error and then immediately delete the e-mail from 
your system.

Any opinions expressed are solely those of the author and do not necessarily 
represent the views or opinions of Anglia Ruskin University.

Although measures have been taken to ensure that this e-mail and attachments 
are free from any virus we advise that, in keeping with good computing 
practice, the recipient should ensure they are actually virus free. Please note 
that this message has been sent over public networks which may not be a 100% 
secure communications


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Rick Lecoat]

On 22/8/07 (12:57) Barney said:

>? Invalid *ML will force browsers into defective behaviour. If your 
>markup isn't written according to the very clear spec, the browser has 
>to make assumptions. Different browsers make different assumptions at 
>different times - you are leaving yourself open to all sorts of trouble. 
>Don't do it!
>
>? Invalid CSS is written because *perfectly valid CSS*, especially in 
>ambitious designs, *will cause different browsers to behave in different 
>ways*. In complete opposite to invalid markup, invalid CSS often has to 
>be used to secure consistent behaviour accross circumstances.

Absolutely.
Just to be clear, then, I was talking specifically about invalid CSS,
not (X)HTML. The markup MUST validate, as you say. Otherwise it doesn't
go out the door.

>PS: I just read your post regarding the danger of hacks getting fixed.

I re-read that post of mine and it might have sounded like I was wagging
an admonishing finger at anyone who uses hacks rather than
Cond.Comments. Nothing could be farther from the truth. If I can solve a
problem equally well using either technique then I'd rather go the CC
route rather than doing the style-hiding/applying in the stream of the
main CSS file via hacks... but that's a personal preference. And it's a
recent preference, too -- in the past I've sure used my share of hacks
in an all-in-one CSS file.
So no finger wagging here. One thing's for sure: I'm here to learn, not
preach.

Best regards; 
-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Barney Carroll]

Rick,

The key thing to consider is this:

• Invalid *ML will force browsers into defective behaviour. If your 
markup isn't written according to the very clear spec, the browser has 
to make assumptions. Different browsers make different assumptions at 
different times – you are leaving yourself open to all sorts of trouble. 
Don't do it!


• Invalid CSS is written because *perfectly valid CSS*, especially in 
ambitious designs, *will cause different browsers to behave in different 
ways*. In complete opposite to invalid markup, invalid CSS often has to 
be used to secure consistent behaviour accross circumstances.


I regularly use MS proprietary CSS (off-spec and therefore invalid: 
zoom, filter, etc.), the comma hack (',' at the end of selectors, feeds 
the rules to IE* only, and is considered bad syntax), and various 
comment hacks (break rules up with comments to render them as simply bad 
syntax to all modern browsers) – to ensure a standardised experience for 
as many users as possible.


Of course such effects must be understood before they are used – but in 
all likelihood you are only using them because you've seen that things 
screw up if you don't. The worst that can happen is an unforseen display 
problem, or you getting confused in hindsight as to how everything's 
holding together through non-spec CSS. Aside from that and the withering 
glare of unemployed standardista mullahs, you have nothing to worry about.



Regards,
Barney


PS: I just read your post regarding the danger of hacks getting fixed. 
My answer to this is simple: Whenever a major browser comes out, I have 
to recheck all my designs and see what behaviour it exhibits – and deal 
with it. Whether I use hacks or not, I'm still going to check and quite 
possibly (remember when IE7 hit the streets?) have to fine-tune for it 
anyway. In this circumstance hacks are just more code to go through – 
although with a fair bit of luck we will work out which hacks apply and 
safely be able to ignore the rest. It's not as if any new Microsoft 
release leaves puritan non-hackers laughing.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Rick Lecoat]

On 22/8/07 (12:12) Georg said:

>It is considered "bad, but necessary and therefore acceptable" by most
>web designers/developers.

That's what I thought, Georg, but it's good to hear it confirmed --
seeing as how we don't live in that 'ideal world' that I keep hearing so
much about.

>'Conditional comments' for IE versions provides us with a practical
>separation-solution, but the hiding-effect (that the validator can't see
>the separate and non-valid workaround) doesn't make the non-valid
>workaround more valid. Thus, my personal preference is *not* to use
>'conditional comments' unless there's no other way to achieve separation
>and prevent other _browsers_ from being disturbed by the non-valid
>workarounds. I see no point in "hiding my sins", although I daily hide
>lots of IE garbage as a result of the separation-process itself.

I fully agree that separating the non-valid 'fixes' stylesheet from the
main one does not make it any more valid. However, I'm curious about why
your personal preference is for NOT using Conditional Comments; you seem
to equate them with trying to hide embarrassing non-valid code, and I'm
sure that some designers might use them for that. 

I'm certainly not trying to hide anything by using CCs (to be honest, I
have a hard enough time convincing clients that valid code is even a
benefit to them, so they aren't going to care if my IE stylesheet
doesn't validate if, indeed, they even understand the concept). I use
them primarily because they segue nicely into my deep-seated anal
retention (everything subdivided and in its own file).

Best...
-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Rick Lecoat]

On 22/8/07 (12:12) [EMAIL PROTECTED] said:

>Are you serving up your hacked stylesheet to everyone, or just to those
>crippled by IE?
>The latter is far more acceptable than the former, in my opinion.

Just the victims of IE.

I'm of the opinion that hacks -- ie. workarounds exploiting browser bugs
and loopholes in css implementation -- are an inferior solution compared
to serving valid browser-specific css via conditional commenting, simply
because the bugs and loopholes can get fixed or closed at any time,
potentially breaking hack-based css. Cond.comments, on the other hand,
are an official M$-approved technique and as such should be around for
the foreseeable future.

But sometimes the CSS that needs to go into the Conditionally Commented
stylesheet isn't valid -- IE's filters being a prime example.

-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[James Jeffery]

If its only to get around bugs in IE then id also have to say its ok, its
the not the developers fault bill gates still cannot get anything right
(well not bill gates but his developers, seen as he has shown alot of
interest in web standards, his browsers still suck).

Anything apart from this id say no. If it cant be done, dont hack away and
try to make something possible, you'll end up with a right mess.

James Jeffery

On 8/22/07, Rick Lecoat <[EMAIL PROTECTED]> wrote:
>
> This is probably one of those questions that divides the audience (no,
> it doesn't involve brussel sprouts), but here goes:
>
> As exponents of web standards, we all know that one of the bedrock
> basics is that our code should validate -- both (x)html and css.
> But we also know that IE(win) is something of a recalcitrant beast and
> must occasionally be spanked into order with some hacks and/or
> conditionally commented stylesheets. And sometimes the workarounds
> required are non-valid CSS.
>
> So, is it considered 'okay', in a web standards sense, to have a non-
> valid "bug-fixes" stylesheet working alongside your perfect, pristine,
> uiber-valid main stylesheet?
>
> To give an example, if I were to have an IE-specific stylesheet with a
> lot of stuff like filter: alpha(opacity=50) in it -- which, a quick
> Google check informs me, does not validate -- would that be seen as a
> breach of web standards?
>
> Perhaps this whole issue is me getting too focused on the nitty gritty,
> but I'm in the process of moving from 'old-school' to web standards and
> am trying very hard to get it 'right'. This is just one of the goal
> posts that I'd like to clearly identify.
>
> Thanks.
>
> --
> Rick Lecoat
>
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
>
>


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Gunlaug Sørtun]

Rick Lecoat wrote:


So, is it considered 'okay', in a web standards sense, to have a non-
 valid "bug-fixes" stylesheet working alongside your perfect, 
pristine, uiber-valid main stylesheet?


It is considered "bad, but necessary and therefore acceptable" by most
web designers/developers.

To give an example, if I were to have an IE-specific stylesheet with 
a lot of stuff like filter: alpha(opacity=50) in it -- which, a quick

Google check informs me, does not validate -- would that be seen as a
breach of web standards?


It _is_ a breach of web standard, so some may see it as a "sin" :-)

However, since there's no other real-world option in many cases, you may
as well add the non-valid part to your pristine CSS and "confess" openly
to having done so. An ordinary CSS comment may make most reasonable web
designers/developers see the light, and make them defer from further
comments on the issue.

Perhaps this whole issue is me getting too focused on the nitty 
gritty, but I'm in the process of moving from 'old-school' to web 
standards and am trying very hard to get it 'right'. This is just one

 of the goal posts that I'd like to clearly identify.


- If there are valid and logical options, then non-valid solutions
should be avoided.
- If no valid and logical options are available, then the _logical_
thing to do is to make it work if at all possible - choosing the most
reliable workaround for weak standard-support and browser bugs, even if
validity suffers a bit.

Whether we separate the valid from the valid parts by using separate
stylesheets, or simply leave the non-valid parts "in the stream",
depends mostly on the local workflow and personal preferences.

'Conditional comments' for IE versions provides us with a practical
separation-solution, but the hiding-effect (that the validator can't see
the separate and non-valid workaround) doesn't make the non-valid
workaround more valid. Thus, my personal preference is *not* to use
'conditional comments' unless there's no other way to achieve separation
and prevent other _browsers_ from being disturbed by the non-valid
workarounds. I see no point in "hiding my sins", although I daily hide
lots of IE garbage as a result of the separation-process itself.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] When is invalid CSS okay?

[michael.brockington]

Are you serving up your hacked stylesheet to everyone, or just to those
crippled by IE?

The latter is far more acceptable than the former, in my opinion.

Mike 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of Rick Lecoat
>Sent: Wednesday, August 22, 2007 11:27 AM
>To: Web Standards Group
>Subject: [WSG] When is invalid CSS okay?



> is it considered 'okay', in a web standards sense, to have 
>a non- valid "bug-fixes" stylesheet working alongside your 
>perfect, pristine, uiber-valid main stylesheet? 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[M. Jama]

Hey rick,

This happened to me as I mentioned in the last issue, and When I spoke to my
client and explained to him the reason he accepted it and chosen design and
cross browser compatibility to complete valid CSS and the only thing that
doesn't validate is the mozilla custom opacity:

Parse Error - opacity=65)
Property -moz-opacity doesn't exist : 0.65

however it all comes back to the client and their requests!


On 8/22/07, Rick Lecoat <[EMAIL PROTECTED]> wrote:
>
> This is probably one of those questions that divides the audience (no,
> it doesn't involve brussel sprouts), but here goes:
>
> As exponents of web standards, we all know that one of the bedrock
> basics is that our code should validate -- both (x)html and css.
> But we also know that IE(win) is something of a recalcitrant beast and
> must occasionally be spanked into order with some hacks and/or
> conditionally commented stylesheets. And sometimes the workarounds
> required are non-valid CSS.
>
> So, is it considered 'okay', in a web standards sense, to have a non-
> valid "bug-fixes" stylesheet working alongside your perfect, pristine,
> uiber-valid main stylesheet?
>
> To give an example, if I were to have an IE-specific stylesheet with a
> lot of stuff like filter: alpha(opacity=50) in it -- which, a quick
> Google check informs me, does not validate -- would that be seen as a
> breach of web standards?
>
> Perhaps this whole issue is me getting too focused on the nitty gritty,
> but I'm in the process of moving from 'old-school' to web standards and
> am trying very hard to get it 'right'. This is just one of the goal
> posts that I'd like to clearly identify.
>
> Thanks.
>
> --
> Rick Lecoat
>
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
>
>


-- 
http://www.Mjama.com


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] When is invalid CSS okay?

[Rick Lecoat]

This is probably one of those questions that divides the audience (no,
it doesn't involve brussel sprouts), but here goes:

As exponents of web standards, we all know that one of the bedrock
basics is that our code should validate -- both (x)html and css.
But we also know that IE(win) is something of a recalcitrant beast and
must occasionally be spanked into order with some hacks and/or
conditionally commented stylesheets. And sometimes the workarounds
required are non-valid CSS.

So, is it considered 'okay', in a web standards sense, to have a non-
valid "bug-fixes" stylesheet working alongside your perfect, pristine,
uiber-valid main stylesheet? 

To give an example, if I were to have an IE-specific stylesheet with a
lot of stuff like filter: alpha(opacity=50) in it -- which, a quick
Google check informs me, does not validate -- would that be seen as a
breach of web standards?

Perhaps this whole issue is me getting too focused on the nitty gritty,
but I'm in the process of moving from 'old-school' to web standards and
am trying very hard to get it 'right'. This is just one of the goal
posts that I'd like to clearly identify.

Thanks.

-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[Rick Lecoat]

/Slightly/ off-thread, but...

On 21/8/07 (04:02) Joseph said:

>Safari will sometimes show a different hue of your color than other 
>browsers will when .png images set as backgrounds.

I believe that this is a product of PNGs containing a built-in gamma
profile; many browsers ignore it (as they ignore other colour profile
info) but Safari (and maybe some others?) adjust the colour render
accordingly, meaning that the image is displayed with a slightly
different gamma to 'non-gamma' elements (eg. GIFs and background colours
set in HTML/CSS).

A solution to this is reported to be GammaSlamma  which strips out the gamma information. I say 'reportedly'
because although I've downloaded it and plan to give it a whirl, I have
not, as yet, had opportunity to try it out.

But just thought in case it helps anybody.
-- 
Rick Lecoat



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE, alpha transparency and sliding doors...

[M. Jama]

There is a way to do that but it won't be CSS valid, since you'd have to use
custom mozilla transparency and since the child will inherit the
transparency properties make it outside the transparent div and movie it
with position left right top and bottom, that should work I have a site that
should launch anytime now done that way



On 8/22/07, Nick Cowie <[EMAIL PROTECTED]> wrote:
>
> Stephen asked:
> > Could you use solid background gif and then the opacity filter in your
> IE6 style sheet?
> > I'm not sure if you can make the child of a translucent parent opaque
> though.
>
> Yes and Yes, I was lazy and chose to do it via background colour rather
> than image (is was easier to get a colour match) and you can make the child
> of a translucent parent opaque. I had to go find the IE CSS for that page.
> But that is what I did.
> http://www.docep.wa.gov.au/presentation/style/wlieonly.css
>
> I could not agree with Joe more:
> > Impossible?  Not if you have a huge amount of time to put towards
> ironing out the issues.
>
> It will consume a couple of days to get it right in IE 5.5 and 6 if that
> is what the client / boss wants and is willing to pay for then do it. You
> will know for next time. Otherwise use conditional comments and feed a gif
> with no shadow to IE 6 and below. Half and hour of your time instead of
> days.
>
> Nick
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
>



-- 
http://www.Mjama.com


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***