date:20060312

Joshua Street wrote: On 3/13/06, Jay Gilmore <[EMAIL PROTECTED]> wrote: I have also read (no personal first hand knowledge) that there can be issues between using DOM/DHTML scripts and XHTML. I don't know what these issues are but why invite trouble. This arises from non-DOM methods, which are often much simpler to implement (and faster in terms of performance), such as innerHTML [1] (and document.write, but we won't go there). I *think* this is because innerHTML/outerHTML/document.write and their kin leave the XML tree alone -- any elements in the inserted content _aren't_ created as elements, and hence cannot be manipulated at all. Um... What the? Of course they are created as elements, or at least they should be, unless you're talking about some strange IE bug I'm not aware of. (I never use innerHTML so I'm not aware of all of its quirks.) AIUI, the way innerHTML is supposed to work is that the value is parsed as HTML or XML (depending on whether the document is HTML or XHTML; which is determined by the MIME type, not the DOCTYPE) and a DOM DocumentFragment is created. If it's XHTML, it should result in an error when the value is not well formed. Mozilla does this, but Opera doesn't because it always parses it as HTML. I'm not sure about other browsers. All children of the element are then removed from the tree and the new DocumentFragment is appended. I believe Mozilla internally uses its proprietary range.createContextualFrament() function to do this. (That aside, I don't really see anything wrong with this [innerHTML] -- we must remember that XMLHttpRequest object is also proprietary!) The problem is not that it's proprietary, there is actually work to get it standardised as part of the WHATWG's Web Apps proposal. The problem I have with it is that it's working with strings to manipulate the DOM, and those strings need to have escaped characters which get's quite messy, much like document.write(), but not quite as bad [1]. For instance, just to write one simple element with an attribute, it needs to be like this: ... foo.innerHTML = "

text<\/p>" ... My other problem with it is that it's specific to (X)HTML, not any generic XML like the rest of the DOM API is (except for, of course, DOM 2 HTML). IMHO, Mozilla's createContextualFragment() is much more useful for any DOM and I would like it to be standardised, but I don't see that happening any time soon. A much better alternative is to use E4X which is specially designed to make working with XML very easy, as XML is a native data structure, but support is currently too limited for real world usage. [1] document.write() is bad because of the way it throws more markup back to the parser during parsing which means instead of having a nice flow like this: input --> parser --> tree constructor --> output (DOM) document.write() makes it more like this: input --> parser --> tree constructor --> output (DOM) ^| |___doc.write()__| -- Lachlan Hunt http://lachy.id.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] Non-interactive Web display on wall screen?

2006-03-12 Thread Steve Olive



On 13/03/2006, at 9:03 AM, Tom Worthington wrote:

Has anyone advice to give on displaying web content on a non- 
interactive wall screen?


Opera has a kiosk mode:

http://www.opera.com/support/mastering/kiosk/

It can run this mode on Windows, Linux & OS X so even an older PC  
running Linux with just a lightweight windows manager would be  
suitable to run this. As was suggested elsewhere setting each page to  
 refresh and load the next page in the sequence would be the  
simplest way to do this.



Steve Olive
Bathurst Computer Solutions
e-mail: [EMAIL PROTECTED]
Mobile: 0407 224 251
Web: www.bathurstcomputers.com.au
 _
... (0)>
... / /\
.. / / .)
.. V_/_
Linux Powered!




**
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] (Opera) CSS print style problem with image

2006-03-12 Thread Philippe Wittenbergh



On Mar 13, 2006, at 1:26 PM, 郑玉萍 wrote:

I have spent many hours tweaking my CSS print style sheet and on  
google too to try to find out what triggers the problem that the  
header image link is broken in Opera. I found no answer and is  
hoping someone here has a remedy for me.


The problem is rather specific - I have a header image inserted in  
html page with display none in my media style sheet, and the reason  
for this is because client wants different header image to be seen  
on printing, therefore having the header image places in the header  
as background image is not a viable solution.


When set to {display:none} in the screen style sheet, Opera doesn't  
download the image. But once you try to print the image, Opera  
doesn't try to fetch that one image, it only relies on what is in  
your cache. Safari used to do the same, but that is fixed in version  
1.3/2.0.


A solution is to move your image of screen for screen display (like  
img {position:absolute; left: -1px}) instead of using  
{display:none}.

