Re: [WSG] Re: XHTML Strict alternative to ol start=11

2005-02-09 Thread Andy Budd
Patrick H. Lauke wrote:
Sorry, ended up being a cyclic argument, but you see what I mean...and 
*that's* what Andy meant (if I may be so bold as to make an educated 
guess)
That's exactly what I meannt.
Go for your life :-)
Andy Budd
http://www.message.uk.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] Re: XHTML Strict alternative to ol start=11

2005-02-08 Thread Andy Budd
Ian Fenn wrote:
Thanks for that, Douglas. Unfortunately my client has accessibility
guidelines that insist the pages are built in XHTML Strict.
So what do they believe the accessibility advantages of XHTML Strict 
are? As far as I'm aware valid and semantically correct HTML is just as 
accessible as XHTML strict. And I'm guessing they probably aren't 
serving their pages up as XML so strictly speaking they are serving 
their pages up as HTML anyway.

This kind of pettiness and misunderstanding of accessibility really 
gets my goat.

It's a damn shame if you ask me ;-)
Andy Budd
http://www.message.uk.com/
p.s. no real goats were harmed in this email
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Ian Fenn
Hi Andy,

 So what do they believe the accessibility advantages of XHTML Strict
 are? As far as I'm aware valid and semantically correct HTML is just as
 accessible as XHTML strict. And I'm guessing they probably aren't
 serving their pages up as XML so strictly speaking they are serving
 their pages up as HTML anyway.

Whilst the guidelines contain explanation for some of its contents, there's
nothing about the decision to go with XHTML Strict. The guidelines were
drawn up with the RNIB as consultants so they do have some integrity though.

All the best,

--
Ian Fenn
Chopstix Media
http://www.chopstixmedia.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] Re: XHTML Strict alternative to ol start=11

2005-02-08 Thread Geoff Deering
 Andy Budd wrote:
 So what do they believe the accessibility advantages of XHTML Strict
 are? As far as I'm aware valid and semantically correct HTML is just as
 accessible as XHTML strict. And I'm guessing they probably aren't
 serving their pages up as XML so strictly speaking they are serving
 their pages up as HTML anyway.
 
 This kind of pettiness and misunderstanding of accessibility really
 gets my goat.
 
 It's a damn shame if you ask me ;-)
 
 Andy Budd
 
 http://www.message.uk.com/

There are a number of advantages to using HTML/XHTML Strict.

Firstly, the term strict implies the strict separation between content and
presentation.  This is meant to have benefit for both user and developer (in
an ideal world).  It is meant to free up both the user and designer.

Normally with think STRICT, those W3C Nazis (like I saw recently on
another list:-), but the whole idea behind Strict is the strict separation
of content and presentation, ultimately aiming for both users and designers
worlds to be much more free and flexible.  That's the point.

Using strict frees the markup of attributes that are bound to the content
layer.  This ideally frees the web pages to accommodate more flexible
designs.  With strict you could develop alternate style sheets, one with
absolute units (to satisfy client requirements), and one with relative units
(to satisfy accessibility requirements), whatever you want.

If you use transitional, that is exactly what you are doing, and you may
need to do it, strict may not work for your design because of current lack
of support and other things, but you are using a DTD that is transitional
between the aim of separating content and presentation, and mixing them
together.  It's basically a compromise.

From a developer's point of view, in large content systems, one of the major
problems is separating content from presentation.  It is very difficult to
regenerate sites with fresh designs if this issue is not addressed at the
foundation level.  This also aids addressing accessibility issues.

We just have to look at any of our own work, when better user agent support
arrives in the future, and the customer requires a redesign, will we be able
to leave the HTML/XHTML as is, and just modify the CSS, or will it require
an overhaul of both?

Regards
Geoff Deering

**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Patrick H. Lauke
Geoff Deering wrote:
There are a number of advantages to using HTML/XHTML Strict.
[...]
If you use transitional, that is exactly what you are doing, and you may
need to do it, strict may not work for your design because of current lack
of support and other things, but you are using a DTD that is transitional
between the aim of separating content and presentation, and mixing them
together.  It's basically a compromise.
I think what Andy meant (as I've got a feeling he's well in the know 
when it comes to css and separation of content and presentation) is what 
the advantages are if you can effectively write strict code while still 
declaring a transitional doctype. Yes, transitional doesn't make certain 
elements illegal, but that doesn't mean that developers can't do nicely 
separated content/HTML and presentation/CSS which happen to have a 
transitional doctype. There are *no* inherent benefits to tableless, css 
driven layouts in XHTML strict versus tableless, css driven HTML (strict 
or transitional) or even XHTML transitional. In particular, when served 
as text/html rather than application/xhtml+xml, and when not mixing in 
additional X technologies, for all intents and purposes XHTML is 
simply HTML with a slightly funkier syntax (self-closing elements for 
instance) which older browsers treat like broken HTML. There is no added 
benefit to the user. All the things you mention (switching stylesheets 
for different layouts, etc) can be done fine in transitional.

