Geoff;
But still, strictly speaking, an
XML based document is bound to be more semantically correct because it
is
well formed.
Why? Are the semantics of the following deferent?
ul
liIce cream/li
liSprinkles/li
/ul
...
ul
liIce cream
liSprinkles
/ul
SGML and XML
Dean;
Then there is the whole Web Applications trend. Again, HTML and
XHTML are pretty much the same in functionality here, but if I'm
using an application on the Web then I want to make sure it is
well-formed and well-structured. I don't want a typo by a web
developer (such as leaving off an end
Paul Connolley wrote:
Geoff Deering wrote:
I am talking about CSS applied to HTML and the rendering of the CSS as
applied to the parsing of the document. But still, strictly speaking,
an
XML based document is bound to be more semantically correct because it
is
well formed.
What Dean says so well here are also the reasons I prefer XML defined
markup, and I don't think it negates the arguments that others have been
expressing here for HTML. I think each on of them have valid points. But
it seems to me that there are more reasons to use an XML based vocabulary
than
Geoff Deering wrote:
I am talking about CSS applied to HTML and the rendering of the CSS as
applied to the parsing of the document. But still, strictly speaking,
an
XML based document is bound to be more semantically correct because it
is
well formed. This means that the CSS can be applied
Please forgive any ignorance on my part...
So I can copy the guts of an XHTML document in all it's splendor with
br /s et all and paste it into an HTML document and all is dandy?
Tom Livingston
Senior Multimedia Artist
mlinc.com
Get FireFox
Chris Bentley wrote:
Are there any parsers out there you explicitly trust to get it right
every
time? I don't.
I know of one, http://validator.w3.org/. Are you say though that User
Agents are generally better/fast at parsing/rendering valid XHTML than
they are valid HTML?
No, that is
.shtml
Regards,
-Vlad
http://xstandard.com
- Original Message -
From: Tom Livingston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 10:28 AM
Subject: Re: [WSG] Is XHTML harmful?
Please forgive any ignorance on my part...
So I can copy the guts of an XHTML
, 2004 10:53 AM
Subject: [WSG] Is XHTML harmful?
Hi,
First of all... I'm sorry if this is off topic.
I've been telling people (the few who asked me and through my website)
to use (valid) xhtml because it a W3C recommendation, it's device
independent, (valid) xhtml can be processed by an XML parser
Hi,
First of all... I'm sorry if this is off topic.
I've been telling people (the few who asked me and through my website)
to use (valid) xhtml because it a W3C recommendation, it's device
independent, (valid) xhtml can be processed by an XML parser, better
accessibility, less code, faster
Kim Kruse wrote:
Hi,
First of all... I'm sorry if this is off topic.
I've been telling people (the few who asked me and through my website)
to use (valid) xhtml because it a W3C recommendation, it's device
independent, (valid) xhtml can be processed by an XML parser, better
accessibility, less
can be
processed by XML parsers.
Regards,
-Vlad Alexander
XStandard Development Team
http://xstandard.com
- Original Message -
From: Kim Kruse [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 10:53 AM
Subject: [WSG] Is XHTML harmful?
Hi,
First of all... I'm
In message [EMAIL PROTECTED], Manuel González
Noriega [EMAIL PROTECTED] writes
XHTML problems:
- Zero-tolerance for markup errors
Surely that is a benefit rather than a problem?
--
Chris Hughes
http://www.epicure.demon.co.uk
**
The discussion
Chris Hughes wrote:
In message [EMAIL PROTECTED], Manuel González
Noriega [EMAIL PROTECTED] writes
XHTML problems:
- Zero-tolerance for markup errors
Surely that is a benefit rather than a problem?
Again, higly subjective: it's neat for marchine-parsing but IMHO it's
overkill to learn that
Again, higly subjective: it's neat for marchine-parsing but IMHO it's
overkill to learn that you've made a teenyweeny mistake in your blog
post markup by watching the bloody thing crash before your eyes
Yet with each crash and burn of your blog and each little mistake you
fix the more and more
Clayton Lengel-Zigich wrote:
Again, higly subjective: it's neat for marchine-parsing but IMHO it's
overkill to learn that you've made a teenyweeny mistake in your blog
post markup by watching the bloody thing crash before your eyes
Yet with each crash and burn of your blog and each little
All code of every web page should be validated. Any errors need to be
corrected. If your typo is in a tag, then it could produce undesirable
results.
We should all make sure our code on every web page we create has no
errors, whether simple typos or forgotten closing tags; whether we use
Manuel González Noriega wrote:
Often, markup errors, like natural language errors, are most likely
typos than anything else. Therefore, i don't really learn anything from
them
You learn that you should validate anything before making it live (just
like you'd spell-check and proofread anything
-Original Message-
Shane Helm - he say:
All code of every web page should be validated. Any errors need to be
corrected. If your typo is in a tag, then it could produce undesirable
results.
We should all make sure our code on every web page we create has no
errors, whether simple
Shane Helm wrote:
All code of every web page should be validated. Any errors need to be
corrected. If your typo is in a tag, then it could produce
undesirable results.
We should all make sure our code on every web page we create has no
errors, whether simple typos or forgotten closing tags;
Shane Helm wrote:
I have also become a better and
cleaner coder since I switched to XHTML CSS.
Table-less layout rules!
But, to clarify: there's nothing, absolutely nothing at all, stopping
you from going all CSS-driven, table-less, separation of content and
presentation, etc in HTML 4 - just
Patrick H. Lauke wrote:
Manuel González Noriega wrote:
Often, markup errors, like natural language errors, are most likely
typos than anything else. Therefore, i don't really learn anything
from them
You learn that you should validate anything before making it live
(just like you'd spell-check
Can anyone explain what this means in that article?
* A CSS stylesheet written for an HTML4 document is interpreted
slightly differently in an XHTML context (e.g. the body element
is not magical in XHTML
In what ways might body be magical?
One that I know, but there may be more: in HTML, body is the size of the
entire viewport, even if it's empty. In XHTML, it's just like any other
block level elements and takes on the dimensions of its content (and if
you float everything in the body, it effectively is 0 pixels high). If
you
there were a couple of threads about this issue at WEB4LIB recently.
subject = Moving from HTML4.01 to XML
subject = to X or not to X
the consensus was generally mixed, as it is here. one of my gurus bow said:
paste
Moving from any flavor of HTML to the corresponding flavor of XHTML is a
pretty
Every modern browser, including Mozilla and Safari, is much worse at
XHTML than at HTML. People tend to foolishly gloss over the transition
from one to the other, thinking that code you write for one will just
work when you switch to XHTML. That simply isnt true. If you look at
XHTML in both
Hmmm...
but it was also pointed out
paste
Note that a strict interpretation of the WAI WCAG 1.0 guidelines would
indicate that you MUST use XHTML 1.0 if you intent to comply
with WAI AA
guidelines. See http://www.w3.org/TR/WAI-WEBCONTENT/
Um, no. Not MUST at all. This is
Kim wrote:
Now I would like to
know what your arguments would be for using xhtml.Hi
everyone,have heard and understand all the good responses on this question.
As usual the decision can vary depending on your needs.I'd like to offer
one reason why it has been a good decision for us here at
... as for appropriate, that's a judgement call
based on personal preference.
mm..
he also did add:
Note that I personally think it is unfortunate that the WAI WCAG guidelines
mandate this.
(I appreciate that the word 'appropriate' could be interpreted as a get-out
- but I would argue that XHTML
I think there are valid arguments for both sides of this.
This is also where I agree with the approach of the Apache/Cocoon advocates
in that you serve up the solution which be suits the user agent.
As standards developers we are working in an imperfect world and it's what
frustrates us all.
On 07/10/2004, at 9:45 AM, Peter Firminger wrote:
(and it's debateable whether HTML 3.2 is either... By version
do they mean the language or the subset? HTML 3.2 is the latest
version of
HTML 3)
I suspect that they mean HTML4.
From the HTML 4 rec
W3C recommends that authors produce HTML 4
On 07/10/2004, at 10:07 AM, Geoff Deering wrote:
The reason being that if you are not closing all your tags it
can become a guessing game for the parser where the CSS declaration
may end
in various parts of the document.
It always strikes me that when using HTML4 you are at the mercy of the
Manuel González Noriega wrote:
You learn that you should validate anything before making it live
(just like you'd spell-check and proofread anything before going to
publication in the print world, for instance). ;)
Hmmm... I started writing a reply a few hours ago and events overtook
me. Still,
On 07/10/2004, at 10:07 AM, Geoff Deering wrote:
The reason being that if you are not closing all your tags it
can become a guessing game for the parser where the CSS declaration
may end
in various parts of the document.
It always strikes me that when using HTML4 you are at the mercy
Title: RE: [WSG] Is XHTML harmful?
Lachlan wrote:
On use of validation: valid code is not difficult.
Pete, I'm assuming from your comments that you aim for valid code by
changing institutional practices rather than programmatically?
Agreed on both.
The reality in big
Are there any parsers out there you explicitly trust to get it right
every
time? I don't.
I know of one, http://validator.w3.org/. Are you say though that User
Agents are generally better/fast at parsing/rendering valid XHTML than
they are valid HTML?
They may well do, but they are still
36 matches
Mail list logo