I once posted an article about this:


Philippe
---
Philippe Wittenbergh




**
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] CAPS in stylesheets

2006-03-12 Thread Gunlaug Sørtun


Jay Gilmore wrote:

I think many standards oriented people have moved or stayed with HTML
 4.0X and those who are using XHTML are either using it incorrectly 
and unknowing of its proper application or the minute few who are 
actually serving it as "application/xhtml+xml".


Don't forget those of us who actually serve our XHTML as 'text/html' for
now - *after* having made sure it works when served as
'application/xhtml+xml'. We're just waiting for the day we can safely
change MIME-type again.

Lachlan Hunt wrote:

Joshua Street wrote:

(with the exception of our esteemed friend Internet Explorer, which
 doesn't even attempt to render pages served as anything other than
 text/html).



...or text/plain. But that's another can of worms :-)


We can go fishing... ;-)

regards
Georg
--
http://www.gunlaug.no
**
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] CAPS in stylesheets

On 3/13/06, Jay Gilmore <[EMAIL PROTECTED]> wrote:
> I have also read (no personal first hand knowledge) that there can be
> issues between using DOM/DHTML scripts and XHTML. I don't know what
> these issues are but why invite trouble.

This arises from non-DOM methods, which are often much simpler to
implement (and faster in terms of performance), such as innerHTML [1]
(and document.write, but we won't go there). I *think* this is because
innerHTML/outerHTML/document.write and their kin leave the XML tree
alone -- any elements in the inserted content _aren't_ created as
elements, and hence cannot be manipulated at all. (That aside, I don't
really see anything wrong with this [innerHTML] -- we must remember
that XMLHttpRequest object is also proprietary!)

Obviously if you do this with an XML document then you wind up with
un-parsed structure (it renders, but it's not part of the tree), which
can mean problems. Apparently Firefox 1.5 copes okay with this,
somehow.

Josh

1.http://www.quirksmode.org/dom/innerhtml.html
**
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] CAPS in stylesheets

2006-03-12 Thread Mark Harris


sime wrote:
Which brings me back to my original question question. Rephrased, what 
are the different situations in which you'd use HTML4 over XHTML1? So 
far I've been led to believe (outside of this list) that XHTML is a step 
forward.


Ah, but, grasshopper, to step backward from the precipice may be a sign 
of wisdom ;-)


It's really a case of "you say tomahto, I say tomayto"

Some will tell you that there is no real need for XHTML, that it confers 
no special capability that websites require now and for the foreseeable 
future. Others will tell you it's the greatest thing since sliced bread, 
and will in fact slice your bread for you (as long as your breadbox is 
defined in XML).


My advice would be for you to analyse your project, analyse the options 
and determine which meets your needs best. If there are tags in XHTML 
that you can't live without, your choice is made. If you find you don't 
absolutely need it, then the choice is yours to make. Be aware that 
XHTML is less forgiving than HTML (even strict) and that most browsers 
currently won't care what you use, although even IE may barf on badly 
formed and served XHTML (or you might get lucky)


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] CAPS in stylesheets

2006-03-12 Thread Jay Gilmore


sime wrote:

define "practically redundant."



I consider HTML 4.01 strict to be "practically awesome" for new web
sites, but that's more of personal preference.


Which brings me back to my original question question. Rephrased, what 
are the different situations in which you'd use HTML4 over XHTML1? So 
far I've been led to believe (outside of this list) that XHTML is a step 
forward.


Many people, especially editor developers, have been implementing 
default DOCTYPES as either XHTML transitional and XHTML strict and many 
authors of great books have done the same but from what I understand is 
that many of these people have adopted XHTML incorrectly simply because 
it is newer.


Unfortunately, is is not made clear by the W3C -- in plain English and 
succinctly that it (XHTML) is not a replacement or update for HTML but a 
different spec altogether. There are uses for XHTML, but for most 
computer based web browsers there is no real advantage to XHTML as they 
just treat it as HTML anyway.


I have also read (no personal first hand knowledge) that there can be 
issues between using DOM/DHTML scripts and XHTML. I don't know what 
these issues are but why invite trouble. I think many standards oriented 
people have moved or stayed with HTML 4.0X and those who are using XHTML 
are either using it incorrectly and unknowing of its proper application 
or the minute few who are actually serving it as "application/xhtml+xml".