XHTML (and strict in particular) being more accessible than HTML (and 
particularly transitional) is a myth. Conscientious coders can use 
exactly the same approach (tableless etc) in both.

Sorry, ended up being a cyclic argument, but you see what I mean...and 
*that's* what Andy meant (if I may be so bold as to make an educated guess)

--
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
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Peter Firminger
Can I just offer an opinion here.

When thinking of semantics it sometimes helps to go back 20 years and use
pen and paper.

If you were writing a big list (numbering each item) in a small notepad you
would, on successive pages, keep the numbering going. So on the second page,
the first item may be number 11.

Putting that into a search result context, the 500 results from a search are
one list. If you are kind enough to break that into pages, the list is still
the same one so starting the list on the second page from record 11 and
numbering it that way is, in my view, correct.

Now, depending on how you do it you can only make that page only available
to someone that already saw the first page (using form method post)
however most of us have search results that can be linked to (using method
get in a form or dynamically writing a link with a query string).

E.g. http://www.seaslugforum.net/list.cfm?startrow=31

You'll note the text Messages 31 to 60 of 8740 to put the list in context.

I see no problem with this. In fact if the list on the second page started
at 1 I think it would be more confusing.

P


**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Geoff Deering
 Patrick H. Lauke wrote:
 I think what Andy meant (as I've got a feeling he's well in the know
 when it comes to css and separation of content and presentation) is what
 the advantages are if you can effectively write strict code while still
 declaring a transitional doctype. Yes, transitional doesn't make certain
 elements illegal, but that doesn't mean that developers can't do nicely
 separated content/HTML and presentation/CSS which happen to have a
 transitional doctype. There are *no* inherent benefits to tableless, css
 driven layouts in XHTML strict versus tableless, css driven HTML (strict
 or transitional) or even XHTML transitional. 

That is a misconception.  There are differences to the way a rendering
parsing engine will work with the different doctypes.  Just as a C
programmer thinks what will the compiler do with this code, there needs to
be some understanding of what is happening at the parser level.  That's also
why this list exists, because, from what I can see is that most of us need a
list like this so that we can deal with the bugs that are in the parsers and
rendering engines.  But I'm also talking about working with bug free
parsers, even if that is in the future.  In that case there is quite a bit
of difference with the way a parser will work with the same design in Strict
as it will in Transitional.  If we fail to understand that we are failing to
understand what is happening with DOCTYPE parsing and rendering.

I can understand why you'd use Transitional, where you could use Strict, ie
where there may be a lack of browser support for a particular design
implemented in Strict, but not supported properly, so you'd use
Transitional.  But it makes no sense to use Transitional where Strict does
exactly the same job.

 In particular, when served
 as text/html rather than application/xhtml+xml, and when not mixing in
 additional X technologies, for all intents and purposes XHTML is
 simply HTML with a slightly funkier syntax (self-closing elements for
 instance) which older browsers treat like broken HTML. There is no added
 benefit to the user. All the things you mention (switching stylesheets
 for different layouts, etc) can be done fine in transitional.

You are missing my point completely.  Try maintaining or redesigning large
content sites that need to meet web and accessibility standards that are
caught in this dilemma.

I'm surprised both of you, who have more knowledge than I do in the design
area, have not come across this very problem.  I really see it as something
basic that web developers who take accessibility and web standards as their
core approach would understand that to redesign sites that meet valid strict
(either HTML or XHTML), are much easier to rework than Transitional.

And it has very little to do with the deprecated elements.  The real lose is
the attributes for elements found in both DTDs, which are not part of
Strict, because they are presentational by nature.

 XHTML (and strict in particular) being more accessible than HTML (and
 particularly transitional) is a myth. Conscientious coders can use
 exactly the same approach (tableless etc) in both.
 

Please explain why you would use a transitional DTD where a Strict one is
valid and works just as well?

Regards,
Geoff Deering

**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Jalenack
Hey, I'm new here :-)

In response to Geoff's email,

XHTML is the web standard of the future. If we implement it now, we
are just helping move it along faster.  A friend of mine recently
created a php script that makes your XHTML into HTML for browsers that
cannot support it. You can check it out at
http://blog.geoffers.uni.cc/archives/2005/01/07/xhtml-html . It sends
application/xhtml+xml to browsers who can take it..and text/html to
browsers that cannot.

