RE: [WSG] Mozilla chocks with Dynamic Content
After examining a previews reply this was my logic. And thank you for the tip, Clear:both would make it work beautifully. So basicly clear:both means.. obey the height of the longest div. Thanks for the tip! -Original Message- From: Lauke PH [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lauke Sent: Thursday, June 03, 2004 8:08 PM To: [EMAIL PROTECTED] Subject: RE: [WSG] Mozilla chocks with Dynamic Content Mozilla is acting correctly. By floating the #menu, you've removed it from the normal flow of the document...hence, it does not take up space height-wise, and therefore does not stretch the container. An initial fix is to add clear: both; to your #footer... Patrick Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk attachment: winmail.dat
Re: [WSG] Anti-spam mailto encoders using Character Entity Evasion
Guys hate to rain on your parade but if your browser can understand that obfuscation what makes you think that a email address harvestor is not going to be able to? These guys are writing complex viruses that harvest email addresses directly from people's Outlook contact lists, surely they can understand a little javascript and work with character entities. Sorry but I think you are kidding yourselves. Obfuscation does not work, replacing @ with at or appending .spam does not work and makes it harder for dummy user to actually use the web, putting emails addresseses in images is anti-accessibility (unless of course you also put the email address in the alt tags). The best method of hiding email addresses is with a contact form, but even then you are losing out because you are forcing a user to contact you via their website (i.e. stopping them from writing down your email or adding it to their contacts and contacting you at leisure). Emails addresses should be public information (like phone numbers). Spam isn't going to be stopped by hiding email addresses, you've got to stop it on the way into your mail box. Cheers Mark * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] CSS Disaster
Just a thought:
Are you writing,
@import url('%styles.css%')
or,
@import url('%styles.css%');
???
The semi-colon is absolutely essential.
Roy
- Original Message -
From: Sean M. Hall AKA Dante [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 7:53 PM
Subject: [WSG] CSS Disaster
Dad, I'm not saying I wrecked the CSS.but I'm gonna need a new stylesheet.
This is how I feel right now. For my new History Website redesign, I worked hard on
creating a valid
XHTML 1.0 Transitional structure consisting of semantic, organized markup. I validated
tha markup
and the CSS (which didn't validate cuz I use -moz-box-sizing). I worked hard, and even
added a
DOM-driven behaviour layer.
Opera 7.23 (IMHO, the best browser ever) renders it beautifully, as I expected. Opera
7.23 rewards
me for my hard work, which is why I love it.
How does IE repay me? By not loading the bloody stylesheet at all (it does load the
external .js
file though). Period. Nein.
At first I though it was this:
@import url('screenstyles.css') screen;
I use single quotes so IE5/Mac won't see the stylesheet. But I switched to double
quotes and still
no luck. Removed the screen; part. Nein. not yet. Removed the conditional comments for
IE in the
head section: no, no, nein.
Almost all of my visitors use IE, and I have less than two weeks to solve the problem.
CSS is an excellent car, but IE is a broken muddy pothole-filled road.
Anyone know any bugs that prevent IE from loading a stylesheet?
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
RE: [WSG] Anti-spam mailto encoders using Character Entity Evasion
I have been using the obfuscation method for some time now, and while it may not totally eliminate spam harvesting, IMHO it certainly does slow the harvesting down. I have used the javascript method also, with the addition of a gif displaying the e-mail address for folks that have javascript disabled. I have found this to be effective also. Mark is quite correct when he says that complex e-mail harvesters will probably work around these methods, but it appears that most of the harvesting is done by very basic programs that are looking only for e-mail addresses stored in conventional format. Guys hate to rain on your parade but if your browser can understand that obfuscation what makes you think that a email address harvester is not going to be able to? These guys are writing complex viruses that harvest email addresses directly from people's Outlook contact lists, surely they can understand a little javascript and work with character entities. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Anti-spam mailto encoders using Character Entity Evasion
On 6/4/04 2:05 AM Mike Pepper [EMAIL PROTECTED] sent this out: There is no doubting professional harvesters will easily circumvent the obfuscation. This is a damage limitation exercise. In this war of attrition, any counter-measure is better than none. A 'What's the point attitude' is defeatist. This has little to do with developing to web standards, does it? Just pondering, Rick * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Anti-spam mailto encoders using Character Entity Evasion
Mark is quite correct when he says that complex e-mail harvesters will probably work around these methods, but it appears that most of the harvesting is done by very basic programs that are looking only for e-mail addresses stored in conventional format. Indeed, Alan, as I mentioned: However, any programmer worth his salt will simply run a recursive loop and trap for either ... There is no 'secure' format because if a browser can display it, a programmer can read it. But it'll keep the kids at bay :o) There is no doubting professional harvesters will easily circumvent the obfuscation. This is a damage limitation exercise. In this war of attrition, any counter-measure is better than none. A 'What's the point attitude' is defeatist. --- Mike Pepper Accessible Web Developer (with shares in Anadin) www.seowebsitepromotion.com --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alan Harrison Sent: 04 June 2004 08:42 To: [EMAIL PROTECTED] Subject: RE: [WSG] Anti-spam mailto encoders using Character Entity Evasion I have been using the obfuscation method for some time now, and while it may not totally eliminate spam harvesting, IMHO it certainly does slow the harvesting down. I have used the javascript method also, with the addition of a gif displaying the e-mail address for folks that have javascript disabled. I have found this to be effective also. Mark is quite correct when he says that complex e-mail harvesters will probably work around these methods, but it appears that most of the harvesting is done by very basic programs that are looking only for e-mail addresses stored in conventional format. Guys hate to rain on your parade but if your browser can understand that obfuscation what makes you think that a email address harvester is not going to be able to? These guys are writing complex viruses that harvest email addresses directly from people's Outlook contact lists, surely they can understand a little javascript and work with character entities. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Anti-spam mailto encoders using Character Entity Evasion
It does now... why not use the content: selector and set your email in there ;) Shame IE dont like Content: tho! * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Anti-spam mailto encoders using Character Entity Evasion
On Fri, 4 Jun 2004 17:41:32 +1000, Alan Harrison wrote: Mark is quite correct when he says that complex e-mail harvesters will probably work around these methods, but it appears that most of the harvesting is done by very basic programs that are looking only for e-mail addresses stored in conventional format. Assuming true intelligence on the part of a spammer is probably going too far, but it does occur to me that it is in the interests of spammers not to try too hard to collect addresses. By only collecting the most easily found addresses (ie the un-obfuscated ones) they: 1) still get many millions of addresses to use and 2) are less likely to reach the group that will report them. But that sort of thinking assumes sensible reasoning on the part of the spammer. :) FTR - I've had great success with minimising spam with simple replacement with character entities. Note that I also hide the 'mailto:' part. Lea -- Lea de Groot Elysian Systems - I Understand the Internet http://elysiansystems.com/ Web Design, Usability, Information Architecture, Search Engine Optimisation Brisbane, Australia * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Anti-spam mailto... MOVED TO DISCUSSION ROOM
Ok, this thread is way off topic now. As it seems of-interest to a section of members, rather than close it we have moved it to the discussion room: http://discuss.webstandardsgroup.org/archives/17.htm Any further discussion on this thread can take place in there but NOT on list. Thanks Russ On Fri, 4 Jun 2004 17:41:32 +1000, Alan Harrison wrote: Mark is quite correct when he says that complex e-mail harvesters will probably work around these methods, but it appears that most of the harvesting is done by very basic programs that are looking only for e-mail addresses stored in conventional format. Assuming true intelligence on the part of a spammer is probably going too far, but it does occur to me that it is in the interests of spammers not to try too hard to collect addresses. By only collecting the most easily found addresses (ie the un-obfuscated ones) they: 1) still get many millions of addresses to use and 2) are less likely to reach the group that will report them. But that sort of thinking assumes sensible reasoning on the part of the spammer. :) FTR - I've had great success with minimising spam with simple replacement with character entities. Note that I also hide the 'mailto:' part. Lea * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Make em' pay for IE
Peter Firminger wrote: I totally disagree. IE (with it's problems) is the dominant browser and it's absolutely your problem (the web developer) to make sure the site you build for a client works on the most likely user-agent. Didn't nay not to make the site work in IE. What I'm suggesting is letting them know that in order to make it 100% functional in IE, that extra work is needed. You're going to due it anyway, why no let client know about it? Again, I'm not suggesting to increase the bill--using standards will often lower the bill--just letting them know that if it wasn't required to support IE 100% (not an option these days) they'd be saving some money. As far as non-IE extras, they should be exactly that--extra. A site need to have a 100% lever of functionality and a 100% look in IE, but in a compliant browser, maybe the look could be 110%? Users would only know they were missing something if they saw the site in a compliant browser. These are features which would otherwise not be included because IE can't handle it, so adding them for free only improves the site without any cost involved (beyond a few extra bytes). * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Make em' pay for IE
El vie, 04-06-2004 a las 12:59, Mordechai Peller escribió: As far as non-IE extras, they should be exactly that--extra. A site need to have a 100% lever of functionality and a 100% look in IE, but in a compliant browser, maybe the look could be 110%? Users would only know they were missing something if they saw the site in a compliant browser. These are features which would otherwise not be included because IE can't handle it, so adding them for free only improves the site without any cost involved (beyond a few extra bytes). FYI, that concept is called MOSE and described here http://www.mezzoblue.com/archives/2003/06/25/mose/ -- Manuel trabaja para Simplelógica, construcción web (+34) 985 22 12 65http://simplelogica.net escribe en Logicola http://simplelogica.net/logicola/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Make em' pay for IE
Title: RE: [WSG] Make em' pay for IE I agree word for word with Mark on this Jamie Mason: Design -Original Message- From: Mark Harwood WebMail [mailto:[EMAIL PROTECTED]] Sent: 04 June 2004 12:23 To: [EMAIL PROTECTED] Subject: Re: [WSG] Make em' pay for IE Im sorry but you never ever suggest to a client that the site will not work in IE, 9 time out of 10 a client will only know about IE. If your suggesting standards you should know what and what not to do to make a standard site work accross all browsers. I would never ever suggest a site will take longer to do due to getting it to work in IE, if you have to do that state that there will be a extra Testing Period in which you will be working over multiple platforms and browsers to check all features are compatible. Your never gonna get a client that says i dont want this to work in ie! and if you ever did it more than like'ly the person could do it them self * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] CSS Disaster
Sean M. Hall AKA Dante wrote:
At first I though it was this:
@import url('screenstyles.css') screen;
I use single quotes so IE5/Mac won't see the stylesheet. But I switched to double quotes and still no luck. Removed the screen; part. Nein. not yet. Removed the conditional comments for IE in the head section: no, no, nein.
It is that.
change it from
@import url('screenstyles.css') screen;
to
@import url(screenstyles.css);
See:
http://w3development.de/css/hide_css_from_browsers/import/
--
Kristof
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
RE: [WSG] Make em' pay for IE
Thanks Jamie, i know this is off topic, but you dont happen to work at the sky offices in Hudderfeild do you? I had the pleasure of being offered a job there when i was about 19/20 and bodged it by requesting to much salary... they never got back to me _ On Fri, 4 Jun 2004 12:43 , Jamie Mason [EMAIL PROTECTED] sent: RE: [WSG] Make em' pay for IE I agree word for word with Mark on this Jamie Mason: Design -Original Message- From: Mark Harwood WebMail [mailto:[EMAIL PROTECTED] Sent: 04 June 2004 12:23 To: [EMAIL PROTECTED] Subject: Re: [WSG] Make em' pay for IE Im sorry but you never ever suggest to a client that the site will not work in IE, 9 time out of 10 a client will only know about IE. If your suggesting standards you should know what and what not to do to make a standard site work accross all browsers. I would never ever suggest a site will take longer to do due to getting it to work in IE, if you have to do that state that there will be a extra Testing Period in which you will be working over multiple platforms and browsers to check all features are compatible. Your never gonna get a client that says i dont want this to work in ie! and if you ever did it more than like'ly the person could do it them self * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Linking External CSS
On 04/06/2004, at 10:02 PM, Jamie Mason wrote: What's the difference of linking by; @import url(styles.css); And link rel=stylesheet type=text/css href=styles.css / If any? @import(...) is not recognised by some older browsers (like NN4), it's helpful for keeping old browsers away from the new-school CSS for starters. --- Justin French http://indent.com.au * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Make em' pay for IE
Manuel González Noriega wrote: FYI, that concept is called MOSE and described here http://www.mezzoblue.com/archives/2003/06/25/mose/ Thanks. So someone with more clout than me said it about a year ago. What I'm adding is that we should let the client know we're doing it, but not charging them anything extra for it. And don't think of it as giving away free labor; think of it as investing a little extra time today in order to make your lives easier tomorrow. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Make em' pay for IE
Mark Harwood WebMail wrote: Im sorry but you never ever suggest to a client that the site will not work in IE, 9 time out of 10 a client will only know about IE. If your suggesting standards you should know what and what not to do to make a standard site work accross all browsers. I said the site should me 100% functional in IE; doing otherwise, in most cases, is foolish. I am suggesting additional, unneeded functionality. I would never ever suggest a site will take longer to do due to getting it to work in IE, In other words, you'll lie to your client because you think they're too stupid to understand that dealing with the problems in IE is one of the costs of doing business and no less real than paying taxes and the electric company. if you have to do that state that there will be a extra Testing Period in which you will be working over multiple platforms and browsers to check all features are compatible. Most clients will understand if you tell them that anyone who would give them the same quality site will also build compliant first and then patch; the only difference is that you respect them enough to let them know about it. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Make em' pay for IE
In other words, you'll lie to your client because you think they're too stupid to understand that dealing with the problems in IE is one of the costs of doing business and no less real than paying taxes and the electric company. Im sorry but i can safely say that i have no need to lie to my client as i get my project timelines correct the first time, i have no need to have to rework my projects due to issuse with IE as i know of the issuse IE has with CSS and i also have a pretty standard way of getting them all out of the way first time round. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
[WSG] lotus domino vs doctype
Sadly, with Lotus Domino the only reliable way to control DOCTYPE (as far as I can tell) is to generate the entire page from scratch with an agent. If your first print is a DOCTYPE, then Domino won't generate headers. But if you use Forms you get stuck with what Domino decides is best for you. But if you have to go to that trouble, Why use Domino at all? one might begin to wonder. --David
[WSG] Relative font sizes without relative dimension units
Hi Folks,
I was wondering if anyone has ideas for a simpler way of dealing with
this issue than I have.
The issue:
I like to set my font sizes in ems. I also use ems a lot to position
block elements so that my designs work better as people expand
contract their text sizes. The problem is for example if I have body
with font-size 1em and h1 with font-size 1.5em, then a 10em margin on
a div (within body) renders at 2/3 the size of the same 10em margin
on an h1.
The solution I've come up with is to enclose non-1em sized text in a
span tag and assign font size values with a contextual selector (e.g.
h1 span {font-size:1.5em}). The problem with this solution is that it
means adding quite a few semantically meaningless tags.
Anybody got a better idea?
--
Bill McAvinney
Massachusetts Institute of Technology
Web Services
Administrative Computing, IST
617-258-6023
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
RE: [WSG] CSS Disaster
Title: Message
Hi
Sean,
Interesting. Especially this
bit:
"For my new History Website redesign, I worked hard on creating a valid XHTML
1.0"
Allow
me to quote this from Simplebits a month ago...
"23. On May 6, 2004 8:08 PM,
Dante
said:
D: Dont use XHTML at
all.
Seriously though even if
I was silly enough to be using xHTML Id go with B.
Its hard for me to say
because Ill never ever need to use XHTML."
I guess a lot can change in a month, but
nothing so drastically or as often as your opinions. Oh and by the way, I
think Jeffrey Zeldman was talking about you in his recent Daily Report where he
mentions a certain someone on the discussion boards of A List Apart. Not
exactly the recognition you seem to consistently crave, but good
job.
Iain
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Sean M. Hall AKA DanteSent: 04 June 2004 02:53To:
[EMAIL PROTECTED]Subject: [WSG] CSS
Disaster"Dad, I'm not saying I wrecked the CSS.but I'm gonna need a new
stylesheet". This is how I feel right now. For my new History Website
redesign, I worked hard on creating a valid XHTML 1.0 Transitional structure
consisting of semantic, organized markup. I validated tha markup and the CSS
(which didn't validate cuz I use -moz-box-sizing). I worked hard, and even
added a DOM-driven behaviour layer. Opera 7.23 (IMHO, the best browser
ever) renders it beautifully, as I expected. Opera 7.23 rewards me for my hard
work, which is why I love it. How does IE repay me? By not loading the
bloody stylesheet at all (it does load the external .js file though). Period.
Nein. At first I though it was this: @import
url('screenstyles.css') screen; I use single quotes so IE5/Mac won't see
the stylesheet. But I switched to double quotes and still no luck. Removed the
screen; part. Nein. not yet. Removed the conditional comments for IE in the
head section: no, no, nein. Almost all of my visitors use IE, and I
have less than two weeks to solve the problem. CSS is an excellent
car, but IE is a broken muddy pothole-filled road. Anyone know any
bugs that prevent IE from loading a stylesheet?
Re: [WSG] Relative font sizes without relative dimension units
I could be wrong here but don't you just need to use descendant
selectors here?
#header h1{font-size: 1.5em;}
#content h1{font-size1.2 em; font-color: red;}
On 05/06/2004, at 1:13 AM, Bill McAvinney wrote:
The solution I've come up with is to enclose non-1em sized text in a
span tag and assign font size values with a contextual selector (e.g.
h1 span {font-size:1.5em}). The problem with this solution is that it
means adding quite a few semantically meaningless tags.
Anybody got a better idea?
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
RE: [WSG] Relative font sizes without relative dimension units
Bill,
funnily enough, this is a problem I've come across recently myself.
The only way around it that I can think of is to do the calculation
of padding/margin based on your font size by hand.
In your example, if you want a 10em margin around your h1, but
you've already set your h1 to 1.5em font size, then set the margin
to 6.66em.
e.g.
#content p { font-size: 1em; margin: 10em; }
#content h1 { font-size: 1.5em; margin: 6.66em; }
Tedious, but the only clean way I can see without cluttering the
markup with extra non-semantic containers...
Patrick
Patrick H. Lauke
Webmaster / University of Salford
http://www.salford.ac.uk
N.X+i nZv+hymjl.f.wq(b(,)azX)i
Re: [WSG] Standards Compliance -vs- User Enjoyment
I would recommend you do both - have a standards compliant accessable site, but include an interactive area. A xhtml/css php/mysql"photobook" with the club at certian nights - preferably the peak holiday periods. Give them the best of both worlds. a quick loading site with an area where they can have alot more interactive with the site. A guestbook would be excellent aswell. runnnig off a db accessed both by the interactive area and the xhtml css area. Camz - Original Message - From: Chris Stratford To: [EMAIL PROTECTED] Sent: Saturday, June 05, 2004 5:28 PM Subject: [WSG] Standards Compliance -vs- User Enjoyment Hey list,I have something which has been a major topic of discussion between a friend and I.I am currently working on a promotions website - promoting for Sydney Nightclubs (RB Scene)To knuckle down and get to the point - Do I use webstandards and efficent coding to make the website...Or do I use Flash, Verbose Table Layouts, Lots of Images Animations etc... To get people interested.Really it is a question of - do I make the website for viewer enjoyment, or for the widest viewer spectrum.I am not sure if many of you would be in the same situation, but I can imagine it has come up at least once with us all before.Whether its a news website, or a Hosting companies website...My situation is a very sticky one - Clubbers dont want web standards, they want to see - what they can't have - lots of pictures help, and sounds are good (ambient music, on/off switch of course).My website hasn't begun yet, although I have some rough ideas, one which my friend came up with:http://www.equicom.net/chris/test.htmlI think its great, doesnt use flash or anything.It was an eye opener thinking it was as simple as it was.It works in FireFox (exept sound) which is good...But the fact that it looks good with such a simply design.What are your opinions - and can you lend me any assistance.Web Standars are very important to me, and I would much rather use standards compliant code, than make 10 extra people per 100 happy because there is a boxed layout (like the demo website)...I could code that in CSS, but it wouldn't be as solid as it is with Tables.Anyway!Let me know what you all think!Cheers!Chris Stratford.