Jay

--
Jay Gilmore
Developer / Consultant
SmashingRed Web & Marketing
P] 902.529.0651
E] [EMAIL PROTECTED]
U] http://www.smashingred.com
B] http://www.smashingred.com/blog
**
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] CAPS in stylesheets


Joshua Street wrote:

(with the exception of our esteemed friend Internet Explorer, which
doesn't even attempt to render pages served as anything other than
text/html).


...or text/plain. But that's another can of worms :-)

--
Lachlan Hunt
http://lachy.id.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] CAPS in stylesheets

On 3/13/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> sime wrote:
> > I have never had a problem with the uppercase not working in strict.
> > Maybe I'm not defining strict correctly. Here is a test page which
> > works in FF,IE6: http://urbits.com/_/test.php
>
> Add this function call to the top of your PHP file:
> header("Content-Type: application/xhtml+xml");
> ?>

http://www.workingwith.me.uk/articles/scripting/mimetypes <-- good
article that extends what Lachlan said (so stuff works with IE,
amongst other things).

Josh
**
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] (Opera) CSS print style problem with image

2006-03-12 Thread 郑玉萍


Greetings,

I have spent many hours tweaking my CSS print style sheet and on  
google too to try to find out what triggers the problem that the  
header image link is broken in Opera. I found no answer and is hoping  
someone here has a remedy for me.


The problem is rather specific - I have a header image inserted in  
html page with display none in my media style sheet, and the reason  
for this is because client wants different header image to be seen on  
printing, therefore having the header image places in the header as  
background image is not a viable solution.


The page:
http://avanimedia.com/printmedia/pub_LANline.html

In my html






Media style sheet:
#headerPrint {display: none;}

Print style sheet
#headerPrint {
height: 130px;
width: 760px;
}

In the above page, there is a publication cover image and it's  
showing up from Opera printing, so I am gussing it is to do with
#headerPrint {display: none;} in the media sheet that maybe a bug of  
Opera (?).


The header image prints fine in IE, Safari and Gecko browsers.

Regards,

tee
lotus seeds design


**
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] CAPS in stylesheets


Christian said:


I think you might be alluding to using XHTML 1 served as text/html.
It's just as harmful as helpful, IMO, to the future of XML on the web.
People see XHTML pages served as text/html with errors and otherwise
non-xhtml behavior and think that XHTML is just another tag-soup
language that can be abused like HTML is. [1] I'm not going to go any
further into that territory as there's a lot of past discussions on
this list covering the same topic. The point is that any XHTML 1
doctype served as text/html could just be changed to an HTML 4 strict
doctype and the display will not change at all.

Thankyou Christion - that explanation helped me immensely. I wish I'd 
read that when I was

first researching this aspect of web design.
**
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] CAPS in stylesheets


sime wrote:
No, it will not work under XHTML at all. The DOCTYPE is irrelevant, 
XHTML is case sensitive and uppercase element selectors will not 
match anything in XHTML. It will only work for text/html.


I have never had a problem with the uppercase not working in strict. 
Maybe I'm not defining strict correctly. Here is a test page which 
works in FF,IE6: http://urbits.com/_/test.php


Add this function call to the top of your PHP file:



--
Lachlan Hunt
http://lachy.id.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] CAPS in stylesheets

2006-03-12 Thread Christian Montoya

On 3/12/06, sime <[EMAIL PROTECTED]> wrote:
> > define "practically redundant."
>
> > I consider HTML 4.01 strict to be "practically awesome" for new web
> > sites, but that's more of personal preference.
>
> Which brings me back to my original question question. Rephrased, what are 
> the different situations in which you'd use HTML4 over XHTML1? So far I've 
> been led to believe (outside of this list) that XHTML is a step forward.

XHTML is a step forward but every step forward involves a high risk of
stumbling.

You use XHTML 1 (served correctly as application/xhtml+xml) in
situations where you know for sure that the markup will never be
invalid, otherwise the pages won't display at all. You use HTML 4 in
situations where there is the slightest risk that you, your client, or
even your visitors could introduce invalid markup, in which case HTML
4 doesn't choke and stop displaying but rather just skips over the bad
tags and keeps going.

