Free embedded realtime software & docs

Chris Hills wrote:
> Michael Schnell <mschnell_at_bschnell_dot_de@aol.com> writes
>
>>> That's good  coming from someone with an aol address :-)
>>
>> :) :) :) It's intended to confuse the spammers' search engines
>> not the readers :) :) :)
> 
> Actually it looks like a VERY good idea! I might to that to mine.
> Most of the spam comes out of the US so why shouldn't it go back
> to AOL :-)

>From which I assume your reply-to is false.  If so, simply switch
the 'from' and the 'reply-to' content.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

>From which I assume your reply-to is false.  If so, simply switch
> the 'from' and the 'reply-to' content.


OOps. I don't see a "reply-to" with my forum messages.

-Michael

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:53dkxWIZsiNGFAem@phaedsys.demon.co.uk...
> In article <f15780$van$1@online.de>, Martin Raabe 
> <Martin.Raabe@NOSPAM_BaSystem.de> writes
>>Hello folks,
>>
>>Chris Hills schrieb:
>>> In article <4635c201$0$24627$8404b019@news.wineasy.se>, David Brown
>>> <david@westcontrol.removethisbit.com> writes
>>>> dmctek.googlepages.com wrote:
>>>>> On Apr 30, 8:14 am, anon <a...@no.no> wrote:
>>>>>> dmctek.googlepages.com wrote:
>>>>>>> dmctek.googlepages.com
>>>> Your website is unusable.
>>>
>>> I can read it OK (IE6)
>>
>>I can't see any text either on Firefox 2.x or IE6.
>>But there is kind of a content on dmctek.googlepages.com/index.html, but
>>th enavigation is broken and no Name and contact info to be found.
>>
>>This can't be professional!
>
> Well yes it can... There are many people in the embedded world who are 
> very good but have no real idea when it comes to web stuff.  (I bought in 
> a template because it was a bit beyond me)
>
> The OP may not realise what is required, or rather what should be avoided 
> to work in most browsers. I tend to have the settings on my web authoring 
> tool set to permit 90% of browsers and test on three browsers. IE, 
> Netscape (an old one) and Safari.
>
> However it is not professional to not check if your web site works with 
> several browsers in your target market.

While using several browsers to check a new site is better than not checking 
at all, I'd suggest that the proper way to test a site is to submit each 
page to the W3C HTML validator at:
  http://validator.w3.org/

If it yields errors (and if you're using a WYSIWYG web editor, it almost 
certainly will), it pays to understand them - and hence ultimately write 
proper W3C-compliant code.

Having said that, there are still cases where good code will render 
differently with different browsers - but even then one learns to code in 
browser-independent ways.

One reason why IE6 (etc) is not a great site checker is that it's too 
tolerant of malformed HTML. While tolerance might seem like a good idea, 
it's actually against the spirit of the W3C spec (which suggests that a 
browser encountering malformed code should show nothing). The rationale here 
is to try to improve the quality of the HTML out there, most of which is 
close to disastrous.

Steve
http://www.fivetrees.com (and yes, feel free to run the validator on these 
pages ;))

In article <S8idnd10sYlr4qHbnZ2dnUVZ8tWnnZ2d@pipex.net>, Steve at 
fivetrees <steve@NOSPAMTAfivetrees.com> writes
>"Chris Hills" <chris@phaedsys.org> wrote in message
>news:53dkxWIZsiNGFAem@phaedsys.demon.co.uk...
>> In article <f15780$van$1@online.de>, Martin Raabe
>> <Martin.Raabe@NOSPAM_BaSystem.de> writes
>>>Hello folks,
>>>
>>>Chris Hills schrieb:
>>>> In article <4635c201$0$24627$8404b019@news.wineasy.se>, David Brown
>>>> <david@westcontrol.removethisbit.com> writes
>>>>> dmctek.googlepages.com wrote:
>>>>>> On Apr 30, 8:14 am, anon <a...@no.no> wrote:
>>>>>>> dmctek.googlepages.com wrote:
>>>>>>>> dmctek.googlepages.com
>>>>> Your website is unusable.
>>>>
>>>> I can read it OK (IE6)
>>>
>>>I can't see any text either on Firefox 2.x or IE6.
>>>But there is kind of a content on dmctek.googlepages.com/index.html, but
>>>th enavigation is broken and no Name and contact info to be found.
>>>
>>>This can't be professional!
>>
>> Well yes it can... There are many people in the embedded world who are
>> very good but have no real idea when it comes to web stuff.  (I bought in
>> a template because it was a bit beyond me)
>>
>> The OP may not realise what is required, or rather what should be avoided
>> to work in most browsers. I tend to have the settings on my web authoring
>> tool set to permit 90% of browsers and test on three browsers. IE,
>> Netscape (an old one) and Safari.
>>
>> However it is not professional to not check if your web site works with
>> several browsers in your target market.
>
>While using several browsers to check a new site is better than not checking
>at all, I'd suggest that the proper way to test a site is to submit each
>page to the W3C HTML validator at:
>  http://validator.w3.org/

This proves my point... I have no idea what W3C is (I shall endeavour to 
find out.)

>
>If it yields errors (and if you're using a WYSIWYG web editor, it almost
>certainly will), it pays to understand them - and hence ultimately write
>proper W3C-compliant code.