On transitional DTDs, they are meant to transitional, eh? So that you
can blend your old methods into brand new ones without using invalid
code. If you're going to use new methods only, there's no point of
using a transitional DTD. XHTML was first introduced in 2000, and
we're still transitioning. Ugg..

Regards,
Andrew Sutherland
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread James Bennett
On Wed, 9 Feb 2005 11:49:55 +1100, Geoff Deering [EMAIL PROTECTED] wrote:
 Please explain why you would use a transitional DTD where a Strict one is
 valid and works just as well?

Depends on the client and how they'll be maintaining their site; I've
handed sites over to clients before who were going to use something
like Frontpage or Composer to write bits of content which they would
then drop into their page template, and going Transitional can keep
them valid where Strict wouldn't.

Then there are clients who I'm setting up with a CMS that I can set up
to generate content which is always valid in Strict, so I'll use
Strict.

In other words, there is no hard and fast always use foo rule for DOCTYPEs.

-- 
May the forces of evil become confused on the way to your house.
  -- George Carlin
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Patrick H. Lauke
Geoff Deering wrote:
That is a misconception.  There are differences to the way a rendering
parsing engine will work with the different doctypes.
Ok, let's narrow down the field to the core issue: what are the 
rendering differences between XHTML1.0 Transitional and XTHML1.0 Strict?

Ok, now the clincher: provided that these differences are not show 
stoppers (i.e. all of a sudden a browser trying to render XHTML1.0 
Transitional makes everything disappear, overlap, scale down to 
infinitesimal size, etc), how are they having a majorly detrimental 
effect on accessibility?

I can understand why you'd use Transitional, where you could use Strict, ie
where there may be a lack of browser support for a particular design
Not talking design (as in visual design), but features relating to the 
markup/content itself (i.e. the start attribute on OL).