I think you might be alluding to using XHTML 1 served as text/html.
It's just as harmful as helpful, IMO, to the future of XML on the web.
People see XHTML pages served as text/html with errors and otherwise
non-xhtml behavior and think that XHTML is just another tag-soup
language that can be abused like HTML is. [1] I'm not going to go any
further into that territory as there's a lot of past discussions on
this list covering the same topic. The point is that any XHTML 1
doctype served as text/html could just be changed to an HTML 4 strict
doctype and the display will not change at all.

[1] don't know if it's the fault of the standards community but
somehow Google got misled into thinking that they can abuse XHTML the
way they abuse HTML:
http://sirokai.googlepages.com/home (view source and cry)

--
--
Christian Montoya
christianmontoya.com ... rdpdesign.com ... cssliquid.com
**
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] CAPS in stylesheets

On 3/13/06, sime <[EMAIL PROTECTED]> wrote:
> Rephrased, what are the different situations in which you'd use HTML4 over 
> XHTML1? So far
> I've been led to believe (outside of this list) that XHTML is a step forward.

You're serving your XHTML as text/html, so it's effectively being
parsed as HTML anyway. If you were using XHTML served as
application/xhtml+xml (is that right? can't recall the exact string
right now...), which is as it should be if you actually have a reason
for using XHTML aside from "it's like HTML, only... extensible!"
(without knowing what extensible entails) then every time you had a
trivial markup error browsers would give a nice big parser error page
(with the exception of our esteemed friend Internet Explorer, which
doesn't even attempt to render pages served as anything other than
text/html).

XHTML *could* be a step forward if you desparately need to be able to
parse your pages and use XSLT or something, but barring that there's
absolutely nothing wrong with HTML 4. Even with XML, it's only
sensible to use a schema with widely recognised semantics -- so,
whilst you can theoretically add your own elements, etc., to an XML
document, there's no point if these elements exist outside the
vocabulary of any parsers (I'm thinking specifically of search
engines, but there are others for which this matters).

With XHTML for today's web, you can only really consider using it as
HTML anyway (unless you have a highly controlled intranet environment,
but that's internal) in terms of how it's served, and the scope of the
schema: and this latter point is unlikely to vary much even in the
future, one would hope, for the sake of backwards-compatability.

Josh
~ who hasn't ranted about XHTML vs HTML before at any great length and
may be slightly off on the specifics of certain points
**
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] CAPS in stylesheets

2006-03-12 Thread Jay Gilmore

sime wrote:
 > No, it will not work under XHTML at all. The DOCTYPE is irrelevant, 
XHTML is case
 > sensitive and uppercase element selectors will not match anything in 
XHTML. It will

 > only work for text/html.

I have never had a problem with the uppercase not working in strict. 
Maybe I'm not defining strict correctly. Here is a test page which works 
in FF,IE6: http://urbits.com/_/test.php

I checked the response headers using webdevtoolbar and your server is 
sending this as "text/html" and not "application/xhtml+xml".

Jay

--
Jay Gilmore
Developer / Consultant
SmashingRed Web & Marketing
P] 902.529.0651
E] [EMAIL PROTECTED]
U] http://www.smashingred.com
B] http://www.smashingred.com/blog
**
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] CAPS in stylesheets

On 3/13/06, sime <[EMAIL PROTECTED]> wrote:
> I have never had a problem with the uppercase not working in strict.
> Maybe I'm not defining strict correctly. Here is a test page which works
> in FF,IE6: http://urbits.com/_/test.php

You're serving it as text/html.
**
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] CAPS in stylesheets


define "practically redundant."



I consider HTML 4.01 strict to be "practically awesome" for new web
sites, but that's more of personal preference.


Which brings me back to my original question question. Rephrased, what are the 
different situations in which you'd use HTML4 over XHTML1? So far I've been led 
to believe (outside of this list) that XHTML is a step forward.
**
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] CAPS in stylesheets

> No, it will not work under XHTML at all. The DOCTYPE is irrelevant, 
XHTML is case
> sensitive and uppercase element selectors will not match anything in 
XHTML. It will

> only work for text/html.

I have never had a problem with the uppercase not working in strict. 
Maybe I'm not defining strict correctly. Here is a test page which works 
in FF,IE6: http://urbits.com/_/test.php


**
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] CAPS in stylesheets


sime wrote:

Christian Montoya

HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you
must write your CSS selectors in lowercase.


So that would make HTML4 practically redundant for new web sites?


What?  I don't understand how you came to that conclusion.


To Lea de Groot:
It worked in Strict which is why I've been misled for so long.


If you're talking about XHTML 1.0 Strict, then it will only work if 
you're using the wrong MIME type: text/html.  Serve your page as 
application/xhtml+xml and I doubt it will work.


--
Lachlan Hunt
http://lachy.id.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] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)

2006-03-12 Thread Christian Montoya

> Christian Montoya
> > HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you
> > must write your CSS selectors in lowercase.


On 3/12/06, sime <[EMAIL PROTECTED]> wrote:
>
> So that would make HTML4 practically redundant for new web sites?
>

define "practically redundant."

I consider HTML 4.01 strict to be "practically awesome" for new web
sites, but that's more of personal preference.


--
--
Christian Montoya
christianmontoya.com ... rdpdesign.com ... cssliquid.com
**
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] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)


Sorry about my poor subject line.

Christian Montoya

HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you
must write your CSS selectors in lowercase.


So that would make HTML4 practically redundant for new web sites?

To Lea de Groot:
It worked in Strict which is why I've been misled for so long.
Anyway, I'll fix that up and go back to being oblivious to the problems 
in my code. ;-)

**
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] Re: digest for wsg@webstandardsgroup.org


Lea de Groot wrote:

sime wrote:
However, I'm told that my code is therefore not XHTML compliant 
because of my use of uppercase. So who then is HTML4 relevant to?


I don't really understand the question.
As written, the css shown will work under HTML dtds (and XHTML 
transitional? I'm not sure as I never use it) but not XHTML strict DTDs.


No, it will not work under XHTML at all.  The DOCTYPE is irrelevant, 
XHTML is case sensitive and uppercase element selectors will not match 
anything in XHTML.  It will only work for text/html.


To make it work correctly for XHTML strict, you should change each tag 
name to lowercase.

Its a trivial change.


There's little point for authors to use that stylesheet, it is intended 
as a guide for browser implementors and was supposedly based on the 
default styles applied by browsers at the time.  (Although there are 
still many differences between that stylesheet and real world browsers)


--
Lachlan Hunt
http://lachy.id.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] Re: digest for wsg@webstandardsgroup.org

2006-03-12 Thread Lea de Groot


sime wrote:
I used the following as the foundation of my current approach to style 
sheets.

http://www.w3.org/TR/REC-CSS2/sample.html


If I am understanding it correctly, thats not meant for page 
developers/designers to base from, its meant for browser developers to 
start from.
You can expect that the default styles supplied by each browser will be 
something like these.
For a web developer to start with something like this would put an 
un-necessary large download on each page. (Yes, yes, I know - caching - 
but its still redundant)


However, I'm told that my code is therefore not XHTML compliant because 
of my use of uppercase. So who then is HTML4 relevant to?


I don't really understand the question.
As written, the css shown will work under HTML dtds (and XHTML 
transitional? I'm not sure as I never use it) but not XHTML strict DTDs.
To make it work correctly for XHTML strict, you should change each tag 
name to lowercase.

Its a trivial change.

HIH!
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
**

[WSG] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)

2006-03-12 Thread Christian Montoya

On 3/12/06, sime <[EMAIL PROTECTED]> wrote:
> I used the following as the foundation of my current approach to style
> sheets.
> http://www.w3.org/TR/REC-CSS2/sample.html
>
> However, I'm told that my code is therefore not XHTML compliant because
> of my use of uppercase. So who then is HTML4 relevant to?

HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you
must write your CSS selectors in lowercase. As a habit I've never
written CSS in caps, but that's just because I learned to write it in
lowercase.

Also please start a new thread rather than replying to the digest in
the future :)

--
--
Christian Montoya
christianmontoya.com ... rdpdesign.com ... cssliquid.com
**
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] Re: digest for wsg@webstandardsgroup.org

I used the following as the foundation of my current approach to style 
sheets.

http://www.w3.org/TR/REC-CSS2/sample.html

However, I'm told that my code is therefore not XHTML compliant because 
of my use of uppercase. So who then is HTML4 relevant to?

**
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] streaming video

2006-03-12 Thread Ben Buchanan

