HomePageReader reading out of order
King Queen
I'm trying to write an ultra-accessible website as it is going to be
used by a lot of disabled people.
The basic prototype is at
http://www.kingqueen.org.uk/lip/template.html
It's kind of getting there but the problem is that IBM HomePage Reader
reads lines out of order.
For example, with this code:
<div class="internal">
Go to: <a href="" title="Section 1">Section 1</a> |
<a href="" title="section 2">Section 2</a> | <a href=
"" title="section 3">Section 3</a>
</div>
<p>Content goes here</p>
<h3>Subheadings for long pages</h3>
It reads this:
Go to:
Content goes here
Subheadings for long pagesSection 1 | Section 2 | Section 3
Why's it reading "Section 1" etc. way after it should? Anybody know
what I can do about it?
Thanks in advance
--
To email me remove ".lartsspammers"
http://www.kingqueen.org.uk
jake
<kq.larts...@kingqueen.org.uk> writes
caused by incorrectly nested tags.
However, I can't see the problem in this case, and your page validates
OK.
You might want to post this problem on the IBM HPR Listserver for an
answer. If you're not a subscriber (and don't want to be) let me know
and I'll post the query for you.
regards.
--
Jake
King Queen
wrote:
>I've only seen this 2 or 3 times in the past, and in all cases it was
>caused by incorrectly nested tags.
>
>However, I can't see the problem in this case, and your page validates
>OK.
>
>You might want to post this problem on the IBM HPR Listserver for an
>answer. If you're not a subscriber (and don't want to be) let me know
>and I'll post the query for you.
Hi Jake
Thanks for that, very much appreciated. I shall join the list server
and ask.
I've never had so many problems with cross browser compatibility as I
am having with this blasted website. I don't know why as it is all
validated XHTML Strict and CSS, all hand coded as well!
Thanks
Doug
Nick Kew
King Queen <kq.larts...@kingqueen.org.uk> writes:
> Hi
>
> I'm trying to write an ultra-accessible website as it is going to be
> used by a lot of disabled people.
>
> The basic prototype is at
> http://www.kingqueen.org.uk/lip/template.html
>
> It's kind of getting there but the problem is that IBM HomePage Reader
> reads lines out of order.
>
> For example, with this code:
>
> <div class="internal">
> Go to: <a href="" title="Section 1">Section 1</a> |
> <a href="" title="section 2">Section 2</a> | <a href=
> "" title="section 3">Section 3</a>
> </div>
> <p>Content goes here</p>
> <h3>Subheadings for long pages</h3>
>
> It reads this:
>
> Go to:
> Content goes here
> Subheadings for long pagesSection 1 | Section 2 | Section 3
>
> Why's it reading "Section 1" etc. way after it should? Anybody know
> what I can do about it?
Don't know. Perhaps style rules on your class="internal"? Or perhaps
some problem in your markup not shown in the sample. What happens if
you mark it up as a list?
Oh, and I'm sure your title attributes are superfluous. But perhaps
they were merely illustrative?
--
Nick Kew
King Queen
wrote:
>Don't know. Perhaps style rules on your class="internal"? Or perhaps
>some problem in your markup not shown in the sample.
div.internal{
font-size: 80%;
font-weight: bold;
padding-bottom: 0px;}
It all validates as XHTML 1.0 Strict, the CSS also validates.
>What happens if
>you mark it up as a list?
It says it perfectly.
>Oh, and I'm sure your title attributes are superfluous. But perhaps
>they were merely illustrative?
Yes, it is only a template file so far, it yet has to have any
significant content put in.
Thanks
Doug
King Queen
wrote:
>You might want to post this problem on the IBM HPR Listserver for an
>answer. If you're not a subscriber (and don't want to be) let me know
>and I'll post the query for you.
Hi Jake
That would be very much appreciated if you wouldn't mind. I have tried
to subscribe to the list but my requests appear to have been swallowed
in cyberspace without a burp - and the links from HPR's help system to
the list are out of date, return 404s.
I think it is amazing that HomePage Reader doesn't pronounce homepage
in the expected manner - it does a Hom Eh Page!
Alan J. Flavell
> I think it is amazing that HomePage Reader doesn't pronounce homepage
> in the expected manner - it does a Hom Eh Page!
The pronunciation is in the hands of the underlying speaking
libraries, not HPR itself.
Pronunciation can be configured. There's a wide range of options,
although the user interface to them was IMHO clumsy - even for a
sighted person - I don't know how much luck a blind user would have
with that.
But anyway, you can change the pronunciation for whole words, or
explain to it how to pronounce acronyms, or to spell-out initials that
it's mistakenly trying to pronounce. Even change the way it indicates
different punctuation characters.
jake
<kq.larts...@kingqueen.org.uk> writes
>On Wed, 24 Mar 2004 16:46:04 +0000, jake <ja...@gododdin.demon.co.uk>
>wrote:
>
>>You might want to post this problem on the IBM HPR Listserver for an
>>answer. If you're not a subscriber (and don't want to be) let me know
>>and I'll post the query for you.
>
>Hi Jake
>
>That would be very much appreciated if you wouldn't mind. I have tried
>to subscribe to the list but my requests appear to have been swallowed
>in cyberspace without a burp - and the links from HPR's help system to
>the list are out of date, return 404s.
OK, I've posted your query and it's now on the server; I'll let you know
what results from it.
>
>I think it is amazing that HomePage Reader doesn't pronounce homepage
>in the expected manner - it does a Hom Eh Page!
>
Not really. There's no such word as 'homepage', so it has to take a
guess as to how it's pronounced. Same with 'sitemap'.
regards.
--
Jake
jake
Alan J. Flavell <fla...@ph.gla.ac.uk> writes
So:
homepage --> `[h1om] `[peJ]
-- not too difficult to add 'homepage' to the (British) dictionary once
you understand the pronunciation table ;-)
--
Jake
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>On Wed, 24 Mar 2004 13:46:23 +0000, ni...@hugin.webthing.com (Nick Kew)
>wrote:
>
>>Don't know. Perhaps style rules on your class="internal"? Or perhaps
>>some problem in your markup not shown in the sample.
>
>div.internal{
> font-size: 80%;
> font-weight: bold;
> padding-bottom: 0px;}
>
>It all validates as XHTML 1.0 Strict, the CSS also validates.
Home Page Reader sits on top of IE - IE does not support XHTML 1.0 as
anything other than tag-soup, so if you're going to give it tag-soup,
don't be surprised if it doesn't do what you might expect.
Jim.
King Queen
>Home Page Reader sits on top of IE - IE does not support XHTML 1.0 as
>anything other than tag-soup, so if you're going to give it tag-soup,
>don't be surprised if it doesn't do what you might expect.
So it is more likely to work as HTML 4.01 then?
King Queen
<kq.larts...@kingqueen.org.uk> wrote:
>So it is more likely to work as HTML 4.01 then?
You were right: I have done a mechanical translation back to HTML 4.01
Strict at http://www.kingqueen.org.uk/lip2/template.html and HomePage
Reader renders it exactly as expected, no bugs or anything.
I'll leave the version at
http://www.kingqueen.org.uk/lip/template.html up for the HPR e-list
readership to have a look at though.
I'll go back to the clients and tell them that they can't have XHTML
1.0 and accessibility and persuade them to go back to HTML 4.01
Strict.
Thanks
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>I'll go back to the clients and tell them that they can't have XHTML
>1.0 and accessibility and persuade them to go back to HTML 4.01
>Strict.
Well in an act of unusual generosity to the XHTML world, and with
thanks to Bjoern Hoerhmann, the problem is simply
<a name="main" id="main" />
and C.3. of XHTML 1.0, is clear on the point:
| Element Minimization and Empty Element Content
| Given an empty instance of an element whose content model is not
| EMPTY (for example, an empty title or paragraph) do not use the
| minimized form (e.g. use <p> </p> and not <p />).
Jim.
King Queen
>| Element Minimization and Empty Element Content
>| Given an empty instance of an element whose content model is not
>| EMPTY (for example, an empty title or paragraph) do not use the
>| minimized form (e.g. use <p> </p> and not <p />).
I can't do right for doing wrong.
Bobby objects to that in some instances - it prefers <a
name="whatever" id="whatever" /> to <a name=...></a>.
Barry Pearson
[snip]
> Well in an act of unusual generosity to the XHTML world, and with
> thanks to Bjoern Hoerhmann, the problem is simply
>
> <a name="main" id="main" />
>
> and C.3. of XHTML 1.0, is clear on the point:
>
>| Element Minimization and Empty Element Content
>| Given an empty instance of an element whose content model is not
>| EMPTY (for example, an empty title or paragraph) do not use the
>| minimized form (e.g. use <p> </p> and not <p />).
Ditto
<script ....... />
of course!
The whole of the rest of the document appears to be script, to any browser
looking for </script>. (That caused lots of trouble for someone I was
communicating with).
XHTML that validates can simply fail to render in browsers that are quite
capable of rendering the equivalent HTML recommendation. And, I understand,
XHTML validation is incapable of spotting certain problems that would be
picked up by HTML validation, such as certain invalid nesting of elements.
If you don't specifically need XHTML, is there any advantage whatsoever in
using XHTML?
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
>Ditto
><script ....... />
>of course!
>The whole of the rest of the document appears to be script, to any browser
>looking for </script>. (That caused lots of trouble for someone I was
>communicating with).
>
>XHTML that validates can simply fail to render in browsers that are quite
>capable of rendering the equivalent HTML recommendation. And, I understand,
>XHTML validation is incapable of spotting certain problems that would be
>picked up by HTML validation, such as certain invalid nesting of elements.
>
>If you don't specifically need XHTML, is there any advantage whatsoever in
>using XHTML?
Well, I don't think it is as open and shut as you make out. I know the
general consensus on this conference is that it is really pretty
pointless or even verging on counter-productive, but the opinion
amongst other arms of the web design community which I also respect
(especially the Open University's web design community) think that in
some respects it is the way forward.
There's also the fact that the LIP Management who I'm writing the page
for have requested I should write in XHTML. Also things like the Web
Accessibility Initiative recommend using the latest technology
specification applicable.
Last but not least (unfortunately) it is perceived amongst many that
XHTML is in some way better and more skillful to write than HTML and
as such web designers who write to it are perhaps more respected by
those who don't know the subject well. I am ashamed to say I like the
kudos!
I'm torn. I can see that XHTML - as a purely mechanical rehashing of a
page, for a start - has little or no technical benefit over HTML 4.01
Strict, on the other hand my clients have requested it and this
absolutely must be a completely accessible site - and the WAI
recommends XHTML.
The good thing is I don't have to make a decision right now as HTML
Tidy is very good at painlessly converting lots of pages from one to
the other in the blink of an eye.
Barry Pearson
> On Fri, 26 Mar 2004 22:06:36 -0000, "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>>If you don't specifically need XHTML, is there any advantage
>>whatsoever in using XHTML?
>
> Well, I don't think it is as open and shut as you make out. I know the
> general consensus on this conference is that it is really pretty
> pointless or even verging on counter-productive, but the opinion
> amongst other arms of the web design community which I also respect
> (especially the Open University's web design community) think that in
> some respects it is the way forward.
A problem is - what do they mean by XHTML? Perhaps XHTML 2.0 *is* the way
forward. But that is a long way off. What we have at the moment is XHTML 1.0
(Transitional & Strict), and 1.1. Are they the future? If so, why? What
credentials do those people have that would make them credible?
I have seen no reason to believe that XHTML 1.0 Strict or 1.1 are steps I will
ever take. (My current target is 4.01 Strict). All my instincts tell me they
are a ghastly blunder and the world would be a better place if they had never
been proposed. Perhaps rational arguments will convince me I am wrong. I'm
waiting ....
> There's also the fact that the LIP Management who I'm writing the page
> for have requested I should write in XHTML. Also things like the Web
> Accessibility Initiative recommend using the latest technology
> specification applicable.
Is there any known accessibility advantage from using XHTML compared with the
equivalent HTML? Has it been evaluated, or is it wishful thinking? (Like
moving to Windows ME from Windows 98!)
Would WAI recommend full use of CSS2 just because it is the latest? Some of it
isn't supported by most browsers in the world!
> Last but not least (unfortunately) it is perceived amongst many that
> XHTML is in some way better and more skillful to write than HTML and
> as such web designers who write to it are perhaps more respected by
> those who don't know the subject well. I am ashamed to say I like the
> kudos!
I am not trying to win mark-up prizes! But since I use Dreamweaver, this is
hardly a challenge. I already get full closing tags & lower case tags, and DW
will happily turn out XHTML if I want it to. I am not aware of any extra skill
that I would need to turn out XHTML. (Except to know of all the traps that
would stop my valid XHTML documents failing to be rendered in the vast
majority of the world's browsers!)
> I'm torn. I can see that XHTML - as a purely mechanical rehashing of a
> page, for a start - has little or no technical benefit over HTML 4.01
> Strict, on the other hand my clients have requested it and this
> absolutely must be a completely accessible site - and the WAI
> recommends XHTML.
I would love to see a proper evaluation of the latter.
> The good thing is I don't have to make a decision right now as HTML
> Tidy is very good at painlessly converting lots of pages from one to
> the other in the blink of an eye.
Indeed. I am confident that, by writing 4.01 Strict, with full closing tags &
lower case tags, etc, I will be able to transform my pages to XHTML, using
free software, if ever I need to. So why bother until I need to?
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
>A problem is - what do they mean by XHTML? Perhaps XHTML 2.0 *is* the way
>forward. But that is a long way off. What we have at the moment is XHTML 1.0
>(Transitional & Strict), and 1.1. Are they the future? If so, why? What
>credentials do those people have that would make them credible?
If you look I didn't say that they were more credible. But I do
respect their opinion - they have a definite commitment to accessible
and sensible web design.
>Perhaps rational arguments will convince me I am wrong. I'm
>waiting ....
You won't get rational arguments from me as I don't know enough about
it :-)
>Is there any known accessibility advantage from using XHTML compared with the
>equivalent HTML? Has it been evaluated, or is it wishful thinking? (Like
>moving to Windows ME from Windows 98!)
I always suggest that people who have Windows ME downgrade to Windows
98 if their computer can't cope with 2000 or XP, it was one of
Microsoft's more blatant money-making for old rope I think.
>Would WAI recommend full use of CSS2 just because it is the latest? Some of it
>isn't supported by most browsers in the world!
Well this as usual is open to interpretation.
The actual bit of text is:
"Use W3C technologies when they are available and appropriate for a
task and use the latest versions when supported. [Priority 2]"
So probably the "where supported" means don't code with CSS2.
Bobby, who aren't the be-all and end-all of accessibility I know, say:
"Use HTML 4.0 instead of earlier versions of HTML. Especially, avoid
the use of elements that were removed from the specification or were
never part of the formal specification. Likewise, use CSS Level 2
instead of Level 1. Whenever possible, render content using HTML, not
a different format that may require a plugin and may not have
accessibility features. Using newer technologies does not create
compatibility problems with older browsers."
So XHTML is out, but CSS 2.0 is apparently OK.
I like this though:
"Using newer technologies does not create compatibility problems with
older browsers."
That's clearly rubbish given the problems XHTML has given me with my
latest website.
You pays your money and you takes your pick...
>I am not trying to win mark-up prizes!
Ah, there you go you see, you're obviously not as shallow as me :-)
>I am not aware of any extra skill
>that I would need to turn out XHTML.
There isn't any, though I think the perception of others not aware of
this fact is that there is. And there lies the difference!
>Indeed. I am confident that, by writing 4.01 Strict, with full closing tags &
>lower case tags, etc, I will be able to transform my pages to XHTML, using
>free software, if ever I need to. So why bother until I need to?
I didn't suggest you should.
Alan J. Flavell
> Bobby objects to that in some instances - it prefers <a
> name="whatever" id="whatever" /> to <a name=...></a>.
Bobby is not without bugs. If your design requirements call for WAI
conformance, check what the WAI recommendations say, not what Bobby
says. Bobby has been known to reject a precise instance of good
practice shown in the WAI recommendations! The WAI was right and
Bobby was wrong.
In short, Bobby is a useful checker, but it is not a final arbiter of
correctness or appropriateness.
If, on the other hand, your design requirements call for nothing more
than a clean report from Bobby, then the design requirements are
defective.
However, it's possible that in this specific instance, it's just
asking you to put some non-null content inside the "a" element.
Those of use who grew up with the WWW learned to do that anyway, due
to bugs in antique browsers. Probably no longer necessary, but does
no harm (as long as you code any stylesheet appropriately, i.e
distinguishing between those "a" elements which are links and those
which are not).
Alan J. Flavell
> I always suggest that people who have Windows ME downgrade to Windows
> 98 if their computer can't cope with 2000 or XP, it was one of
> Microsoft's more blatant money-making for old rope I think.
9x-derived systems are fundamentally unsafe, at least when engaged in
Internet activities.
Either upgrade to Linux or, if you really have to run Win-compatible
applications, bite the bullet and run some Win-NT derived version,
such as Win2K (i.e NT5). Of course: except when applying service or
installing new software, you should be running as an unprivileged
user, for your own safety. That goes for Linux as much as for
Win/NTx.
Any system which does not distinguish between administrator privs and
normal user privs isn't really safe to connect to the Internet. AIUI
that also goes for "XP Home" (as opposed to Pro).
> The actual bit of text is:
>
> "Use W3C technologies when they are available and appropriate for a
> task and use the latest versions when supported. [Priority 2]"
I read that as HTML4.01, frankly.
> So probably the "where supported" means don't code with CSS2.
CSS is designed to be harmless on those client agents which don't
support it. If you use it appropriately, I mean.
The killer is those client agents that make a guess (in violation of
the specifications) at what some unrecognised CSS might mean - and get
it wrong. If they don't understand something, they -ought- to ignore
it. It's part of the design philosophy of CSS.
Barry Pearson
> On Fri, 26 Mar 2004 23:19:52 -0000, "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>>Perhaps rational arguments will convince me I am wrong. I'm
>>waiting ....
>
> You won't get rational arguments from me as I don't know enough about
> it :-)
I have the feeling we are both followers of different fashions, here!
I'm expecting that if/when it is time to move on, I'll see the signs. (For
example, I notice that flared trousers and kipper ties are less common, so
perhaps I need to move on there too).
King Queen
<fla...@ph.gla.ac.uk> wrote:
>In short, Bobby is a useful checker, but it is not a final arbiter of
>correctness or appropriateness.
Oh yes I agree there.
>If, on the other hand, your design requirements call for nothing more
>than a clean report from Bobby, then the design requirements are
>defective.
No - I won't settle for anything less than the most accessible I can
possibly make it, as you say that doesn't just mean hoop jumping for
Bobby's sake.
>
>However, it's possible that in this specific instance, it's just
>asking you to put some non-null content inside the "a" element.
>Those of use who grew up with the WWW learned to do that anyway, due
>to bugs in antique browsers. Probably no longer necessary, but does
>no harm (as long as you code any stylesheet appropriately, i.e
>distinguishing between those "a" elements which are links and those
>which are not).
Thanks
Doug
King Queen
<fla...@ph.gla.ac.uk> wrote:
>9x-derived systems are fundamentally unsafe, at least when engaged in
>Internet activities.
>
>Either upgrade to Linux or, if you really have to run Win-compatible
>applications, bite the bullet and run some Win-NT derived version,
>such as Win2K (i.e NT5). Of course: except when applying service or
>installing new software, you should be running as an unprivileged
>user, for your own safety. That goes for Linux as much as for
>Win/NTx.
Well yes, thing is - for example on my Dad's computer which I have
been repairing this week - older computers don't cope with Windows
2000. Well it does, but incredibly slowly. And he's not up for Linux -
he's not that proficient on computers but just about gets by in
Windows, which he's been trained on (CLAIT strikes again). So Windows
98 it is.
>The killer is those client agents that make a guess (in violation of
>the specifications) at what some unrecognised CSS might mean - and get
>it wrong. If they don't understand something, they -ought- to ignore
>it. It's part of the design philosophy of CSS.
Indeed, it's a shame that all our browsers are so broken.
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
>I have the feeling we are both followers of different fashions, here!
>
>I'm expecting that if/when it is time to move on, I'll see the signs. (For
>example, I notice that flared trousers and kipper ties are less common, so
>perhaps I need to move on there too).
I know the feeling :-)
Nick Kew
"Barry Pearson" <ne...@childsupportanalysis.co.uk> writes:
> (quoting KQ)
>> Well, I don't think it is as open and shut as you make out. I know the
>> general consensus on this conference is that it is really pretty
>> pointless or even verging on counter-productive, but the opinion
>> amongst other arms of the web design community which I also respect
>> (especially the Open University's web design community) think that in
>> some respects it is the way forward.
I couldn't possibly comment on the OU's views without more background,
like the arguments they use, and the caveats they attach.
> A problem is - what do they mean by XHTML? Perhaps XHTML 2.0 *is* the way
> forward. But that is a long way off.
That'll depend on browser support. With M$ turned inactive, it'll be a
case of whether the active browser developers (Moz; Konq/Safari; Opera)
see value in it.
> What we have at the moment is XHTML 1.0
> (Transitional & Strict),
Yep.
> and 1.1.
Har har. The one that gratuitously breaks back-compatibility without
offering anything in return.
> I have seen no reason to believe that XHTML 1.0 Strict or 1.1 are steps I will
> ever take. (My current target is 4.01 Strict).
A very sensible choice. But best taken with a validator that deals with
at least the SHORTTAGS bug in the HTML spec.
> Perhaps rational arguments will convince me I am wrong. I'm
> waiting ....
There are rational arguments. It fixes the SHORTTAGS bug (but introduces
other gotchas, as noted in this thread). And it exposes markup to a
wider range of processing tools.
>> There's also the fact that the LIP Management who I'm writing the page
>> for have requested I should write in XHTML.
That's not so bad. You could actually fix the problems with <a/> and
<script/> automatically - e.g. using the XHTML1.0 Namespace processor
module with Apache to ensure what the browser sees follows Appendix-C.
> Also things like the Web
>> Accessibility Initiative recommend using the latest technology
>> specification applicable.
And the ... erm ... key word applicable word in the above might be?
> Is there any known accessibility advantage from using XHTML compared with the
> equivalent HTML?
It disallows abbreviated forms that browsers can't deal with. Oh, and
then there's the comment syntax - again not many browsers get HTML
right if it (perfectly legally) departs from XML syntax).
> Would WAI recommend full use of CSS2 just because it is the latest? Some of it
> isn't supported by most browsers in the world!
Not an issue. Read WCAG again: thou shalt not _rely on_ any flavour
of CSS for accessibility.
>> Last but not least (unfortunately) it is perceived amongst many that
>> XHTML is in some way better and more skillful to write than HTML and
Anyone who believes that is showing their ignorance.
> I would love to see a proper evaluation of the latter.
I think from an accessibility POV we've done the differences in this thread.
>> The good thing is I don't have to make a decision right now as HTML
>> Tidy is very good at painlessly converting lots of pages from one to
>> the other in the blink of an eye.
But tidy also has some very stupid habits - like taking strict and
calling it transitional. Not that that's hard to fix, either.
> Indeed. I am confident that, by writing 4.01 Strict, with full closing tags &
> lower case tags, etc, I will be able to transform my pages to XHTML, using
> free software, if ever I need to. So why bother until I need to?
Zigackly.
--
Nick Kew
Barry Pearson
> In article <4X29c.46$F9...@newsfe3-win.server.ntli.net>,
> "Barry Pearson" <ne...@childsupportanalysis.co.uk> writes:
>> I have seen no reason to believe that XHTML 1.0 Strict or 1.1 are
>> steps I will ever take. (My current target is 4.01 Strict).
>
> A very sensible choice. But best taken with a validator that deals
> with at least the SHORTTAGS bug in the HTML spec.
> There are rational arguments. It fixes the SHORTTAGS bug (but
> introduces other gotchas, as noted in this thread). And it exposes
> markup to a wider range of processing tools.
What is the SHORTTAGS bug?
I couldn't deduce it from a quick Google. People just appeared to be
discussing it as though everyone knew what it was!
Nick Kew
"Barry Pearson" <ne...@childsupportanalysis.co.uk> writes:
> What is the SHORTTAGS bug?
>
> I couldn't deduce it from a quick Google. People just appeared to be
> discussing it as though everyone knew what it was!
http://valet.webthing.com/page/parsemode.html
which also explains what I recommend doing about it.
--
Nick Kew
Jim Ley
wrote:
>> A problem is - what do they mean by XHTML? Perhaps XHTML 2.0 *is* the way
>> forward. But that is a long way off.
>
>That'll depend on browser support. With M$ turned inactive, it'll be a
>case of whether the active browser developers (Moz; Konq/Safari; Opera)
>see value in it.
Hmm, and do we see much from them? XBL is getting nicely resurrected
it seems, with that we get arbitrary XML rendered into useful things,
so this makes much more sense than just XHTML which is limited to very
few semantics.
>> and 1.1.
>
>Har har. The one that gratuitously breaks back-compatibility without
>offering anything in return.
Well, there's Ruby...
>That's not so bad. You could actually fix the problems with <a/> and
><script/> automatically - e.g. using the XHTML1.0 Namespace processor
>module with Apache to ensure what the browser sees follows Appendix-C.
You've done that? (I can't imagine many other people would) There is
an Appendix C validator? how do you deal with the contradiction, or
do you require no StyleSheets at all as the only possible way fo
fulfilling it?
>>> Last but not least (unfortunately) it is perceived amongst many that
>>> XHTML is in some way better and more skillful to write than HTML and
>
>Anyone who believes that is showing their ignorance.
Indeed, and I've certainly found it only takes a couple of minutes
explaining HTML/XHTML differences for people to change their
requirements.
Jim.
Barry Pearson
Truly bizarre! I just put the HTML from that page into Dreamweaver. It said
(perhaps incorrectly?) that the title & p tags were "malformed HTML 4".
IE & Opera 7.23 displayed everything starting at <title. Firefox 0.8 &
Netscape 7.1 not only didn't display anything, when I tried to view their
source there was no text in it.
I don't think I need to worry about this, because Dreamweaver won't generate
such code, valid or not. (I run it configured to "fix invalidly nested and
unclosed tags").
Alan J. Flavell
I'm ony a dabbler in SGML, so this is more in the nature of a question
than a statement.
Hope you don't mind, but I thought it a bit more-relevant to move
this rather technical-detail discussion to c.i.w.a.h (x-posted and
f'ups set).
As I understood it, the original SGML "SHORTTAGS" bundled a number
of different shorthands, some of which were wanted in HTML and some
of which were not. "N.E.T-enabling" shorttags, which is what this is
about, weren't really wanted.
The SGML Web "technical corrigendum" (is that the right term?)
unbundled these several features, so that they can be separately
enabled and disabled.
IINM, then, it would now be technically feasible to write an updated
SGML declaration for HTML, which retained the desired features while
excluding the unwanted ones. Thus getting these particular benefits
of XHTML without the client-agent incompatibilities.
Google found a number of vaguely relevant discussions, but this seemed
to be the most pertinent one that I located:
http://lists.w3.org/Archives/Public/www-html/2002Nov/0055.html
in which I see that you were involved.
Sure, the W3C wouldn't be interested in this, because they've put
their bets on XML. But it might be interesting as a more-compatible
approach than the notorious "Appendix C", until XML-based markups are
well enough supported to do anything genuinely constructive relative
to HTML4.*.
Does that make any sense? Have any of the ideas from that 2002
discussion actually been developed?
Btw, are the terms "Web TC" and "Annexe K" synonymous? Or is one just
a part of the other?
Alan J. Flavell
> Well yes, thing is - for example on my Dad's computer which I have
> been repairing this week - older computers don't cope with Windows
> 2000. Well it does, but incredibly slowly.
Of course I don't know just what age of machine you have in mind here,
but unless it's geriatric, a memory upgrade might be worth
considering.
On the other hand if it's too old to use the currently-available chip
architectures, then memory upgrades get progressively more expensive
(if obtainable at all), to the point where you/he would just be
"throwing good money after bad".
("Crucial" have a very useful web selection page for memory chips,
once you've managed to find out what motherboard you're dealing with
http://www.crucial.com/uk/index.asp ).
> And he's not up for Linux - he's not that proficient on computers
> but just about gets by in Windows, which he's been trained on (CLAIT
> strikes again). So Windows 98 it is.
I understand what you're saying; but it doesn't change the fact that
such systems are insecure, representing a potential threat to
themselves and to others. The fact that the user lacks the expertise
to handle them well does not make things any better, in fact it puts
them even more at risk.
(Thought about a motherboard transplant ?)
cheers
Nick Kew
j...@jibbering.com (Jim Ley) writes:
>>That's not so bad. You could actually fix the problems with <a/> and
>><script/> automatically - e.g. using the XHTML1.0 Namespace processor
>>module with Apache to ensure what the browser sees follows Appendix-C.
>
> You've done that? (I can't imagine many other people would) There is
> an Appendix C validator? how do you deal with the contradiction, or
> do you require no StyleSheets at all as the only possible way fo
> fulfilling it?
Not an Appendix C validator, no. A SAX-based filter for the XHTML1.0
namespace that rewrites markup where necessary to ensure Appendix C
compatibility.
It's actually a simplest-case ("HelloWorld") demonstrator for mod_xmlns,
which is itself essentially a demo-of-concept for XML Namespace
handling in Apache. See http://apache.webthing.com/mod_xmlns/ .
--
Nick Kew
Nick Kew
"Alan J. Flavell" <fla...@ph.gla.ac.uk> writes:
> Hope you don't mind, but I thought it a bit more-relevant to move
> this rather technical-detail discussion to c.i.w.a.h (x-posted and
> f'ups set).
x-post honoured; followup reset.
> As I understood it, the original SGML "SHORTTAGS" bundled a number
> of different shorthands, some of which were wanted in HTML and some
> of which were not.
That's my understanding too, though I too am open to correction.
> The SGML Web "technical corrigendum" (is that the right term?)
> unbundled these several features, so that they can be separately
> enabled and disabled.
Indeed. That is certainly true now.
> IINM, then, it would now be technically feasible to write an updated
> SGML declaration for HTML, which retained the desired features while
> excluding the unwanted ones. Thus getting these particular benefits
> of XHTML without the client-agent incompatibilities.
Yes - we've done that within the www-validator team (as shown in Terje's
post you mention below). But of course we can't go "live" with that
without the blessing of the HTML WG.
The Parse Mode solution works by implementing the extra rigour in software
without touching the SGML declaration. So what Valet describes as HTML mode
or Web mode does the job, while strict SGML mode slavishly follows the HTML
spec including the SHORTTAGS bug.
> Does that make any sense? Have any of the ideas from that 2002
> discussion actually been developed?
Nothing has changed. Valet and htmlhelp continue to present users a
choice and a recommendation. W3C continues (when people find the time)
to debate whether and how to do something similar, and seems in some
danger of offering SGML and Fussy modes while missing out the
intermediate mode recommended by the other validators.
--
Nick Kew
Jukka K. Korpela
>> As I understood it, the original SGML "SHORTTAGS" bundled a number
>> of different shorthands, some of which were wanted in HTML and some
>> of which were not.
>
> That's my understanding too, though I too am open to correction.
The tutorial annex C in The SGML Handbook explains what SHORTTAG YES
means: it allows - with certain conditions of course - unclosed start
tags, empty tags (not empty elements but tags without a "tag name", e.g.
</>), omission of delimiters (quotes) from attribute values, omission of
attributes (defaulting them), and omission of attribute names.
HTML, as originally defined, made use of many of these features.
It seems that the only one left in XHTML is omission of attributes,
and it has of course been formally defined by the XML specification,
which is logically independent of SGML, so SHORTTAG considerations are
irrelevant.
From the beginning of HTML up to its XMLization (which is mostly just a
game or a hobby at present), HTML has been formally defined by rules that
permit quite some syntactic variation that is not actually supported by
browsers. This is a bit tragicomic, since there was never a serious
attempt to enforce that syntax - it was just a by-product of nominal
SGMLization of a markup system with several eclectic features.
Validators are, for almost all purposes, the only programs that care
about those syntax rules. This is one reason why validation has been
overrated; another reason is that validation covers just part of
correctness (despite being constantly sold as something else).
>> IINM, then, it would now be technically feasible to write an updated
>> SGML declaration for HTML, which retained the desired features while
>> excluding the unwanted ones. Thus getting these particular benefits
>> of XHTML without the client-agent incompatibilities.
>
> Yes - we've done that within the www-validator team (as shown in
> Terje's post you mention below).
There's little point in such an exercise. It won't change the browsers,
it won't change the specifications, and it will confuse people (who are
already confused with all this XHMTL stuff).
What authors might need is a practical HTML syntax analyzer that does
_not_ postulate any SGML (or XML) and especially does not talk SGMLese or
XMLese in its messages but tries to report potential problems in markup.
But I'm afraid we should have done that years ago, it's too late now -
especially when various _faulty_ analyzers have spoiled the reputation of
such an idea.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Matthew Somerville
> Any system which does not distinguish between administrator privs and
> normal user privs isn't really safe to connect to the Internet. AIUI
> that also goes for "XP Home" (as opposed to Pro).
No, XP (both Home and Pro) does have proper user / administrator separation
(though Pro gives you far more control over access control); a pity many
Windows programs still can't cope with this...
ATB,
Matthew