But it makes no sense to use Transitional where Strict does
exactly the same job.
In certain edge cases (like this one we're discussing) I think it does 
indeed make sense. By dropping start you are losing semantic information.

You are missing my point completely.  Try maintaining or redesigning large
content sites that need to meet web and accessibility standards that are
caught in this dilemma.
I do. Did a redesign on a fairly large University site and rolled out 
the first phase as XHTML1.0 Transitional, and only later moved to Strict 
once the legacy systems were changed to spit out clean markup. Most of 
the web authors across the University are still using my Transitional 
template (for various reasons - mainly them having their own legacy 
systems to contend with). No problems in maintenance (over 1 1/2 years 
now) and no reports of accessibility problems on the grounds of my 
DOCTYPE choice.

I'm surprised both of you, who have more knowledge than I do in the design
area, have not come across this very problem.  I really see it as something
basic that web developers who take accessibility and web standards as their
core approach would understand that to redesign sites that meet valid strict
(either HTML or XHTML), are much easier to rework than Transitional.
If we're talking purely from a visual layout point of view, of course 
settling for Strict is the only way to fly. However, this discussion 
revolves around the accessibility. I still haven't seen any evidence 
that Transitional (which, granted, can have subtle differences in its 
*visual* rendering) is less accessible than Strict (all other things 
being equal, i.e. tableless layout, no use of deprecated or 
presentational elements, etc). There's no killer feature in Strict which 
instantly makes it more accessible. Nada.

And it has very little to do with the deprecated elements.  The real lose is
the attributes for elements found in both DTDs, which are not part of
Strict, because they are presentational by nature.
Again, just because the attributes are in the DTD, doesn't mean that I 
have to use them. I can write Transitional avoiding all the 
presentational attributes, and it's still Transitional if I so declare 
it. The main point is that there are a few things (like the start 
attribute) which have been thrown out of the window in Strict which are 
*not* presentational. Yes, in the utopian world of W3C standards, CSS 
will take care of things like numbering. However, for accessibility 
reasons, the page still needs to make sense without stylesheets...so, in 
actual fact (and bringing it down to the concrete example again) using 
ol without start and relying on CSS in Strict is *less* accessible 
than using ol start=... in Transitional.

Please explain why you would use a transitional DTD where a Strict one is
valid and works just as well?
That's the point: in this instance, it does NOT work just as well.
--
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
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Paul Connolley
On 9 Feb 2005, at 00:49, Geoff Deering wrote:
Patrick H. Lauke wrote:
There are *no* inherent benefits to tableless, css
driven layouts in XHTML strict versus tableless, css driven HTML 
(strict
or transitional) or even XHTML transitional.
That is a misconception.
Provided the XHTML document has been extended and that the correct 
content-type header has been sent for the document (application/x) 
there are *no* benefits. Pages don't load faster because no current 
browser will incrementally load the page. Mozilla themselves even 
recommend that you do *not* send it as application/xhtml+xml because of 
the slower rendering.

With a HTML document (strict or otherwise) the rendering occurs 
incrementally

There are differences to the way a rendering
parsing engine will work with the different doctypes.
No. There are differences in the way things such as box models are 
handled and the like. This is to do with Quirks mode and not to do with 
benefits of XHTML strict over HTML strict.

That's also
why this list exists, because, from what I can see is that most of us 
need a
list like this so that we can deal with the bugs that are in the 
parsers and
rendering engines.
If you think that this list will deal with parsing and rendering bugs 
you are probably mistaken. You could probably discuss them and talk by 
all means but the real work gets done when you submit bug reports to 
bugzilla and the like.

But I'm also talking about working with bug free
parsers, even if that is in the future.In that case there is quite a 
bit
of difference with the way a parser will work with the same design in 
Strict
as it will in Transitional.
Considering that Internet Explorer are reported to have said that they 
didn't want to change the IE engine because it would 'break the WWW' 
and also considering that Mozilla even chose to *have* a quirks mode I 
think that you will see the existence of quirks mode for a long time to 
come.

But it makes no sense to use Transitional where Strict does
exactly the same job.
Reverse this statement and realise that it means nothing.
In particular, when served
as text/html rather than application/xhtml+xml, and when not mixing in
additional X technologies, for all intents and purposes XHTML is
simply HTML with a slightly funkier syntax (self-closing elements for
instance) which older browsers treat like broken HTML. There is no 
added
benefit to the user. All the things you mention (switching stylesheets
for different layouts, etc) can be done fine in transitional.
You are missing my point completely.  Try maintaining or redesigning 
large
content sites that need to meet web and accessibility standards that 
are
caught in this dilemma.
I have seen some real messes in my short time and I know that HTML 
transitional can be just as accessible as XHTML strict. All the 
elements available to XHTML strict are available in HTML transitional. 
A perfectly validating XHTML strict document has just as much chance to 
be inaccessible as a HTML transitional.

Try creating an XHTML Strict document which validates and then convert 
it to a HTML document (by removing the forward slashes from 
self-closing elements) and then change the DTD to HTML transitional. 
Open both in a text only browser and compare them. If you see any 
differences then let me know.

I really see it as something
basic that web developers who take accessibility and web standards as 
their
core approach would understand that to redesign sites that meet valid 
strict
(either HTML or XHTML), are much easier to rework than Transitional.
Once again you are saying that a HTML transitional document can't 
contain all the same elements as an XHTML strict document.

Please explain why you would use a transitional DTD where a Strict one 
is
valid and works just as well?
As before, reverse the two subjects and see that the statement is still 
true:
Please explain why you would use a Strict DTD where a transitional one 
is valid and works just as well?

--
Paul Connolley
AccessPlanIT  LWDP Data Manager
Phone  01524 389541, Email  [EMAIL PROTECTED]
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Patrick H. Lauke
Geoff Deering wrote:
 That is my
point, not all these other arguments about where to or where not to use
transitional or strict.
However, that *was* the point of the original question. To recap: 
something can't be done in strict which is not presentational, but 
nevertheless has been dropped from the DTD. It can be done in 
transitional, but some shortsighted policy maker in the company decided 
that their guidelines should absolutely require strict. Which then 
prompted the (admittedly more general) question of whether or not strict 
has any accessibility advantages over transitional so as to warrant it 
being made mandatory in an accessibility policy.

I still stand by the idea that there is nothing intrinsically more 
accessible to strict over transitional - and in very rare cases such as 
this one, transitional *is* more accessible than strict.


--
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
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread James Bennett
On Wed, 9 Feb 2005 12:50:56 +1100, Geoff Deering [EMAIL PROTECTED] wrote:
 If you have a document that validates as doctype Strict, then why declare it
 as transitional?  For what reason are such decisions made?  That is my
 point, not all these other arguments about where to or where not to use
 transitional or strict.

I don't want to re-open the can of worms that is the XHTML MIME-type,
but I lean toward using Transitional on any XHTML that gets sent as
'text/html'.

-- 
May the forces of evil become confused on the way to your house.
  -- George Carlin
**
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: XHTML Strict alternative to ol start=11

2005-02-07 Thread Ian Fenn
Douglas wrote:
 Why not switch to XHTML Transitional for the page that you
 want to use the start= attribute on?

Thanks for that, Douglas. Unfortunately my client has accessibility
guidelines that insist the pages are built in XHTML Strict.

All the best,

--
Ian Fenn
Chopstix Media
http://www.chopstixmedia.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
**