> can anyone give me some pointers for streaming video.  I know nothing, but
> it looks like my client base will want it and I need to know about it in
> general and guidance in particular from a reliable source.
> Suggestions?

We've done a little bit of video/streaming at work; not huge amounts
but from that:

1) We found the least painful method of embedding a player into a page
is to use Flash video or a Flash player. YMMV.

2) If you only need to do very small amounts of video, you may find
putting up "hinted" video files will suffice. Hinted video can be
opened off a garden-variety web server, the user's software will start
playing the file before the download is finished. While it's not true
"streaming" a lot of users won't know or care about the difference. I
don't know how to actually hint the files since we generally work with
video produced by other teams.

3) Streaming servers are good so long as they can handle the load you
are likely to experience. For really big/expensive/high-profile
events, you are probably better off outsourcing to streaming
specialists.

4) If you need to stream live, ditto on outsourcing. Unless you
*really* know what you're doing, you're better off hiring someone and
letting them stress about it ;)

cheers,

Ben

--
--- 
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson
**
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] Non-interactive Web display on wall screen?

2006-03-12 Thread Grant Bissett

Hi,
Firstly, no I don't have experience doing this, but:

- I'm pretty mozilla will take command line parameters to let you
start it full screen, without any of the browser chrome.

- a handful of pages with an old fashioned meta refresh should do
what you need

just a thought
-grant

On 13/03/2006, at 9:03 AM, Tom Worthington wrote:

Has anyone advice to give on displaying web content on a non-
interactive wall screen?

I was asked about content for a large screen as an electronic
information board in the foyer of a building. The display will not
be interactive but just cycle through some set information.

Creating content for such devices is an expensive and the novelty
of doing it wears off quickly. Most end up like the forlorn tourist
kiosks I saw in India, switched off and collecting dust www.tomw.net.au/blog/2005/12/electronic-tourist-kiosk.html>

Instead I thought of using a selection of existing web content from
the organization's web site. The screen can cycle through web pages
showing current events, profiles of people and projects. This would
require a few scripts to control the web browser and command it to
display a canned list of pages.

I did a quick mockup using the Opera browser and it looked okay,
with the browser forcing the web page to the width of the screen. I
could get a better result using carefully designed accessible web
pages , but the average page
seems to work okay.

Dose anyone have experience of doing this? Are there products to
adapt the browser and content? I had a look on the web and found
some Kiosk products, but these are for interactive exhibits.

Tom Worthington FACS HLM [EMAIL PROTECTED] Ph: 0419 496150
Director, Tomw Communications Pty LtdABN: 17 088 714 309
PO Box 13, Belconnen ACT 2617http://www.tomw.net.au/
Director, ACS Communications Tech Board http://www.acs.org.au/ctb/
Visiting Fellow, ANU Blog: http://www.tomw.net.au/blog/atom.xml
**
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] Non-interactive Web display on wall screen?

2006-03-12 Thread Patrick H. Lauke


Tom Worthington wrote:
Has anyone advice to give on displaying web content on a non-interactive 
wall screen?


It depends on what technology you'll be using. You could conceivably run 
the whole thing off a basic PC, with a browser set to full-screen and a 
bit of javascript in a frameset (1 hidden frame with the js, plus one 
full-size frame for the actual web page) to load different pages, if 
they fit. Or you could write a tiny bit of server-side script that 
scrapes pages for their content and displays them.


--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__
**
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] Re: Encoding test page

2006-03-12 Thread Andrew Cunningham

Keryx webb writes: 



According to my tests Firefox *will* use the charset specified in the 
http-header over the one in the XML-prologue if a page is sent as 
application/xhtml+xml. (Or more exactly, regardless whether the page is 
sent as text/html or application/xhtml+xml.) As will Opera. 



isn't that the way the browsers are supposed to operate? That the 
http-header has precedence? 



Andrew Cunningham
Multicultural Officer
Public Libraries Unit, Vicnet
State Library of Victoria
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] streaming video

2006-03-12 Thread Ric Raftis


Christina Porter wrote:

can anyone give me some pointers for streaming video.  I know nothing, 
but it looks like my client base will want it and I need to know about 
it in general and guidance in particular from a reliable source. 


