Why XHTML?
Root
charsets. There is now a dialogue concerning default mark up. Drawing
these strands together, it might now be timely to raise a far more
substantial issue. Why are we using xhtml at all? I do not yet know
whether this is a knee jerk kind of thing or whether the proposed or
continuing use of xhtml represents a considered view as to the best
way forwards on behalf of the extant commiter group. In my opinion it
is a mistake. Put simply the issue is to do with error handling. By
default a malformed xml document will not render AT ALL.
That is clearly unsatisfactory for most bloggers. The quick solution
(kluge) is to hack the browser by serving up the wrong mime type. This
also accomodates IE. By serving up a bogus mime type however we
promptly loose all the advantages of xml and acquire a huge number of
very unwelcome side effects. On some legacy platforms some people have
been trying to point this out for two years and getting very little
response. And now the chickens are coming home to roost and it is
causing the predictable chaos. I hope - fervently - that we do not go
down that route.
So what does any one think?
Firas Durri
type is overblown. I think serving html 4.01 would cause more
consternation than whatever chickens are coming home (which ones?)
Personally I'd rather not relearn the few syntax differences that html
4.01 had from what I've been working with for five years (self-closing
tags &c.)
It doesn't particulary matter either way but which parts of habari
would you have changed? Are plugin and theme authors so used to xhtml
syntax that html 4.01-style syntax would increase the friction of
developing for habari?
--
Firas Durri | http://firasd.org | 617-894-1657
vkaryl
used html 4.01 for years now, and I'm not planning to return to it. I
think the "legacy platform" thing is overblown.... and that the mime
type will sort itself before much longer in the overall schema.
In the long run, I'm not dev'ing themes for Habari, I'm dev'ing themes
for me and my clients. If Habari comes "standard" with html 4.01
themes fine; I'll simply continue to do xhtml myself.
However, I *think* that if Habari regresses to html 4.01, there will
be a fair amount of people who will feel that Habari is therefore not
particularly "forward-motion". Which may or may not be
problematic.... though considering its cutting-edge backend
positioning....
On Feb 16, 1:37 pm, "Firas Durri" <fir...@gmail.com> wrote:
> I think that the ostensible harm of serving xhtml with the wrong mime
> type is overblown. I think serving html 4.01 would cause more
> consternation than whatever chickens are coming home (which ones?)
>
> Personally I'd rather not relearn the few syntax differences that html
> 4.01 had from what I've been working with for five years (self-closing
> tags &c.)
>
> It doesn't particulary matter either way but which parts of habari
> would you have changed? Are plugin and theme authors so used to xhtml
> syntax that html 4.01-style syntax would increase the friction of
> developing for habari?
>
Root
A bit of light reading:
vkaryl
Where exactly are YOU seeing problems brought on by using xhtml, Root?
Firas Durri
Firas Durri
Root
vkaryl
it's a huge problem for you, you can always use the option here:
http://www.workingwith.me.uk/articles/scripting/mimetypes
And I repeat, where exactly are YOU seeing problems brought on by
using xhtml, Root?
Root
Many leading web devs are moving to html 4.0 as indeed am I very
shortly.
I see no reason for Habari to be using a broken standard.
vkaryl
"leading web dev".... Whatever.... I tend to think there's a lot of
superciliousness in your attitudinalizing here. But as I said
earlier, I don't care what you "leading devs" do, I'll just go on my
merry way.... and that piece of php wizardry I linked up earlier works
exactly as advertised, in case anyone cares....
Root
On Feb 16, 10:41 pm, "vkaryl" <vka...@bytehaven.com> wrote:
> Well, of course I wouldn't have "received the memo"; I'm not a
> "leading web dev".... Whatever.... I tend to think there's a lot of
> superciliousness in your attitudinalizing here. But as I said
> earlier, I don't care what you "leading devs" do, I'll just go on my
> merry way.... and that piece of php wizardry I linked up earlier works
> exactly as advertised, in case anyone cares....
>
Well I am not a leading web developer either. But it wouldn't be a bad
thing for Habari to adopt some forward thinking in this as in
everything else. There are some pros and cons in using scripts to
serve different mime types. The first step is to reach a deeper
understanding as to why what other platforms do is unsatisfactory.
Then we can try and reach a consensus about what to do.
I would hazard a guess that any client who understood the issue would
go with html. It was after all published as long ago as - heck - one
month before the xhtml transitional. Hardly a regression. The case for
serving faux xhtml with the wrong mime type for any longer is
unsustainable. I have been forced into following the crowd against my
better judgment on a number of *too cool* blog platforms. If we want
any hope of moving to the new web standards emerging we need to get
straight now. WP is in some difficulty in this regard.
vkaryl
simply keeps on keepin' on at this point, eventually the world's most
broken browser will manage to fall into line. For instance, had
"leading web devs" the world around not kept up the "valid CSS"
pressure on MS, IE7 would be even more broken than IE6 (no, MS
wouldn't have done that on purpose, they simply wouldn't have made
much if any change - so the only upshot would have been a change in
the version number, not the fairly viable changes which WERE made).
So if "leading web devs" decide to go hide in the html 4.01 burrow,
xhtml isn't ever going to happen the way it SHOULD happen. But if
everyone keeps the pressure on.... by using it....
Root
Its worth reading.
http://www.w3.org/TR/xhtml-media-types/
This has something but not a lot - to do with IE. Any User Agent will
serve the wrong mime type as tag soup.
It is meant to.
Root
> So if "leading web devs" decide to go hide in the html 4.01 burrow,
> xhtml isn't ever going to happen the way it SHOULD happen. But if
> everyone keeps the pressure on.... by using it....
>
The *Executive Summary*
http://www.w3.org/TR/xhtml-media-types/#summary
I rest my case.
vkaryl
didn't already know. S'okay, Root, you go your way and be happy....
Root
On Feb 16, 11:36 pm, "vkaryl" <vka...@bytehaven.com> wrote:
> Er yah.... I've read it. I doesn't really address much of anything we
> didn't already know. S'okay, Root, you go your way and be happy....
>
And there is more. Matt Mullenweg May 5 2003:
http://www.goer.org/Journal/2003/04/the_xhtml_100.html#comments
WordPress is going to be xhtml STRICT right out of the box. Er not
quite.
chrisjdavis
standard we can go back to HTML 4.01. Habari is geared towards using
the most recent, and sometimes cutting edge standards and technology
that the web has to offer. Moving to HTML 4.01 would fly in the face
of what we are trying to do, therefore, I am pretty sure we shouldn't
do it.
The only areas of Habari that we need concern ourselves with are those
under our control, e.g. the Admin area, bundled help area and the
default theme. If we can't write well formed XHTML for these three
areas, then there is a larger problem here than what version of HTML
we think is peachy keen.
If we create well formed, valid XHTML and a browser borks on it, then
that really isn't our concern is it? This is yet another instance
where we (being the user community) are enabling browser manufacturers
to be lazy, sloppy coders. I for one, am tired of it.
And yes before you ask I have written my own web browser before, so I
am somewhat familiar with the travails of implementing these things.
Chris
Root
On Feb 18, 1:20 am, "chrisjdavis" <chrisdmi...@gmail.com> wrote:
> As for my vote, when the standards bodies rescind XHTML as an official
> standard we can go back to HTML 4.01. Habari is geared towards using
> the most recent, and sometimes cutting edge standards and technology
> that the web has to offer. Moving to HTML 4.01 would fly in the face
> of what we are trying to do, therefore, I am pretty sure we shouldn't
> do it.
>
Chris, serving xhtml with the wrong mime type is not, and has never
been; an official standard. The W3C say it *should not be used* as per
my reference given. How does that make it an official standard?
Valid xhtml makes no difference. A browser will render the text/html
mime type as tag soup anyway.
If Habari really wants to adopt cutting edge standards then we need to
plan on maintaining the integrity of our code for over the next 10
years. XHTML trans is neither one thing nor the other. What I am
advocating is strategic thinking based on the real issues.
And slightly OT - some other platforms have adopted the *it validates*
policy. Well it may do and still be very unsatisfactory for IE users.
I hope that validation itself does not become a substitute for *sloppy
coding practices*. It is not enough.
Owen Winkler
>
>
> On Feb 18, 1:20 am, "chrisjdavis" <chrisdmi...@gmail.com> wrote:
> > As for my vote, when the standards bodies rescind XHTML as an official
> > standard we can go back to HTML 4.01. Habari is geared towards using
> > the most recent, and sometimes cutting edge standards and technology
> > that the web has to offer. Moving to HTML 4.01 would fly in the face
> > of what we are trying to do, therefore, I am pretty sure we shouldn't
> > do it.
> >
>
> Chris, serving xhtml with the wrong mime type is not, and has never
> been; an official standard. The W3C say it *should not be used* as per
> my reference given. How does that make it an official standard?
The W3C says "MAY", which does not mean "should not be used". I don't
want to get into a discussion of the nuances of "MAY"and "SHOULD"
here, since that's all pretty clear in the document you referenced.
But the bottom line is that sending it with text/html headers is
indeed valid, and creating XHTML tags in output now puts us in a
better position for when it makes sense (more browsers properly
support) to send the application/xhtml+xml mime type, which HTML would
not, since it is not XML-valid.
Owen
Andrew Krespanis
is saying it.
Essentially, Habari creates content by concatenating strings. At this
time, it has no inbuilt way of ensuring the resulting mega-string
(page) is well-formed XML. Until such abilities are added, we're
creating pseudo XML, crossing our fingers and sending it off into the
wilds of the intarwebs. As auto_p-esque formatting because more
complex (oh please Lord don't let Habari end up with something like
wp_autop()!), and content altering plugins become more prevalent, the
chances of Habari's output being well-formed XML become increasingly
less.
Output quality will only get worse from this point, not better. Living
in the false hopes that everyone (theme/plugin/content authors) will
just Do The Right Thing is an open invite to increasing entropy.
Habari has a chance to lead here, not by forcing either XHTML or HTML,
but by treating it's XML as such and building it in a node-based
manner.
Do I have the code to make this happen? No.
Do I know how much of a performance impact this may have? No.
Am I ready and willing to try and make this a reality? Hell Yes.
Andrew
---
http://leftjustified.net/
Root
better than me.
On Feb 19, 11:02 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
Rich Bowen
On Feb 19, 2007, at 18:02, Andrew Krespanis wrote:
>
> ... As auto_p-esque formatting because more
> complex (oh please Lord don't let Habari end up with something like
> wp_autop()!), ...
As one who is not familiar with the Wordpress code, I need some
clarification here. What, specifically, is so atrocious about wp_autop
()?
--
"He wrapped himself in quotations- as a beggar would enfold himself
in the purple of Emperors."
-- Rudyard Kipling
Doug Stewart
Jeff Harrell recently wrote not one but _two_ whole rants on the X/HTML debate:
http://theshapeofdays.com/2007/02/enough_with_the_x_already.html
http://theshapeofdays.com/2007/02/more_on_this_xhtml_nonsense.html
He's definitely of Ye Olde Schoole, so he comes down on the "serve
HTML only" side of the debate.
Still, worth a quick read.
--
-Doug
Scott Merrill
> To add some fuel to the fire:
> Jeff Harrell recently wrote not one but _two_ whole rants on the X/HTML debate:
> http://theshapeofdays.com/2007/02/enough_with_the_x_already.html
> http://theshapeofdays.com/2007/02/more_on_this_xhtml_nonsense.html
>
> He's definitely of Ye Olde Schoole, so he comes down on the "serve
> HTML only" side of the debate.
Users who want to write blog posts likely won't care about HTML vs
XHTML. We must keep this in mind as this conversation continues.
So if the user doesn't care, what are the relative benefits and
drawbacks to HTML and XHTML?
It sounds to me as though using HTML is a relatively "safe" way forward,
and it allows us to sidestep some potential problems.
But using XHTML allows a website to be processed by XML parsing tools.
I presume that parsing a plain ol' HTML document is a bit harder to do
than an XHTML document, by dint of the fact that XHTML is rigidly
structured XML. I don't know how folks might use XML parsing tools on
web sites in the future, but it seems to me we ought to be making it
easier for folks to do stuff with web content. If XHTML gets us closer
to this goal, then I think that's worth consideration.
There also seems to be a problem of adoption. XHTML isn't yet widely
adopted for use in some browsers. I am underwhelmed by this concern.
Habari requires a new(er) version of PHP _specifically_ because we want
to take advantage of what it has to offer. In the same way, I think
it's fair to have a high(er) expectation for client-side tools for Habari.
Yes, I understand the difference between requirements on the host, which
are one person's concern, and requirements on the clients, which may be
well out of our control. Nonetheless, the adoption rate of new tools
and technologies will not increase unless there are compelling reasons
to start using them. I would like to see Habari help drive the adoption
rate of useful technology, if that's at all within our capacity to do.
Andrew wrote:
> Habari has a chance to lead here, not by forcing either XHTML or HTML,
> but by treating it's XML as such and building it in a node-based
> manner
I like the idea of Habari taking the lead.
As I said above, I think most users won't care. If we provide a WYSIWYG
editor for Habari, then ostensibly that editor ought to handle the
construction of XHTML from user input. I do not know the ramifications
or challenges if we don't provide a WYSIWYG editor (or if users elect
not to use it).
Andrew, since you're ready and willing to take the effort to make Habari
build node-based XML, can you please outline what's involved, what
changes (if any) need to be made to current Habari content handling, and
how others might best help you in your effort?
Cheers,
Scott
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Root
> drawbacks to HTML and XHTML?
--
> GPG 9CFA4B35 | ski...@skippy.net |http://skippy.net/
I am not sure strictly whether the average end user is going to be the
best judge of this? Surely you do not mean that Scott?
Some of the relative benefits and the issues in continuing with faux
xhtml are in the references given.
I just hope some one is soon going to post a reference explaining why
serving xhtml with the wrong mime type is a *good thing* - if they can
find one. :)
Chris J Davis
mime type. I am serving a validly formed XHTML 1.1 document with the
correct mime type, and I have yet to see any problems arise from it.
There are some formatting issues that I have yet to address, but
those are squarely in the realm of oddities in CSS implementation,
not in mime types.
I too am appreciative of this conversation staying, for the most
part, cordial. It is important to try to keep a level head when
communicating in a medium that lacks context. This is an
admonishment to myself as much as anyone else.
Chris
On Feb 20, 2007, at 11:22 AM, Root wrote:
>
> So if the user doesn't care, what are the relative benefits and
>> drawbacks to HTML and XHTML?
>
> --
>> GPG 9CFA4B35 | ski...@skippy.net |http://skippy.net/
>
> I am not sure strictly whether the average end user is going to be the
> best judge of this? Surely you do not mean that Scott?
>
> Some of the relative benefits and the issues in continuing with faux
> xhtml are in the references given.
>
> I just hope some one is soon going to post a reference explaining why
> serving xhtml with the wrong mime type is a *good thing* - if they can
> find one. :)
>
> I am really pleased that this thread has now risen appreciably above
> the level of the earlier contributions. Thanks to all who have so far
> taken part. We may never get any kind of concensus but at least the
> issue is beginning to be explored.
>
>
> >
Root
document - then that - surely - is completely outside the purview of
this dialogue which concerns the wisdom of serving xhtml 1.0
transitional with a text mime type.
To respond to some earlier replies: The issue here goes some way
beyond what we do in our themes, or what our clients say they think
they would like in a theme. This is about the more substantive part of
the app - which I would venture to suggest is the admin area and all
things therein.
Scott Merrill
> So if the user doesn't care, what are the relative benefits and
> drawbacks to HTML and XHTML?
Root replied:
> I am not sure strictly whether the average end user is going to be the
> best judge of this? Surely you do not mean that Scott?
No, I don't mean to ask the end user about what they perceive as the
relative benefits of using HTML or XHTML.
If the end user doesn't care, how should that guide us in the
development of the application that the user will use?
What are the relative benefits and drawbacks for HTML and XHTML in terms
of Habari development? What are the relative benefits and drawbacks for
HTML and XHTML in terms of any user's use of Habari?
Chris J Davis
think, since it is about the correct HTML version to use and the
correct mime type. My point was that XHTML, of any flavor, is fine
when sending the correct type. If we are using XHTML transitional,
then we will send the type that is recommended, and things should be
fine.
That was what I was getting at. From what I understand we should be
sending the same mime type with transitional as I do with 1.1:
application/xhtml+xml
Thoughts?
Chris
Root
If we were to switch to html the end user (with the browser) would not
see any difference.
To that extent it would not make any difference to him anyway.
The site/blog operator would not see any difference either.
So from that perspective there is no incentive to continue as we are.
>From the Habari development perspective (ie writing interface markup)
the change would be almost unnoticeable. The differences in spec are
small. It would not impose a burden.
The difference may come if and when any new standard is agreed on, and
we need to upgrade our code.
At least we will be clear as to where we are.
In the meantime the difference might be one of perception. Some people
might be kidding themselves that because we are declaring xhtml trans
we are getting ready for xml docs. We are not. Its a chimera. This is
going to apply to plugins and javascript particularly. I have a
feeling there is going to be plenty of both.
Secondly we would be doing the *right thing* by not polluting the net
with malformed dtd/mime types which may be copied by a lot of folk.
Thirdly we would be taking a principled and well informed stance. For
a forward looking community looking for credibility that is a big
plus. It would differentiate us as innovative, smart, and being
industry leaders as opposed to crowd followers. We are by no means
going to be alone.
Finally we are going to head off at the pass a whole lot of bitching
from some very clever folks and fancy dudes trying to do things like
upgrade to xhtml strict by changing the mime type. Opera users in
particular are prone to this type of thing. One VERY experienced Opera
user got loose in the WP forum and caused chaos because he was right.
Not that any one admitted it. Those sorts of guys may be lurking here
already.
I am beginning to think a core downgrade to html 4.0 allied to a
modular processor as proposed might be ideal.
There are just some early thoughts. By no means a complete list.
Root
the mime type you suggest will:
1. Not be accessible AT ALL in IE because it is not an xml parser.
2. Will not be accessible in other browsers if it contains any other
validation error (which being a blog it will do).
Mark Pilgrim
> I am not sure who is saying that we should serve XHTML with the wrong
> mime type. I am serving a validly formed XHTML 1.1 document with the
> correct mime type, and I have yet to see any problems arise from it.
Are you talking about http://chrisjdavis.org/ ? Because if so, you
are mistaken. Your page is being interpreted as text/html. You can
easily verify this by going to Tools / Page Info and looking at the
"Type" field. (For comparison, a blog that is *actually* served as
application/xhtml+xml is here: http://www.intertwingly.net/blog/ )
It appears that you are attempting to override the Content-Type HTTP
header with a META element. That doesn't work; browsers are still
treating your page as text/html. I suggest you change your web server
settings to serve your pages with the application/xhtml+xml Content-
Type HTTP header and revisiting, for example, your colophon:
http://chrisjdavis.org/colophon/
Chris J Davis
I discovered that Habari is sending the mime type programmatically
(via a line found in index.php), which is not something that I was
aware of or particularly fond of.
As for the colophon, it breaks because of pingback content, since one
of the pingbacks uses » in the title text, I removed comments
from my colophon, which I don't really want anyway, and wow, it
renders fine now. My site is running with Habari serving the correct
mime type for the next little bit. I am sure IE won't be happy but
there are no other problems, at least on the colophon page, and the
index page.
Chris
Root
> On Feb 20, 2007, at 2:58 PM, Mark Pilgrim wrote:
>
>
>
> > Are you talking abouthttp://chrisjdavis.org/? Because if so, you
> > are mistaken. Your page is being interpreted as text/html. You can
> > easily verify this by going to Tools / Page Info and looking at the
> > "Type" field. (For comparison, a blog that is *actually* served as
> > application/xhtml+xml is here:http://www.intertwingly.net/blog/)
>
Welcome to Habari Mark. Your expertise will be both welcomed and
valued.
Root
On Feb 20, 9:08 pm, "Root" <atthe...@gmail.com> wrote:
> > On Feb 20, 2007, at 2:58 PM, Mark Pilgrim wrote:
>
> > > Are you talking abouthttp://chrisjdavis.org/? Because if so, you
> > > are mistaken. Your page is being interpreted as text/html. You can
> > > easily verify this by going to Tools / Page Info and looking at the
> > > "Type" field. (For comparison, a blog that is *actually* served as
> > > application/xhtml+xml is here:http://www.intertwingly.net/blog/)
>
Here is a screenshot of Chris J Davis site in IE 6.
http://more404.com/user/themes/k2/images/snapshot.png
That is what happens when we serve up application/xhtml+xml. What use
is that?
Firas Durri
Does valid xhtml mostly sneak by validation under a 4.01 doctype?
--
Firas Durri | http://firasd.org | 617-894-1657
Chris J Davis
Are you planning on helping out officially, or were you just lending
your voice to this debate? We would love to have someone who is a
recognized authority on this subject involved, if you have time.
If you were open to more discussion:
For some perspective, I am only advocating the use of XHTML for areas
we have complete control of, e.g. the Admin area, and the default
theme. I do not think we should be sending the mime type via the
index.php as we are doing now, since it doesn't allow Theme Authors
the flexibility to design as they would like.
What I would rather see is the theme.php included in each theme
declare the mime type. Is it your position Mark, that XHTML is
pointless and a waste of our time, or something that we shouldn't be
forcing on end users due to Browser compatibility concerns?
Root
Andrew Krespanis
wants to tackle, so they get swept under the carpet. Things like the
wrapping of HTML comment contents in <p>s and other, larger, annoying
little bugs that take people by surprise.
It started off small and focused, but with time has grown to be an
unwieldy beast.
Andrew
---
http://leftjustified.net/
Mark Pilgrim
> Are you planning on helping out officially, or were you just lending
> your voice to this debate? We would love to have someone who is a
> recognized authority on this subject involved, if you have time.
I have joined this mailing list. I promise nothing else.
> For some perspective, I am only advocating the use of XHTML for areas
> we have complete control of, e.g. the Admin area, and the default
> theme. I do not think we should be sending the mime type via the
> index.php as we are doing now, since it doesn't allow Theme Authors
> the flexibility to design as they would like.
>
> What I would rather see is the theme.php included in each theme
> declare the mime type. Is it your position Mark, that XHTML is
> pointless and a waste of our time, or something that we shouldn't be
> forcing on end users due to Browser compatibility concerns?
XHTML served as text/html is a pointless waste of time; browsers parse
it as broken HTML, so it buys you literally nothing. XHTML served as
application/xhtml+xml is really really hard to do correctly (see
below), but it does allow you to embed SVG inline. Also, to do some
incredibly esoteric accessibility stuff that about 50 people in the
world understand. Both of these have been "backported" to HTML (Sam
Ruby backported SVG, and I backported the accessibility stuff), so
application/xhtml+xml really just buys you a world of hurt for no
reason. Anyone who says that XHTML is "better" or "more semantic" or
"more well-defined" than HTML is misinformed or lying.
Read <http://diveintomark.org/archives/2003/08/29/semantics> and
<http://hsivonen.iki.fi/wannabe/> before you argue about web
standards. Read <http://dig.csail.mit.edu/breadcrumbs/node/166>
before you say that "XHTML is the future." Read
<http://diveintomark.org/archives/2004/01/14/thought_experiment> and
then consider whether using application/xhtml+xml on administration
pages is a good idea. Note that many TrackBack implementations
*still* send content without specifying the character encoding, which
is both crucial for maintaining wellformedness and impossible to guess
with 100% accuracy. Read <http://hsivonen.iki.fi/producing-xml/>
before you produce XML in any form. This includes XHTML, Atom, and
Atom Publishing Protocol responses. Then read
<http://www.xml.com/pub/a/2003/07/02/dive.html> and
<http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff> to
learn how serving XHTML as application/xhtml+xml will affect layout,
CSS parsing, and JavaScript execution. Then consider that IE does not
support application/xhtml+xml at all, so you will need to detect that
and serve it text/html instead, which means you will need to write CSS
and JavaScript that work in both environments. All of these things
are harder than you think.
If you want to produce application/xhtml+xml, you are free to do so.
If you get it right, no one will notice. If you get it wrong, no one
will forgive you.
--
Cheers,
-Mark
Mark Pilgrim
> As for the colophon, it breaks because of pingback content, since one
> of the pingbacks uses » in the title text, I removed comments
> from my colophon, which I don't really want anyway, and wow, it
> renders fine now. My site is running with Habari serving the correct
> mime type for the next little bit. I am sure IE won't be happy but
> there are no other problems, at least on the colophon page, and the
> index page.
Well I still see it being served up as text/html, but that's probably
a good thing, because most of your posts are not valid (and probably
not well-formed either). Your featured post
<http://chrisjdavis.org/2005/05/26/secrets-of-wp-theming-part-1/> has
29 errors. Your post <http://chrisjdavis.org/holy-lent-draws-near>
has an unescaped ampersand. Many of your posts seem to share a
similar problem of improperly nested blockquotes.
I do not point this out to denigrate you or your work. I have no
doubt that you could find validation errors on my blog. I know for a
fact you could find them on diveintopython.org, and probably my other
sites as well. My point is simply that validation is hard,
wellformedness is hard, XHTML is hard, and the only reason you haven't
noticed is because you haven't *really* been using XHTML (in the sense
that you haven't been using Content-Type: application/xhtml+xml). Try
it for a few weeks and let me know how it goes.
--
Cheers,
-Mark
chrisjdavis
I was just wanting to know how many times I could say "Mark, what do
you think about this.." or "Hey Mark, what color socks do you
wear..". Good to know.
> Well I still see it being served up as text/html, but that's probably
> a good thing, because most of your posts are not valid (and probably
> not well-formed either).
I had to change the type back to text/html since it was killing the
Habari admin area and I have actual coding to do, not just one up-man-
ship with people :)
> My point is simply that validation is hard,
> wellformedness is hard, XHTML is hard, and the only reason you haven't
> noticed is because you haven't *really* been using XHTML (in the sense
> that you haven't been using Content-Type: application/xhtml+xml). Try
> it for a few weeks and let me know how it goes.
I tried it for a couple of hours today and could see the difficulties
it would present, not to mention the fact that it made me stop using
HTML entities, one of my favoritest things the whole wide world. So,
we should use HTML 4.01 as our standard. I am open to discussing this
further in a more official capacity.
Committers and Community Members gather round, we got some talking to
do.
Chris
vkaryl
closed tags.... Again, it really doesn't matter to me what the
official position and release is/does.
Andrew Krespanis
> I'm not thrilled with regressing to html 4.01.
It's not regression, Habari never got it right in the first place.
On Feb 20, 7:21 pm, "chrisjdavis" wrote:
> we should use HTML 4.01 as our standard. I am open to discussing this
> further in a more official capacity.
+1 for html 4.01 strict, with no shortcuts (ie: including all optional
closing tags, such as </p>, </li>, etc).
Andrew
--
http://leftjustified.net/
<layer src="ajax.shtml">I got your Web2.0 right here...</layer>
vkaryl
On Feb 20, 7:39 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
> On 2/21/07, vkaryl wrote:
> > I'm not thrilled with regressing to html 4.01.
>
> It's not regression, Habari never got it right in the first place.
>
> On Feb 20, 7:21 pm, "chrisjdavis" wrote:
>
> > we should use HTML 4.01 as our standard. I am open to discussing this
> > further in a more official capacity.
>
> +1 for html 4.01 strict, with no shortcuts (ie: including all optional
> closing tags, such as </p>, </li>, etc).
>
> Andrew
Root
On Feb 21, 2:39 am, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
> On 2/21/07, vkaryl wrote:
> > I'm not thrilled with regressing to html 4.01.
>
> It's not regression, Habari never got it right in the first place.
>
> On Feb 20, 7:21 pm, "chrisjdavis" wrote:
>
> > we should use HTML 4.01 as our standard. I am open to discussing this
> > further in a more official capacity.
>
> +1 for html 4.01 strict, with no shortcuts (ie: including all optional
> closing tags, such as </p>, </li>, etc).
>
> Andrew
Rich Bowen
On Feb 20, 2007, at 18:16, Andrew Krespanis wrote:
>
> It's a snake pit of regex voodoo that is full of tiny bugs that no one
> wants to tackle, so they get swept under the carpet. Things like the
> wrapping of HTML comment contents in <p>s and other, larger, annoying
> little bugs that take people by surprise.
>
> It started off small and focused, but with time has grown to be an
> unwieldy beast.
Ah. Thanks for the clarification.
That being the case, I don't see why we'd end up with something like
that. We, too, will start of small and focused, but will have a
larger mob of screaming zealots keeping it on track. Yes, eventually
my idealism will run down, but not yet.
>
> On 2/21/07, Rich Bowen <rbo...@rcbowen.com> wrote:
>>
>>
>> On Feb 19, 2007, at 18:02, Andrew Krespanis wrote:
>>
>>>
>>> ... As auto_p-esque formatting because more
>>> complex (oh please Lord don't let Habari end up with something like
>>> wp_autop()!), ...
>>
>> As one who is not familiar with the Wordpress code, I need some
>> clarification here. What, specifically, is so atrocious about
>> wp_autop
>> ()?
>>
>> --
>> "He wrapped himself in quotations- as a beggar would enfold himself
>> in the purple of Emperors."
>> -- Rudyard Kipling
>>
>>
>>
>>>
>>
>
> >
--
If you miss this moment
You miss your life
Andrew Krespanis
> That being the case, I don't see why we'd end up with something like
> that.
I was having a think about the whole autop thing today, and if memory
serves, it was the continual mod's required by edge-cases that caused
wp_autop to spiral out of control. (the total lack of test cases
doesn't help)
What started as a simple preg_replace, grew into the monster it is
today due to the use of other markup within a post.
To prevent Habari form ever going down that path, I'd like to suggest
3 alternative content formatting options as default (or as plugins
shipped with the default install):
1. plain text. Like, REAL plain text, nothing stripped. This is the
option that would be used by those who want full control over their
markup. Line breaks, and everything else, should remain untouched.
Mmmm...pristine.
2. Markdown [http://daringfireball.net/projects/markdown/]
3. Textile[http://www.textism.com/tools/textile/]
And as simple as that, we've provided autop-like formatting (both
Markdown and Textile do this), along with the complete control option,
without ever setting foot in the dangerous turf of "some markup
allowed, some inserted automagically"
Not having the option to mix and match like between HTML and plain
text might seem a bit limiting for old school WP users, but I think in
the long run we could save the Habari project a lot of potential
grief.
How do people feel about this idea?
Andrew
--
http://leftjustified.net/
Scott Merrill
> To prevent Habari form ever going down that path, I'd like to suggest
> 3 alternative content formatting options as default (or as plugins
> shipped with the default install):
>
> 1. plain text. Like, REAL plain text, nothing stripped. This is the
> option that would be used by those who want full control over their
> markup. Line breaks, and everything else, should remain untouched.
> Mmmm...pristine.
>
> 2. Markdown [http://daringfireball.net/projects/markdown/]
>
> 3. Textile[http://www.textism.com/tools/textile/]
If we implement these as plugins (presumably storing the filtered
content in the cached_content field?), why stop at three choices? A
plugin author could construct a wp_autop() workalike filter.
I like the idea of the default as "unfiltered", and then the author can
elect which filtering mechanism to apply to their posts.
This raises some additional questions though: should this be a per-post
setting? That is, can an author elect at post composition which filter
to apply? If so, should there be any per-author default which can be
set in their profile page somewhere? And finally, can a site admin
mandate a particular format for all posts on the site?
If this is in any way a variable setting, how do we encode in the post
object which filter to apply when rendering the output? Do we encode it
once at "save" and stick the final result in the cached_content field?
I assume that's the best way, but I'd like to get some verification of that.
Chris J Davis
flexibility. I think that taking Andrew's suggestion (shipping with
markdown and textile plugins) is a sound one, and I second Skippy's
call for the default being unfiltered (which is how I write my posts).
Allowing users to decide how they handle their content can only be
good, even if that means someone can port the WP auto_p() function to
Habari and produce crappy output.
Chris
Root
On Feb 21, 1:08 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
What about this http://hp.jpsband.org/comparison.html
Is that any good to you?
Nichod
> > GPG 9CFA4B35 | ski...@skippy.net |http://skippy.net/- Hide quoted text -
>
> - Show quoted text -
Andrew Krespanis
> This raises some additional questions though: should this be a per-post
> setting?
Absolutely. I would love to be able to type out a quick post in
Markdown and do a longer post in html. I was thinking that the option
should be stored in post_meta or similar? More importantly, in my mind
the post would be transformed to the end result _before_ saving to the
DB, thereby negating any need for the public face of the site to a)
know or care about transformations; and b) have to do any extra work.
After all, the more processing we can keep on the admin side, the less
things we'll have slowing down page views for users/readers/customers.
Markdown, Textile (and MediaWiki?) formats are all reversible -- when
a post is edited, it can be easily transformed into its original
format.
> That is, can an author elect at post composition which filter
> to apply?
Yes. I'm thinking a dropdown <select>, into which plugins can add more
options (though the idea of keeping all but plain text options as
plugins is a +1 form me -- including plugins written by the core
committers is a great way to demo best practice). Whilst conversion
filters can be written, I don't think Habari should try to hard to
cover this by default, as some of the non-HTML formats have features
that the others don't support.
The option to convert to HTML should be there by default, as that
would be easy to call -- assuming all text transform plugins have a
predictable interface. (perhaps there should be a specific plugin
class that extends Plugin? or a different abstract class for text
transformation plugins?)
> If so, should there be any per-author default which can be
> set in their profile page somewhere? And finally, can a site admin
> mandate a particular format for all posts on the site?
Yes and yes.
Andrew
--
http://leftjustified.net/
Scott Merrill
> I was thinking that the option
> should be stored in post_meta or similar?
The declaration of the formatting option used for the post? Yeah,
that's a valid use of postinfo, especially if the default is no
formatting, which means no postinfo record would be necessary.
> More importantly, in my mind
> the post would be transformed to the end result _before_ saving to the
> DB, thereby negating any need for the public face of the site to a)
> know or care about transformations; and b) have to do any extra work.
> After all, the more processing we can keep on the admin side, the less
> things we'll have slowing down page views for users/readers/customers.
So you're saying to store the formatted post in the content field?
Maybe I'm confused: why do we have a cached_content field?
> Markdown, Textile (and MediaWiki?) formats are all reversible -- when
> a post is edited, it can be easily transformed into its original
> format.
Neat.
> The option to convert to HTML should be there by default, as that
> would be easy to call -- assuming all text transform plugins have a
> predictable interface. (perhaps there should be a specific plugin
> class that extends Plugin? or a different abstract class for text
> transformation plugins?)
Can you please elaborate a bit on this? I don't understand what you're
suggesting.
Owen Winkler
>
> I tried it for a couple of hours today and could see the difficulties
> it would present, not to mention the fact that it made me stop using
> HTML entities, one of my favoritest things the whole wide world. So,
> we should use HTML 4.01 as our standard. I am open to discussing this
> further in a more official capacity.
>
I assume self-closing tags are out when using HTML 4.01? That sucks.
Still, there is more to this issue than the technical side. There is
obviously a barrier of perception.
HTML is perceived by people who are not Mark Pilgrim or Root as "the
old way", regardless of whether that perception is accurate, and the
education they would provide is not knowledge that is widespread. It
will take an effort to convince users who "don't care about what
standards are broken as long as their blog outputs" that out HTML
isn't antiquated in comparison to the XHTML (valid or not) of other
tools. Who will lead this charge in the user domain?
I assume that users will want to use a tool that is "more valid", but
convincing them that Habari is this when using text/html with HTML
will be the true challenge. Even with the standards evangelists out
there proclaiming the mysteries of HTML vs XHTML, I feel like this is
a war not fought. I've been doing this for years, trying to follow
this debate all along, and I'm still confused about the details of
what's involved.
It's still unclear to me why it's a disadvantage to attempt to serve
XML-like content with an HTML mimetype if browsers continue to render
it and it continues to validate. Being that Habari has been serving
XML with an HTML mimetype all along, it would be helpful for someone
to explain in simple language the reason why changing our XHTML to
HTML will matter to anyone. "It's wrong," doesn't constitute an
answer in this case. The W3C recommendations allow us to serve XHTML
as text/html - why should we not? Why should we convert our markup
entirely to HTML and serve it as text/HTML? For what benefit?
I'm not saying we shouldn't, I'm simply curious about the perceived advantage.
Owen
Root
>
> It's still unclear to me why it's a disadvantage to attempt to serve
> XML-like content with an HTML mimetype if browsers continue to render
> it and it continues to validate. Being that Habari has been serving
> XML with an HTML mimetype all along, it would be helpful for someone
> to explain in simple language the reason why changing our XHTML to
> HTML will matter to anyone. "It's wrong," doesn't constitute an
> answer in this case. The W3C recommendations allow us to serve XHTML
> as text/html - why should we not? Why should we convert our markup
> entirely to HTML and serve it as text/HTML? For what benefit?
>
> I'm not saying we shouldn't, I'm simply curious about the perceived advantage.
>
> Owen
Crikey. I thought everyone was exhausted by this :)
Owen Winkler
Yes, this discussion is exhausting.
Still, we've reached no conclusion, and I haven't yet heard an
argument to fully persuade me that we should change what we're doing
already.
An appropriate argument would succinctly explain the following
specifically in regard to Habari:
1- The disadvantage in what we're doing now.
2- The advantage to developers and to our users of what we would do instead.
3- The way we're going to spin what we're doing in regard to my "HTML
is the old way" point in the thread above.
What I'm asking for is a compelling argument for it that a layman will
follow; something simple I can use to answer the question, "Why
doesn't Habari use more modern XHTML code like other tools?"
Owen
Root
On Feb 22, 1:03 pm, "Owen Winkler" <epit...@gmail.com> wrote:
I am beginning to think that anyone who hasn't been moved by the case
put forward by Mark Pilgrim and others probably isn't going to be
persuaded at all. To that extent I myself am unwilling to remain
engaged in further controversy.
More fundamentally this raises two issues. One is how 4 primary
developers all of whom have veto powers respond to these types of
questions. Well we will just have to go with what you do. The second
issue is what might be called the *interface* between the backend and
front end developers. This may be a poor rallying point for the front
end developers - I understand that. But the primary committers core
discipline is php. To really get the front end you deserve then at
some stage you are going to need to engage with the interface
designers *on their terms*. I say on their terms because the things
that they are interested in / care about / are good / at may be
different from yours. Speaking from experience on other platforms this
can cause a chasm. And that chasm in turn causes a million pin pricks
for the end user. The admin panel wont run in I E?
You can't use the text editor on a Mac? Opera users can't access the
forum? All these types of thing stem from the same mind set. It
validates so we must be right. The problem with that approach is that
all the people who may be in a position to assist give up and drift
away. And in my limited experience, a certain lack of clarity and
unwillingness to commit to certain goals like *the blog should be
viewable in all browsers*
is often to blame. I think we have all benefited from Mark Pilgrims
input. What the commiters do now is up to them. That is my last two
cents.
OT: I do not understand why a continuing dialogue which has had 56
posts or so keeps being hijacked by the auto p gang. There is a
message in that. We can all move on to something else.
Rich Bowen
>
> OT: I do not understand why a continuing dialogue which has had 56
> posts or so keeps being hijacked by the auto p gang. There is a
> message in that. We can all move on to something else.
I had no intent to hijack, and that's why I changed the subject line
when I forked the thread. I don't care about XHTML vs HTML. I care
that my pages and atom feeds render correctly. I tried to care, and
was unable to do so.
--
If we only live,
We too will go to sea in a Sieve,---
To the hills of the Chankly Bore!
Scott Merrill
> What I'm asking for is a compelling argument for it that a layman will
> follow; something simple I can use to answer the question, "Why
> doesn't Habari use more modern XHTML code like other tools?"
How would you respond to that argument right now, if you were pressed to
do so? Surely you can articulate something on this issue, by playing
devil's advocate for the other side.
Root observed:
> More fundamentally this raises two issues. One is how 4 primary
> developers all of whom have veto powers respond to these types of
> questions.
Actually, 10 people now have veto power. Anyone who's name appears on
the front page of the Google Code site under "Project Owners" and
"Project Members" has a binding vote. This number will continue to
increase.
> But the primary committers core
> discipline is php. To really get the front end you deserve then at
> some stage you are going to need to engage with the interface
> designers *on their terms*. I say on their terms because the things
> that they are interested in / care about / are good / at may be
> different from yours.
This is absolutely a valuable insight: subject matter experts should be
recognized. However, I don't think Owen's question above is so much an
outright rejection of anyone's expertise, but rather a legitimate
question on how to transfer the subject matter experts' opinions into
meaningful information to disseminate to end users.
We cannot say to our users "Go read all these posts (linked in Mark
Pilgrim's message) to educate yourself on this issue." We need to be
able to have clear speaking points that a layperson can understand.
It is important that discussions like this occur: it transfers knowledge
from experts to others. It ensures that we all understand why decisions
are being made. The more we all understand things, the better we'll
each be able to advocate and defend Habari to its detractors. To simply
say "Oh, you're the expert, we'll do it your way" is dangerous. Just
like we want peer review of code, to catch niggling problems and catch
omissions, so too do we want peer review of policy decisions,
documentation, standards compliance, etc etc.
I know this has been a laborious discussion, but I hope everyone can
take it as an example of a healthy community working together toward a
common goal.
Root
On Feb 22, 2:09 pm, Scott Merrill <ski...@skippy.net> wrote:
> Owen said:
>
> > What I'm asking for is a compelling argument for it that a layman will
> > follow; something simple I can use to answer the question, "Why
> > doesn't Habari use more modern XHTML code like other tools?"
>
> How would you respond to that argument right now, if you were pressed to
> do so? Surely you can articulate something on this issue, by playing
> devil's advocate for the other side.
>
OK. First up my gut feeling is that 99% of our target market will not
know/ care/ be interested in this question.
Secondly any themer can do their own thing. Our thinking is about
admin and bundled themes.
Finally by way of context we would need to bear in mind (but
definitely not saying so) that our interlocutor
is likely to be ill informed.
Bearing all that in mind what could we say?
Well like a lot of blog platforms Habari looked at xhtml pretty
closely. But the thing is it was only ever meant to be a transitional
standard. As the most commonly used browsers were not interpreting the
code as xml anyway we thought it right to reconsider whether we should
be using it. What we found surprised us: Here are some of our
thoughts:
We can not use xml because IE is not an xml parser.
We could use xhtml like a lot of people if we use the wrong mime type.
If we do it still wont be parsed as xml by Firefox and other modern
browsers.
But if we do that we have to go to a lot of trouble to escape our
scripts.
Our code can't be converted to xml in the future anyway.
It renders inconsistently.
And a lot of other stuff.
Using html is better. XHTML is JUST AS OLD.
That way all our plugin and themer community is working to a standard
which works.
And we are going to be well positioned for <em>the new standards</em>
like html 5.0 and web 2.0.
We are planning ahead. WE do not want our users trapped in *LEGACY
CODE*. :)
We are really happy with our choice. A lot of other folk are doing it
now as well like [add links here]
Sometimes being forward thinking means not jumping on the bandwagon.
Or in this case jumping off it.
Now let me ask you something Joe? Has it made any difference to you?
Root
On Feb 22, 2:04 pm, Rich Bowen <rbo...@rcbowen.com> wrote:
>
> I had no intent to hijack, and that's why I changed the subject line
> when I forked the thread. I don't care about XHTML vs HTML. I care
> that my pages and atom feeds render correctly. I tried to care, and
> was unable to do so.
>
> --
Why the atom feeds do not work is intimately related to the question
of standards and specification I would have thought. And a mess of br
tags might not be an elegant solution from any stand point. But I
sense your frustration and I am not a php guru.
FreAkErZ
I have an atomhandler.phps you could try out, the feeds should work
right with that version.
Please tell me if it does not work in that thread :)
Thanks!
Andrew
muffinresearch
academic. I personally would suggest that it should be down to the
individual user. Not the tool/blogging platform etc.
I would also suggest that as a result is should be possible to use
either and the tools for writing code will handle the basic
differences. As for taking care of valid XML that's another thing
entirely. But you won't be able to stop a user screwing up somewhere
along the line.
Note: I'm new to Habari and so I may not be up to speed on everything
you're trying to achieve. If this comment is not relevant please
ignore it.
Regards,
Stuart
On Feb 20, 5:10 pm, Scott Merrill <ski...@skippy.net> wrote:
> Doug Stewart wrote:
> > To add some fuel to the fire:
> > Jeff Harrell recently wrote not one but _two_ whole rants on the X/HTML debate:
> >http://theshapeofdays.com/2007/02/enough_with_the_x_already.html
> >http://theshapeofdays.com/2007/02/more_on_this_xhtml_nonsense.html
>
> > He's definitely of Ye Olde Schoole, so he comes down on the "serve
> > HTML only" side of the debate.
>
> Users who want to write blog posts likely won't care about HTML vs
> XHTML. We must keep this in mind as this conversation continues.
>
> So if the user doesn't care, what are the relative benefits and
> drawbacks to HTML and XHTML?
>
> It sounds to me as though using HTML is a relatively "safe" way forward,
> and it allows us to sidestep some potential problems.
>
> But using XHTML allows a website to be processed by XML parsing tools.
> I presume that parsing a plain ol' HTML document is a bit harder to do
> than an XHTML document, by dint of the fact that XHTML is rigidly
> structured XML. I don't know how folks might use XML parsing tools on
> web sites in the future, but it seems to me we ought to be making it
> easier for folks to do stuff with web content. If XHTML gets us closer
> to this goal, then I think that's worth consideration.
>
> There also seems to be a problem of adoption. XHTML isn't yet widely
> adopted for use in some browsers. I am underwhelmed by this concern.
> Habari requires a new(er) version of PHP _specifically_ because we want
> to take advantage of what it has to offer. In the same way, I think
> it's fair to have a high(er) expectation for client-side tools for Habari.
>
> Yes, I understand the difference between requirements on the host, which
> are one person's concern, and requirements on the clients, which may be
> well out of our control. Nonetheless, the adoption rate of new tools
> and technologies will not increase unless there are compelling reasons
> to start using them. I would like to see Habari help drive the adoption
> rate of useful technology, if that's at all within our capacity to do.
>
> Andrew wrote:
> > Habari has a chance to lead here, not by forcing either XHTML or HTML,
> > but by treating it's XML as such and building it in a node-based
> > manner
>
> I like the idea of Habari taking the lead.
>
> As I said above, I think most users won't care. If we provide a WYSIWYG
> editor for Habari, then ostensibly that editor ought to handle the
> construction of XHTML from user input. I do not know the ramifications
> or challenges if we don't provide a WYSIWYG editor (or if users elect
> not to use it).
>
> Andrew, since you're ready and willing to take the effort to make Habari
> build node-based XML, can you please outline what's involved, what
> changes (if any) need to be made to current Habari content handling, and
> how others might best help you in your effort?
>
> Cheers,
> Scott
Chris J Davis
I am not sure what you mean here. We responded, I didn't agree with
you then, and I don't necessarily agree with you now, but I can admit
that I am not the expert that Mark is on this point, therefore I am
open to voting on changing our official spec to HTML 4.01 if that is
what the community feels is best. I am in the same camp as Owen
personally but I am comfortable going with decisions that I don't
particularly think are the best, since I try not to be a totalitarian
and can't always be right.
In fact I called for official discussion on this point, as well as a
vote. That is the appropriate response to this sort of thing, and is
in keeping with the spirit of the "Habari Way". What would you have
liked to seen different?
> Well we will just have to go with what you do. The second
> issue is what might be called the *interface* between the backend and
> front end developers. This may be a poor rallying point for the front
> end developers - I understand that. But the primary committers core
> discipline is php. To really get the front end you deserve then at
> some stage you are going to need to engage with the interface
> designers *on their terms*. I say on their terms because the things
> that they are interested in / care about / are good / at may be
> different from yours. Speaking from experience on other platforms this
> can cause a chasm. And that chasm in turn causes a million pin pricks
> for the end user. The admin panel wont run in I E?
> You can't use the text editor on a Mac? Opera users can't access the
> forum? All these types of thing stem from the same mind set. It
> validates so we must be right. The problem with that approach is that
> all the people who may be in a position to assist give up and drift
> away. And in my limited experience, a certain lack of clarity and
> unwillingness to commit to certain goals like *the blog should be
> viewable in all browsers*
> is often to blame. I think we have all benefited from Mark Pilgrims
> input. What the commiters do now is up to them. That is my last two
> cents.
I am not sure how many time we need to say this, but the committers
try to reflect the will of the community. If the community shows
overwhelming support for something, then we would be silly not to see
the wisdom in it. We are trying very hard to not be dictators, but
custodians.
Root
On Feb 22, 3:45 pm, "muffinresearch" <muffinresea...@gmail.com> wrote:
>
> As for taking care of valid XML that's another thing
> entirely. But you won't be able to stop a user screwing up somewhere
> along the line.
Hi muffinresearch and welcome to Habari.
Your php expertise is going to be useful and welcome.
I hope you do not mind me mentioning that you have 120 validation
errors on your blog.
Fixing them up would give you a much more stable performance across
platform.
Yeah. The user is almost bound to screw up. That is why I propose we
rely on him as little as possible.
>
Owen Winkler
>
> I am not sure what you mean here. We responded, I didn't agree with
> you then, and I don't necessarily agree with you now, but I can admit
> that I am not the expert that Mark is on this point, therefore I am
> open to voting on changing our official spec to HTML 4.01 if that is
> what the community feels is best. I am in the same camp as Owen
> personally but I am comfortable going with decisions that I don't
> particularly think are the best, since I try not to be a totalitarian
> and can't always be right.
I don't expect to always be right, but I want someone to get me to the
point where I at least understand the answer to the question that I'll
be solving. I mean, I can mindlessly implement HTML instead of XHTML,
but I, for myself, want to understand why this is what I should be
doing.
The statements "We could use xhtml like a lot of people if we use the
wrong mime type. If we do it still wont be parsed as xml by Firefox
and other modern
browsers." don't resonate with me. I don't understand why the mime
type is wrong when the W3C clearly says it's ok, or why we care that
our XHTML (which we're intentionally serving as text/html anyway)
isn't being parsed as XML.
> In fact I called for official discussion on this point, as well as a
> vote. That is the appropriate response to this sort of thing, and is
> in keeping with the spirit of the "Habari Way". What would you have
> liked to seen different?
If it comes down to a vote for HTML being the standard we adhere to,
then that's fine. I don't see a way to get to a vote when it's still
unclear what we're voting on or why.
(No ire is directed here - especially at you specifically, Chris -
just that you're easiest to reply to.)
Owen
Andrew Krespanis
> Maybe I'm confused: why do we have a cached_content field?
I'm quite out of touch with the codebase atm, and really should have
held back on my opinions until I had time to catch up...but I saw
debate going on that I wanted to contribute to, so I jumped in ;)
What's the cached_content field for? Is it to store post content after
it's been modified by plugins etc? If so, I stand by my original
suggestion -- I think there's value in having all posts stored in the
same format, HTML. Keep the text transforms at a single point (the
saving of a post) and most potential "is this pre-transform or
post-transform?" plugin development problems are negated.
Predictability rocks. Guesswork blows.
> > The option to convert to HTML should be there by default, as that
> > would be easy to call -- assuming all text transform plugins have a
> > predictable interface. (perhaps there should be a specific plugin
> > class that extends Plugin? or a different abstract class for text
> > transformation plugins?)
>
> Can you please elaborate a bit on this? I don't understand what you're
> suggesting.
Glad to.
Hypothetical: I blog for a couple of years using Textile formatting,
then decide that I want to abandon Textile and be able to edit my
posts as HTML. Habari could easily do this so long as the transform
plugins shared a common interface, as (roughly) demonstrated below:
interface iTextTransform
{
public function toHtml();
public function toOriginal();
}
class TransformMarkdown extends Plugin
implements iTextTransform
{
public function toHtml()
{
return $this->convertToHtml();
}
public function toOriginal()
{
return $this->convertHtmlToMarkdown();
}
}
Ok, that's a mess, but you get the idea.
It's understandable that users might want to convert Textile to
Markdown to Wiki format to what-ever-comes-next, but this is a
slippery slope for Habari to try and cover. From the get go, I think
we should provide HTML as the common ground and work from there.
Now, to try and formulate a response to the html vs. xhtml debate. *sigh* ;)
Andrew
--
http://leftjustified.net/
vkaryl
posts here. And linked info from that linked info. I don't have a
clear idea about any of this YET. I don't know that I ever will.
I have an opinion or so; feel free to ignore me of course.
First, some things I found in my foray into this on the 'net:
1. There's no absolute "thou shalt NOT" in the w3c information. In
fact, there's simply a "may" - which I take to mean "use xhtml 1.0
served as text/html if you want to, it's not going to hurt anything as
long as it fits under Appendix C". Further, that "may" is NOT
secondarily qualified by footnoting as to potential fires needing put
out or some possible breakage somewhere - other than "fitting under
Appendix C".
2. I found that there are several people who are quite outspoken on
regression to html 4.01 while there do not seem to be several people
who are quite outspoken in the other direction. I don't know that
that's compelling either way.
3. I found nothing setting out specific "borks" which "WILL ALWAYS
occur in X browser" if you serve xhtml 1.0 as text/html - and other
than the notation that if you do the wrong thing as far as well-formed
xml, browsers WILL throw a yellow-and-orange error page, not much
about xhtml 1.1 (not to say that it's not out there, just that with
all the seemingly millions of words I read, I didn't find it).
4. I spent a number of hours over a couple of days trying the various
solutions for serving "the correct mime type to most major browsers".
What I discovered (using these browsers: IE6, IE7, Opera 8.02, Opera
9.10, Firefox 2.0.0.1) -
A. I could get the correct mime type served to each of these
browsers on "plain" xhtml pages extensioned as .php
B. I could get the correct mime type served to each of these
browsers on php-extensioned dynamic pages (such as habari and wp
produce)
C. I could get the correct mime type served to every browser in
either of the above situations where inline javascripts (such as
AdSense) were also included on the pages, BUT the js would display
only in one sort of browser engine (and depending on certain tweaks
being made to the js): either the gecko engine would display them, or
the IE engine would display them. I'm sure there must be a way to
make them all work with js (because I visited sites where it's obvious
it works in all of them) - but I got to the point of thinking that if
it was that much work, it wasn't worth it (at least not for me; and I
can't visualize anyone I know who has blogs whether self-hosted or not
doing it either....)
Opinion: I stated earlier (not sure if it was in this thread or
elsewhere by now) that I believe those who choose at a future date to
use Habari as their blogging engine will expect to see xhtml, because
that's showing up on "the other guys". My guess is that if Habari
frames itself as "we're doing this the RIGHT way, html 4.01", people
will simply see that as saying "we're too lazy to figure out how to do
this in xhtml, html is good enough". People are people.... if
someone's looking at Habari instead of wp or whatever else, and Habari
is saying html 4.01 is the only way to go, they're not going to
believe it. And no, that's not a compelling reason either for using
xhtml I suppose. Of course, "simple bloggers" aren't going to know or
care as long as it works. (Until someone comes along and says, well,
Habari's still back in the dark ages of html, you know.... and some
WILL care about that. *shrug* Still not compelling really.)
Opinion: I think there will be those who may find it specious that
Habari sells itself as "cutting edge" due to the backend programs/
versions of same, but does not use xhtml.
Opinion: I really don't care what it's released as, I'm not
regressing to html 4.01 tagging. That's a personal choice, and I
don't need to justify it to anyone. I do my own themes and do not
produce themes for release, I can write them to whatever spec I
like....
I don't have a vote really, but my personal "voice" is -1 to html
4.01. I did more research than anyone else will probably do on this,
and I did not find one thing indicating to me that pages I create
using xhtml 1.0 will cause problems anywhere. No matter what mime
type they're served with. I found a lot of opinion.... and some of
that opinion was voiced by "high-powered" folks. Of which number I am
not one.
[Ugh. Excuse the length - I did just cut it down some.... *sigh*]
Doug Stewart
Here's my thinking on the issue:
XHTML, when properly formed, is an XML dialect. This allows for all
manner of machine-parsing coolness down the road. By insisting right
here, right now that code output by our systems validates as proper
XML, we can save ourselves the trouble of having to go back and revamp
everything in order to gain the machine parsing upsides.
If we enforce HTML 4.01 right now, there will be significant effort in
the future in order to gain back that XML-ness. Stick with it right
now and continue serving what amounts to really pretty HTML with
self-closing tags, IMNSHO.
--
-Doug
vkaryl
subject AFAIK.... sorry! If you want it changed back, Rich, fine by
me!
Doug Stewart
>
> Here's my thinking on the issue:
>
> XHTML, when properly formed, is an XML dialect. This allows for all
> manner of machine-parsing coolness down the road. By insisting right
> here, right now that code output by our systems validates as proper
> XML, we can save ourselves the trouble of having to go back and revamp
> everything in order to gain the machine parsing upsides.
>
> If we enforce HTML 4.01 right now, there will be significant effort in
> the future in order to gain back that XML-ness. Stick with it right
> now and continue serving what amounts to really pretty HTML with
> self-closing tags, IMNSHO.
>
Not to respond to myself, but, well, a welcome side-effect of ensuring
XML-ness is that, should the HTML 4.01 fans really and truly want to
display everything as HTML 4.01 Strict, they can simply take a pass at
the XML, run a few transforms and serve 4.01 to their hearts' content,
leaving the core data unmolested in the process.
--
-Doug
Andrew Krespanis
Firstly, are we talking front end or admin?
If we're talking front end, how about letting the theme set a
parameter for whether single tag elements should be self closing.
Plugins could then call a core method to return either ' />' or '>'
depending on what the theme is using.
This option has been my core concern all along. I hate that WP echoes
'<br />'. I also hate that 99% of plugins are written for XHTML.
Here's the patch to allow this and to allow themes to override it.
XHTML is true by default.
Index: /habari/htdocs/system/classes/theme.php
===================================================================
--- /habari/htdocs/system/classes/theme.php (revision 535)
+++ /habari/htdocs/system/classes/theme.php (working copy)
@@ -17,6 +17,7 @@
public $template_engine= null;
public $theme_dir= null;
public $config_vars= array();
+ public $is_xhtml = true;
/**
* Constructor for theme
@@ -143,6 +144,14 @@
{
$this->template_engine->assign( $key, $value );
}
+
+ /**
+ * Helps plugins remain compatible with HTML and XHTML themes
+ */
+ public function get_tag_end()
+ {
+ return ( $this->is_xhtml ) ? ' />' : '>';
+ }
}
?>
================ end patch ===================
As for the admin, I really don't have the energy to give a damn
anymore. Whichever way it goes, it would be nice to at least keep it
valid. One of the final straws with my growing tired of WP was
spending a pre-2.1 bug hunt session patching all the validity errors
in the WP admin. All the patches were commited. Wp2.1 was released a
few months later. Many validity bugs had been re-introduced in the
interim.
peace,
Andrew.
---
http://leftjustified.net/
vkaryl
XHTML"?
As far as front end or admin: I only address front end. Admin is
just "there" to me - it works (or not sometimes....) and while it
would be nice if I could easily theme it to match any given theme (so
that when I access admin it auto-pops the matching look to whatever
theme's on front-end right then) that's certainly not a necessity as
long as it works.
Themes are all I'm concerned with. I "tweak" php, js, vb etc., I
don't write code from scratch. So other than stating my pref re xhtml
over html (for themes), the rest of it's beyond my ken or input.
On Feb 22, 6:35 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
> This discussion is a complete mess.
>
> Firstly, are we talking front end or admin?
>
Andrew Krespanis
>
> Could you explain why you "hate that 99% of plugins are written for
> XHTML"?
Why should a plugin decide what output format I want?
--
http://leftjustified.net/
<layer src="ajax.shtml">I got your Web2.0 right here...</layer>
vkaryl
plugins I use don't "format" as such maybe?
On Feb 22, 7:39 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
wrote:
> On 2/23/07, vkaryl <vka...@bytehaven.com> wrote:
>
>
>
> > Could you explain why you "hate that 99% of plugins are written for
> > XHTML"?
>
> Why should a plugin decide what output format I want?
>
Doug Stewart
>
> On 2/23/07, vkaryl <vka...@bytehaven.com> wrote:
> >
> > Could you explain why you "hate that 99% of plugins are written for
> > XHTML"?
>
> Why should a plugin decide what output format I want?
>
Why would you use a plugin whose formatting you don't want?
I guess where you're driving is that Habari should have a portion of
the plugin API that allows plugins to specify what format their output
will take...?
--
-Doug
Andrew Krespanis
Hypothetical:
Blog user has an HTML theme.
Plugin writer makes a plugin that inserts a form into the theme.
Blog user installs said plugin.
Blog user's site now has invalid markup introduced by Plugin writer's
assumption that everyone wants to wear the "i use XHTML just because
it's newer and cooler and has an X in it" badge.
Blog user could modify the plugin, but then has to do so for every update.
Some might say "Why doesn't Blog user just upgrade to XHTML" (the
whole upgrade/regress side of this debate is f***ing infuriating. but
n/m that for now). But if it was the other way around, and Plugin
author dictated the use of HTML over XHTML, fanboys (and girls) would
shout form up high about "OMG!! You're so 1992! Get with the program!"
Well, it's wrong. Plugin author doesn't have any moral or technical
high ground to stand on and dictate one over the other. Neither does
Habari.
Now, if you'll excuse me, I've got some HTML 3.2 to write ;)
-Andrew
On 2/23/07, vkaryl <vka...@bytehaven.com> wrote:
>
> *confused* I'm sorry, I don't at all understand what you mean....
> plugins I use don't "format" as such maybe?
>
> On Feb 22, 7:39 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
> wrote:
> > On 2/23/07, vkaryl <vka...@bytehaven.com> wrote:
> >
> >
> >
> > > Could you explain why you "hate that 99% of plugins are written for
> > > XHTML"?
> >
> > Why should a plugin decide what output format I want?
> >
> > --http://leftjustified.net/
> > <layer src="ajax.shtml">I got your Web2.0 right here...</layer>
>
>
> >
>
--
vkaryl
thing.... or if I have, I presume I must have just fixed it validation-
wise without getting my knickers in a twist over it....
So I assume that Doug's question:
"I guess where you're driving is that Habari should have a portion of
the plugin API that allows plugins to specify what format their output
will take...?"
or something similar is what you think should happen with plugins/
themes specifically? And Habari overall? I'd go for that - that the
program itself would allow users to select which spec they wish to
use.
On Feb 22, 8:11 pm, "Andrew Krespanis" <leftjustif...@gmail.com>
Root
On Feb 23, 12:45 am, "Doug Stewart" <zamo...@gmail.com> wrote:
>
> Here's my thinking on the issue:
>
> XHTML, when properly formed, is an XML dialect. This allows for all
> manner of machine-parsing coolness down the road. By insisting right
> here, right now that code output by our systems validates as proper
> XML, we can save ourselves the trouble of having to go back and revamp
> everything in order to gain the machine parsing upsides.
>
> If we enforce HTML 4.01 right now, there will be significant effort in
> the future in order to gain back that XML-ness. Stick with it right
> now and continue serving what amounts to really pretty HTML with
> self-closing tags, IMNSHO.
>
Sorry to be terse but these are two dangerous myths unsupported - as
usual - with any supporting references. It is no more than ill
informed opinion wrapped in pseudo Alpha Geek wonkery. It does not cut
it.
Andrew Krespanis
> >
> Sorry to be terse but these are two dangerous myths unsupported - as
> usual - with any supporting references. It is no more than ill
> informed opinion wrapped in pseudo Alpha Geek wonkery. It does not cut
> it.
S**t, nice work. Way to make friends and influence people there dude.
Nothing like a direct insult to make people agree with your point.
Let me take a stab at interpreting what you said... (remember, I am on
your side, as the only person who has supported your original point
throughout this drawn out discussion ;)
> > XHTML, when properly formed, is an XML dialect.
The most important thing you said there is "when properly formed" -- I
still don't think many of the people who are in favor of XHTML and
think we can just "flick a switch" down the line fully understand what
this entails. (I'm certainly not assuming you don't, but I've seen
points put forward by core project members both in this thread and in
IRC that would indicate that is the case)
Firstly, there are only five named entities allowed in XML (as Chris
discovered when he "flicked the switch" on his site)
& &
' '
" "
< <
> >
Next up, there is the presence of external content. Trackbacks and
pingbacks being the most obvious. As Mark indicated, accurately
detecting (and then converting) the character encoding of these things
is a nightmarish undertaking. Habari would need to be able to handle
and convert to/from every character encoding out there... and then,
just when you think you've managed it (ignoring all the characters
that aren't available across various encodings), some freak will start
a blog in Klingon (which is NOT in utf-8, despite the myth) and bring
your house of cards tumbling to the ground. Luckily, your admin
control panel will be in HTML or incorrectly served XHTML, otherwise
you won't be able to fix the broken page without database access.
There are more points to go along with it, but I'm not going to spend
my night disseminating years of study for the sake of an argument that
I feel has already run its course.
I've got to be completely honest; this debate tires me, and I hereby
retire from it. The fact that so much detail has been required to
further educate the group as a whole as to what is involved in serving
XHTML properly does nothing more than convince me that it's an
undertaking not worth pursuing. Please, don't anyone take that as
insult, it's certainly not intended as any sort of "I know and you
don't, haha" or anything close to that sort of arrogant oneupmanship.
If the core group doesn't already get it, plugin authors will have a
harder time and theme authors will have a harder time again. (not the
theme authors who think of their markup as a work of art unto itself;
the ones who take their first steps in PHP by making a blog theme).
I think Habari has great potential, and I look forward to contributing
in any ways I can, but as a project it doesn't yet "get" XHTML.
peace,
Andrew.
--
http://leftjustified.net/
Doug Stewart
"Myths" - you keep using that word. I dinna think it means what you
think it means.
Well-formed, validating XHTML is XML, plain and simple. I defy you to
say otherwise. To wit, from http://www.w3.org/TR/xhtml1/#xhtml
=========
XHTML is a family of current and future document types and modules
that reproduce, subset, and extend HTML 4 [HTML4]. XHTML family
document types are XML based, and ultimately are designed to work in
conjunction with XML-based user agents. The details of this family and
its evolution are discussed in more detail in [XHTMLMOD].
XHTML 1.0 (this specification) is the first document type in the XHTML
family. It is a reformulation of the three HTML 4 document types as
applications of XML 1.0 [XML]. It is intended to be used as a language
for content that is both XML-conforming and, if some simple guidelines
are followed, operates in HTML 4 conforming user agents. Developers
who migrate their content to XHTML 1.0 will realize the following
benefits:
* XHTML documents are XML conforming. As such, they are readily
viewed, edited, and validated with standard XML tools.
* XHTML documents can be written to operate as well or better than
they did before in existing HTML 4-conforming user agents as well as
in new, XHTML 1.0 conforming user agents.
* XHTML documents can utilize applications (e.g. scripts and
applets) that rely upon either the HTML Document Object Model or the
XML Document Object Model [DOM].
* As the XHTML family evolves, documents conforming to XHTML 1.0
will be more likely to interoperate within and among various XHTML
environments.
The XHTML family is the next step in the evolution of the Internet. By
migrating to XHTML today, content developers can enter the XML world
with all of its attendant benefits, while still remaining confident in
their content's backward and future compatibility.
================
Let's talk migration down the road, "Root". (That high-n-mighty
moniker has always bothered me, by the way. Why not "uid0"?) What
happens when Habari decides to store all content to the database in
HTML 4.01-conformant format and then, some time down the road, it's
decided that SGML just isn't cutting it and a real, human-readable,
self-describing data set is needed. Think of the effort that will be
required to go back and re-parse all your old content *that isn't
guaranteed to validate*.
If people are free to toss <p>s and <li>s and <LI>s about without
corresponding </p>s, etc., then the job of a parser down the road
becomes that much more nightmarish. However, if we enforce proper
storage of well-formed and valid XML right now, you HTML-4.01ers with
your tails in a twist can simply add an additional filter to your
Habari output buffers and have it render 4.01 to your heart's content
*using existing XML tools*. What happens on the reverse, if some
unlucky sap wants to take your 4.01 and transform it to proper XHTML
on-the-fly? /me shudders and quietly bangs his head against the
table.
Let's face it: a lot of this discussion boils down to the fact that IE
is stupid and simply won't handle XHTML when served with a non
text/html MIMEtype. I'm not a Microsoft coder, thus I have no ability
to influence their codebase, but I do think that continuing to make up
for IE's shortcomings is simply madness. Death to "quirks mode" and
The Marquis de Sade's Favorite Box Model!
--
-Doug
Root
On Feb 23, 12:07 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
> On 2/23/07, Root <atthe...@gmail.com> wrote:
>
>
If anyone is just joining this thread and is reading beyond this point
they should realise that the serious participants have already quit.
We are exhausted.
Root
you thought of it first. Troll on.....
Doug Stewart
Nice.
You still haven't answered why valid, well-formed XML data is a bad
thing. Your constant appeals to authority (AFTER claiming you were
fed up with Google and were taking your marbles and going home) are
really, truly tiresome.
So sorry that we hoi polloi "tire" you wise sages. Must be nice up
there on HTML Olympus.
--
-Doug
Doug Stewart
That last reply of mine was offsides. I've taken that portion of the
discussion off-list. Apologies to the rest of you that simply want to
hash these things out.
Perhaps position papers (or wiki entries) ought to be established so
that anyone interested in making a decision when the eventual vote
comes up can have a one-stop-shop on the X/HTML debate.
--
-Doug
Andrew Krespanis
> thing.
It's a wonderous thing. Actually achieving it will pretty much result
in a whole new way of designing and building themes, and will raise
the bar for involvement in a big way. Probably not a real popular
approach.
> So sorry that we hoi polloi "tire" you wise sages. Must be nice up
> there on HTML Olympus.
I assume by the plural form of "sages" you're including more than just
Root with that attack.
Chill dude, I'm not here to have a flame war. IRC muskets at dawn? ;)
http://wiki.habariproject.org/en/XHTML_vs_HTML
-Andrew
--
http://leftjustified.net/
Doug Stewart
>
> On 2/23/07, Doug Stewart <zam...@gmail.com> wrote:
> > You still haven't answered why valid, well-formed XML data is a bad
> > thing.
>
> It's a wonderous thing. Actually achieving it will pretty much result
> in a whole new way of designing and building themes, and will raise
> the bar for involvement in a big way. Probably not a real popular
> approach.
>
Now you've lost me. Sounds like you're advocating XHTML here.
> > So sorry that we hoi polloi "tire" you wise sages. Must be nice up
> > there on HTML Olympus.
>
> I assume by the plural form of "sages" you're including more than just
> Root with that attack.
>
No, he was lumping you in with himself as one of the "tired" sages.
My vitriol was intended for him and him alone.
> Chill dude, I'm not here to have a flame war. IRC muskets at dawn? ;)
>
I'll bring my ROFLCopter.
> http://wiki.habariproject.org/en/XHTML_vs_HTML
>
>
> -Andrew
> --
> http://leftjustified.net/
>
> >
>
--
-Doug
Scott Merrill
> Perhaps position papers (or wiki entries) ought to be established so
> that anyone interested in making a decision when the eventual vote
> comes up can have a one-stop-shop on the X/HTML debate.
I am not an expert on any of this. I have not thoroughly read all of
the links that have been posted thus far. I'm sorry that I don't have a
specific opinion to advance in this discussion. I appreciate all of the
information that has been shared to date, and I look forward to reaching
a consensus eventually.
My understanding of this debate is that there are two sides:
1) Serving XHTML as text/html doesn't _really_ break anything, so what's
the big deal? It gets us some groovy possibilities in a few years time.
2) Serving XHTML as text/html doesn't really break anything, but it's
not the correct way to do it.
Habari places a certain barrier to entry on participants. We require
PHP5 because we want to use PDO for (some) database independence. We
require a new-ish version of MySQL so that we can take advantages of
features present in that version. These -- and more -- are specific
examples where technology decisions were made because they provide a
demonstrable benefit to us the developers, which in turn produces
demonstrable benefit to our end users.
What's the demonstrable benefit to using XHTML (served as text/html)?
Is there one? I'm not entirely sold on Doug Stewart's claims of future
conversion to some new markup, though I recognize that none know what
the future holds. It's also possible that a decent (or at least
sufficient) HTML-to-new-markup conversion tool will be developed in that
future, as well.
Is there a distinct advantage of XHTML (served as text/html) over plain
ol' HTML, other than the fact that the former is newer?
In many instances of the code so far, folks have stood up to say "Yes,
you can do it that way, but that's not the right way." We try hard in
the code to do things "the right way" as much as possible. Is there a
reason we're willing to say "Yeah, so XHTML served as text/html isn't
the right way, but who cares? It works!" ?
Andrew Krespanis
> Now you've lost me. Sounds like you're advocating XHTML here.
we choose correctly. And as gnsedders kindly reminded me in #habari,
XHTML 1.0 Spec appendix C is non-nomnitive. So really, leaning on
that whole "MAY" crutch is getting a bit old-- lets try and get apst
that, eh? :)
If you take a look at my first post in this thread --
http://groups.google.com/group/habari-dev/msg/29c6e99e416bc61b --
you'll see that I started on the pro-XHTML (as XML) bandwagon. You,
Doug, seem to be the only other person strongly in favour of that
route. After further investigation into some of the pain and suffering
enforcing valid, well formed, correctly encoded XML would result in, I
pretty much walked away form pushing that point and took the side of
"well, if we can't ensure it's correct XML, can we at least use an
SGML doctype?". I apologize for the confusion my change of stance may
have caused. I know it took a bit of explaining in IRC today as to why
I seemed to be making conflicting points throughout the lifespan of
this discussion.
> I'll bring my ROFLCopter.
Let me guess... it's an Apache? (oh man, that was TOO lame. sorry!)
Andrew
--
http://leftjustified.net/
Chris J Davis
comments were well said.
Chris
Geoffrey Sneddon
On 23 Feb 2007, at 13:16, Andrew Krespanis wrote:
>
> On 2/24/07, Doug Stewart <zam...@gmail.com> wrote:
>> Now you've lost me. Sounds like you're advocating XHTML here.
> I really should clear that up. I'm advocating serving whatever doctype
> we choose correctly. And as gnsedders kindly reminded me in #habari,
> XHTML 1.0 Spec appendix C is non-nomnitive. So really, leaning on
> that whole "MAY" crutch is getting a bit old-- lets try and get apst
> that, eh? :)
To say more of what I told Andrew in IRC, there is _absolutely no_
nominative specification allowing XHTML as text/html. Any standards
compliant UA will enter a NET tag section, as per SHORTTAG constructs
(the forward slash enters you into an NET tag section, and everything
up until the following forward slash is the content of that element).
e.g. <p><img src="test.gif" />test<img src="test2.gif" /></p>
Will produce an <img> with the contents of: >test<img
src="test2.gif" (which is then followed by a greater than sign).
The only specification that allows empty elements to have a closing
slash is Web Applications 1.0 (HTML5), which moves away from HTML's
SGML roots.
>
> If you take a look at my first post in this thread --
> http://groups.google.com/group/habari-dev/msg/29c6e99e416bc61b --
> you'll see that I started on the pro-XHTML (as XML) bandwagon. You,
> Doug, seem to be the only other person strongly in favour of that
> route. After further investigation into some of the pain and suffering
> enforcing valid, well formed, correctly encoded XML would result in, I
> pretty much walked away form pushing that point and took the side of
> "well, if we can't ensure it's correct XML, can we at least use an
> SGML doctype?". I apologize for the confusion my change of stance may
> have caused. I know it took a bit of explaining in IRC today as to why
> I seemed to be making conflicting points throughout the lifespan of
> this discussion.
It isn't actually that hard to enforce well formed and correctly
encoded XML (although validity is hard, but there is only one major
validating XML parser: Trident (that's the rendering engine in IE/
Win, for those who don't know). The XHTML 1.1 DTD is actually
invalid, so any validating parser MUST throw a fatal error, without
even starting on the document itself.).
If we really want to build a blog system with no bars held back,
doing it as specifications say we should, we CANNOT use XHTML text/
html, as there is NO nominative specification making this legal. If
we do want to use XHTML we MUST use an XML MIME type (application/
xhtml+xml, application+xml, or text/xml, baring in mind with the
latter that there is only one source of the encoding: the MIME type
sent over the transport protocol, and that we default to US-ASCII).
On 23 Feb 2007, at 12:07, Doug Stewart wrote:
> Let's talk migration down the road, "Root". (That high-n-mighty
> moniker has always bothered me, by the way. Why not "uid0"?) What
> happens when Habari decides to store all content to the database in
> HTML 4.01-conformant format and then, some time down the road, it's
> decided that SGML just isn't cutting it and a real, human-readable,
> self-describing data set is needed. Think of the effort that will be
> required to go back and re-parse all your old content *that isn't
> guaranteed to validate*.
Neither is XHTML content. As I've mentioned, the only major
validating XML parser Trident, and the XHTML 1.1 DTD is invalid.
Under the XML specification, we [parsers] are no required to validate
the content, only ensure that it is well-formed.
> If people are free to toss <p>s and <li>s and <LI>s about without
> corresponding </p>s, etc., then the job of a parser down the road
> becomes that much more nightmarish. However, if we enforce proper
> storage of well-formed and valid XML right now, you HTML-4.01ers with
> your tails in a twist can simply add an additional filter to your
> Habari output buffers and have it render 4.01 to your heart's content
> *using existing XML tools*. What happens on the reverse, if some
> unlucky sap wants to take your 4.01 and transform it to proper XHTML
> on-the-fly? /me shudders and quietly bangs his head against the
> table.
There is a large number of undocumented differences between XHTML and
HTML. It isn't that easy to switch between the two. In fact, it's
probably just as hard to go from XHTML to HTML as it is the other way
around.
In summary,
- We CANNOT use XHTML as text/html, as there is ABSOLUTELY no
nominative specification saying that's legal.
- We CAN use XHTML as an XML MIME type (preferably with an XML
serialiser to ensure it's well-formed, and not just treat XHTML as a
text format).
- We CAN use HTML as text/html, with only the misinformed
complaining (with XHTML as text/html anyone who knows how the web
works, and cares about standards, will complain).
- Geoffrey Sneddon
Owen Winkler
>
> Is there a distinct advantage of XHTML (served as text/html) over plain
> ol' HTML, other than the fact that the former is newer?
Three things off the top of my head:
1) It may not strictly be well-formed XML, but it's closer to it than HTML.
2) The perception that XHTML is "better" than HTML, however
unfortunate, is a factor, as well as the idea of its ubiquity.
3) It appeals to my sensibilities as a programmer to require closing
tags everywhere, and to use the shortcut self-closing tags.
Trivial, perhaps. But it's interesting to weigh these things against
the perceived drawbacks of XHTML.
Let me provide, briefly, what I understand as the opposition to XHTML:
To serve XHTML, the markup must be well-formed XML. Although this is
possible, it is perceived as more difficult to achieve due to
differences in handling of entities between HTML and XML, markup of
posts (Markdown? Raw (X)HTML?), and external influences like
trackbacks and pingbacks.
We must assume that producing well-formed XML is impractical to
continue. If it is "easy" to produce valid XML, then we should stop
here and settle on the idea that Habari will aim to produce
well-formed XHTML (XML), because overall, the results will be better;
setting a standard for any other tool that produces web output.
Continuing with the assumption that we can't guarantee well-formed XML
output, we should not serve our markup as application/xml of any
variant, because nothing would be able to render it. XML parsers
would find the invalid markup and choke on our output. This is not an
effect that we desire.
We could output with text/html, because the W3C says that we "MAY" do
so. What happens at this point is the core subject of the debate, I
think.
If we tell a browser that we're serving text/html, we should provide
the browser with valid HTML markup. If we include XHTML-like tags
(self-closing tags, for example) then we are not providing valid HTML.
I think that Habari should make every effort to produce valid markup
for what output type it says it is outputting. If we say we're
outputting text/html, then we should output valid HTML. If we say
we're outputting application/xhtml+xml, then we should output valid
XHTML/XML.
If by producing XHTML markup for a text/html mimetype, we are not
conforming to the specifications of what a browser should render, then
we should not output XHTML markup, but instead choose something for
which we can produce both the correct mimetype and markup.
My question at this point is very academic: If the W3C says that it's
ok to serve XHTML markup as text/html, then why do browsers render it?
Is it because they're being accommodating of poorly-written HTML, or
is it because they're abiding by the W3C recommendations that say they
may handle this markup under this mimetype?
If you're not supposed to do this, then why does XHTML markup served
under the text/html mimetype validate? Or does it?
Other examples of using XHTML where the markup is invalid when parsed
as HTML would be helpful for demonstration.
Owen
Geoffrey Sneddon
On 23 Feb 2007, at 17:12, Owen Winkler wrote:
> I think that Habari should make every effort to produce valid markup
> for what output type it says it is outputting. If we say we're
> outputting text/html, then we should output valid HTML. If we say
> we're outputting application/xhtml+xml, then we should output valid
> XHTML/XML.
Agreed. We should produce what we claim.
>
> My question at this point is very academic: If the W3C says that it's
> ok to serve XHTML markup as text/html, then why do browsers render it?
> Is it because they're being accommodating of poorly-written HTML, or
> is it because they're abiding by the W3C recommendations that say they
> may handle this markup under this mimetype?
The W3C (specifically the HTML WG) informally says it is all right,
that is correct. The reason why UAs display it as the author intended
is because they are accommodating invalid HTML (if any UA actually
followed the spec 98% of the web wouldn't work at all).
>
> If you're not supposed to do this, then why does XHTML markup served
> under the text/html mimetype validate? Or does it?
It doesn't validate under any nominative specification, only under
non-nominative sections of specifications.
- Geoffrey Sneddon
Owen Winkler
mimetype for the theme with the default of text/html which will still
"work" if your theme chooses to output XHTML on that mimetype.
Owen
Root
On Feb 23, 12:45 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
> On 2/23/07, Doug Stewart <zamo...@gmail.com> wrote:
>
>
>
> > On 2/23/07, Root <atthe...@gmail.com> wrote:
>
> > > On Feb 23, 12:07 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
> > > > On 2/23/07, Root <atthe...@gmail.com> wrote:
>
> > > If anyone is just joining this thread and is reading beyond this point
> > > they should realise that the serious participants have already quit.
> > > We are exhausted.
>
Sending your childish personalised abuse to me by email doesn't
legitimise it just because it is off list.
Reply to author is not a license for nutters.
Doug Stewart
>
>
>
> On Feb 23, 12:45 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
> > On 2/23/07, Doug Stewart <zamo...@gmail.com> wrote:
> >
> >
> >
> > > On 2/23/07, Root <atthe...@gmail.com> wrote:
> >
> > > > On Feb 23, 12:07 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
> > > > > On 2/23/07, Root <atthe...@gmail.com> wrote:
> >
> > > > If anyone is just joining this thread and is reading beyond this point
> > > > they should realise that the serious participants have already quit.
> > > > We are exhausted.
> >
>
> Sending your childish personalised abuse to me by email doesn't
> legitimise it just because it is off list.
> Reply to author is not a license for nutters.
You, sir, have problems. Stand down on-list and abuse me as you will
on my own account. The rest of the list doesn't need to read it.
--
-Doug
Matthias Bauer
> I assume self-closing tags are out when using HTML 4.01? That sucks.
Self-closing tags are unneeded when using HTML 4.01. The elements are
marked #EMPTY; they don't need and indeed must never have a closing tag.
> The W3C recommendations allow us to serve XHTML as text/html - why should we not?
'XHTML Documents which follow the guidelines set forth in Appendix C,
"HTML Compatibility Guidelines" may be labeled with the Internet Media
Type "text/html" [RFC2854], as they are compatible with most HTML browsers.'
Basically, it's "write peculiar XHTML and pray you don't meet a proper
SGML parser". It relies on the tag-soup parsing of many current HTML
user agents, the only reason that things like '<br />' "work" when
served as text/html. If a real {SGML,HTML} parser were to have at that,
the result would be '<br>>', e.g. an empty BR tag, and a literal
greater-than char, because the br/ would be treated as a
Null-End-Tag-enabling start tag, thus '<br /' is equivalent to '<br>',
and the following '>' is just a character that is not part of the markup.
So, while Section 5.1 of the XHTML 1.0 spec seems to imply that
'HTML-compatible XHTML documents' were *valid* HTML documents, it
doesn't *actually* say that, and it's not true.
> Why should we convert our markup entirely to HTML and serve it as text/HTML?
> For what benefit?
Standards-compliance.
-Matt