I use Dreamweavr set to do html for a very wide selection of browsers. 
I rune the checker on that as well as testing in 3 browsers.  OTOH my 
web sites tend to be simple. I am an embedded Engineer not a web 
programmer.

>One reason why IE6 (etc) is not a great site checker is that it's too
>tolerant of malformed HTML. While tolerance might seem like a good idea,

Not really because if it is tolerant it will let though a lot that 
others will have difficulty reading.

>browser encountering malformed code should show nothing). The rationale here
>is to try to improve the quality of the HTML out there, most of which is
>close to disastrous.

I agree.

>Steve
>http://www.fivetrees.com (and yes, feel free to run the validator on these
>pages ;))

Thanks

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:8sEVncB37bPGFA$3@phaedsys.demon.co.uk...
> In article <S8idnd10sYlr4qHbnZ2dnUVZ8tWnnZ2d@pipex.net>, Steve at 
> fivetrees <steve@NOSPAMTAfivetrees.com> writes
>>
>>While using several browsers to check a new site is better than not 
>>checking
>>at all, I'd suggest that the proper way to test a site is to submit each
>>page to the W3C HTML validator at:
>>  http://validator.w3.org/
>
> This proves my point... I have no idea what W3C is (I shall endeavour to 
> find out.)

The W3C (WorldWideWeb Consortium) are the people who are responsible for the 
specs for HTML and XHTML ;).

> I use Dreamweavr set to do html for a very wide selection of browsers. I 
> rune the checker on that as well as testing in 3 browsers.  OTOH my web 
> sites tend to be simple. I am an embedded Engineer not a web programmer.

Well, yes, I take your point. But (X)HTML is a fairly simple language 
(albeit usually rendered incomprehensible by them thar WYSIWYG editors) - no 
conditionals or loops ;). I found it far easier to learn XHTML/CSS than to 
find an editor whose output I actually approved of.

My main tip is the same one that W3C are promoting: separate content (HTML) 
from style (CSS). If the HTML contains anything to do with fonts, colours, 
or positions, there's a better, simpler way of doing it.

Steve
http://www.fivetrees.com 

Steve at fivetrees wrote:
>>One reason why IE6 (etc) is not a great site checker
>>is that it's too tolerant of malformed HTML.
>>While tolerance might seem like a good idea,
>>
Chris Hills wrote:
>Not really because if it is tolerant it will let though a lot
>that others will have difficulty reading.
>
...and produce what??  **Bad guesses** is what.

>>browser encountering malformed code should show nothing).
>>The rationale here is to try to improve the quality of the HTML out there,
>>most of which is close to disastrous.
>>
>I agree.

It appears that you agree with "disastrous"
but not with "improve the quality".

The solution to better Web pages is **ignore broken code**.
M$ is the scourge of the Internet.
http://www.google.com/search?q=cache:w100CwTtO_MJ:en.wikipedia.org/wiki/Embrace,_extend_and_extinguish+United.States.v.Microsoft.antitrust.trial+*-*-*-Department-of-Justice+*-competitors-that-do-not-*-*-support-Microsoft's.extensions+*.describe.Microsoft's.strategy+*-goal-*-*-*-*-to-monopolize-a-*-category+features-not-*-*-*-*-*-*-part-of-the-standard

Op Sat, 05 May 2007 15:00:32 +0200 schreef Steve at fivetrees  
<steve@NOSPAMTAfivetrees.com>:
> [...] there are still cases where good code will render
> differently with different browsers - but even then one learns to code in
> browser-independent ways.

I consider it a Good Thing(TM) if good code is able to render  
differently.  It means that the browser is taking decisions based upon the  
user's default font face, colour and size as well as the size of the page,  
whether that be a printed page or a raster screen page.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

"Boudewijn Dijkstra" <boudewijn@indes.com> wrote in message 
news:op.ttwq0ryoy6p7a2@ragnarok.lan...
> Op Sat, 05 May 2007 15:00:32 +0200 schreef Steve at fivetrees 
> <steve@NOSPAMTAfivetrees.com>:
>> [...] there are still cases where good code will render
>> differently with different browsers - but even then one learns to 
>> code in
>> browser-independent ways.
>
> I consider it a Good Thing(TM) if good code is able to render 
> differently.  It means that the browser is taking decisions based upon 
> the  user's default font face, colour and size as well as the size of 
> the page,  whether that be a printed page or a raster screen page.

Point very much taken. The W3C Accessibility Guidelines make it very 
clear that the site's CSS is really only a suggestion, and the user 
should be able to totally override it - for instance to provide 
high-contrast text in a large font for a visually-impaired user. At the 
very least, the user should be able to control text size - if s/he 
can't, this is a Bad Thing(tm).

Of course, this also means that the X/HTML should be properly 
structured: heading tags, for instance, should only be used for 
headings. (I've seen them used too often for emphasis.) All of which 
means Good Code.

And yes, a good site should adapt gracefully to the browser environment 
(platform, resolution, overriden font sizes/colours). This point seems 
to be lost on the graphics designers who infest the PR agencies used by 
the corporates, who have *still* yet to grasp the fact that the web is a 
different medium from paper.

Steve
http://www.fivetrees.com