If it's Flash, there is a thing called the "Satay Method" that removes 
the  tags plus other bits and pieces to make Flash code standards 
compliant.  Do a search at the Macromedia web site.  Their pages on it 
are easier  to read than the ones located elsewhere.


Regards,


Ric
**
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] streaming video

2006-03-12 Thread Christina Porter




can anyone give me some pointers for streaming 
video.  I know nothing, but it looks like my client base will want it and I 
need to know about it in general and guidance in particular from a reliable 
source. 
 
Suggestions? 
 
kind 
regards
 
Christina 
Porter
Wellington 
based

[WSG] Non-interactive Web display on wall screen?

2006-03-12 Thread Tom Worthington

Has anyone advice to give on displaying web content on a non-interactive 
wall screen?


I was asked about content for a large screen as an electronic information 
board in the foyer of a building. The display will not be interactive but 
just cycle through some set information.


Creating content for such devices is an expensive and the novelty of doing 
it wears off quickly. Most end up like the forlorn tourist kiosks I saw in 
India, switched off and collecting dust 



Instead I thought of using a selection of existing web content from the 
organization's web site. The screen can cycle through web pages showing 
current events, profiles of people and projects. This would require a few 
scripts to control the web browser and command it to display a canned list 
of pages.


I did a quick mockup using the Opera browser and it looked okay, with the 
browser forcing the web page to the width of the screen. I could get a 
better result using carefully designed accessible web pages 
, but the average page seems to work okay.


Dose anyone have experience of doing this? Are there products to adapt the 
browser and content? I had a look on the web and found some Kiosk products, 
but these are for interactive exhibits.




Tom Worthington FACS HLM [EMAIL PROTECTED] Ph: 0419 496150
Director, Tomw Communications Pty LtdABN: 17 088 714 309
PO Box 13, Belconnen ACT 2617http://www.tomw.net.au/
Director, ACS Communications Tech Board   http://www.acs.org.au/ctb/
Visiting Fellow, ANU  Blog: http://www.tomw.net.au/blog/atom.xml  


**
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] Encoding test page

2006-03-12 Thread Keryx webb


Hello all!

I month or so ago Lachlan and I had a discussion concerning how browsers 
interpret different ways of specifying charsets.


I've written a small test-page, located at:
http://ne.keryx.se/xhtmldemo/encoding_tests.php

(That server is primarily intended for the use of my students and I'd encourage 
you to set up a page of your own if you intend to use this more than once or twice.)


According to my tests Firefox *will* use the charset specified in the 
http-header over the one in the XML-prologue if a page is sent as 
application/xhtml+xml. (Or more exactly, regardless whether the page is sent as 
text/html or application/xhtml+xml.) As will Opera.


The meta-tag mostly seems to go ignored, at least for pages sent over http. 
There might be some issues with the servers default http-header settings or with 
 the browsers cache that I have not tested. The results differ somewhat when I 
test on my laptop (apache on Win) and on the public server (apache on Linux), 
but the apache response headers are exactly the same for both!



Lars Gunther

P.S. My script is attached.

Make sure there are no whitespace before the opening php-tag
as that will make it impossible to send http-headers.


Title: Encoding demo

* @license Creative Commons Share Alike
*/

define('ISO','iso-8859-1');
define('UTF','UTF-8');

// Set headers
$httpHeaderChar = 'Not set';
if ( isset($_POST['httpHeaderChar']) ) {
if (strcmp($_POST['httpHeaderChar'],'ISO') == 0 ) {
$httpHeaderChar = ISO;
} elseif (strcmp($_POST['httpHeaderChar'],'UTF') == 0 ) {
$httpHeaderChar = UTF;
}
}
$httpHeaderHtml = 'text/html'; // default
if ( isset($_POST['httpHeaderType']) && strcmp($_POST['httpHeaderType'],'xhtml') == 0 ) {
$httpHeaderHtml = 'application/xhtml+xml';
}


$headerString = $httpHeaderHtml;
$headerString.= ( $httpHeaderChar != 'Not set' ) ? '; charset='.$httpHeaderChar : '';
header('Content-type: '.$headerString);

ob_start();

// Set XML-prologue
$xmlPrologue = 'Not set';
if ( isset($_POST['xmlPrologue']) ) {
if (strcmp($_POST['xmlPrologue'],'ISO') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" encoding="'.ISO."\"?>\n";
} else if (strcmp($_POST['xmlPrologue'],'UTF') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" encoding="'.UTF."\"?>\n";
} else if (strcmp($_POST['xmlPrologue'],'NOCHAR') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" '."?>\n";
}
}
if ( $xmlPrologue != 'Not set' ) echo $xmlPrologue;

?>




  Test of different ways to specifying the encoding
  
The next paragraph should read "å, Å, ä, Ä, ö, Ö". But if
the browser interprets the text using the wrong charset, it will look weird or be squares or question marks.
  
  å, Å, ä, Ä, ö, Ö.
  Current values
  
a.k.a.ISO-8859-1';
echo 'Real encoding'.$realEncoding."\n";
echo 'Http-headers'.$headerString."\n";
echo 'XML-prologue'.htmlspecialchars($xmlPrologue)."\n";
echo 'Meta-tag'.htmlspecialchars($metaString)."\n";
?>
  
  

  Specify encoding for the page
  
  Encode page with UTF-8.
  
  Encode page with Latin-1 (default).


  Set new values for HTTP-header
  
  Set http-header to UTF-8.
  
  Set http-header to Latin-1.
  
  Do not specify charset in http-header (default).
  
  
  Set http-header to text/html (default).
  
  Set http-header to application/xhtml+xml.


  Set new values for XML-prologue
  
  Set XML prologue to UTF-8.
  
  Set XML prologue to Latin-1.
  
  Do not specify charset in XML-prologue.
  
  Do not include XML-prologue at all (default).


  Set new values for the meta-tag
  
  Set meta-tag to UTF-8.
  
  Set meta-tag to Latin-1.
  
  Do not set meta-tag at all (default).


  

  
  
  Apache response headers

Re: [WSG] Some studies about web standards usage (sites of Estonia and W3C members)

2006-03-12 Thread Rene Saarsoo


Rimantas Liubertas wrote:



Quite interesting, but one thing confuses me: no HTML 4.01 Strict?



Only 50 pages used HTML 4.01 Strict (of those 7 were valid).
That's probably because when most people make a move to Strict,
they also move to XHTML.


Lachlan Hunt wrote:


This article states:
 | Character encodings
|
| 111 pages had no encoding specified in HTML. Of course not a
| requirement, but belongs to a good style.
 Wrong.  It is a requirement to specify the character encoding correctly.
It would be useful if your statistics indicated not only what encodings
were used, but whether they were specified in HTTP headers, the meta
element, the XML declaration or a combination of them, incl. how many did
so for each MIME type and how many had conflicting values.


What I meant was - it's not a requirement to specify character encoding
in HTML by using the meta element.

My methodology/script had some shortcomings (which I'll hope to improve
in future) and one of them was, that encoding-information was only
searched from meta-elements.


Lachlan Hunt also wrote:


Regarding the list of DOCTYPEs, it would be useful if you indicated which
HTML ones included the System Identifier so that it is possible to
determine which ones trigger standards mode, almost standards mode or
quirks mode.  For example, in Mozilla, HTML 4.01 Transitional will  
trigger

quirks mode without the SI and almost standards mode with the SI.


And that's another shortcoming - quite little information was gathered  
about

the doctypes, but thanks for pointing this out, I'll hope to improve...

And thanks for the feedback.

--

Rene Saarsoo
**
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] Some studies about web standards usage (sites of Estonia and W3C members)

2006-03-12 Thread Kim Kruse


Hi Rene,

IMO a very impressing piece of work. Your survey shows the same tendency 
as in Denmark. It's slowly but steady getting better. Thanks for sharing


Kim

Rene Saarsoo wrote:


Hi,

I have made some further studies on Estonian web sites.

Compared to the survey done in August, the number of
valid sites has grown almost 50%.

http://triin.net/2006/03/11/Web_Standards_in_Estonia_vol_3

Also I tested the sites of W3C member organisations, and
found, that compared to the previous investigations (done
four years ago by Marko Karppinen) when only 2% of the
sites were valid, now 17% is.

http://triin.net/2006/03/05/Validating_sites_of_W3C_members

Hope, this information brings smile on your faces :)

--

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

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





--


Med venlig hilsen/Best regards

Kim Kruse
-
http://www.mouseriders.dk


**
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] Some studies about web standards usage (sites of Estonia and W3C members)