XTHML/PHP Editor

Radon3k

Is there an HTML editor (hopefully that supports PHP) that will automatically put things in XHTML compliance for you? I'm using Dreamweaver now and it's getting on my nerves. I'm spending more time modifying the pre-written code than I am writing the back-end code. What I mean by XTML compliant is for example in Dreamweaver when you go to File --> New you can choose to make it XHTML compliant so a lot of the code to make it be XTML is there (As in the DOCTYPE for example). Thanks. 🙂

Mordecai

First off, it's XHTML. Secondly, it's useless, but that's no matter.

Try using PHPEdit, it can handle just about anything you throw at it.

Radon3k

oops, sorry about that. I know it's XHTML but I mis-typed. Why is it useless? The link isn't working. Maybe the site is down.

Mordecai

Yeah, the site's down.

Umm, how does adding a slash to some tags make something more "compliant," when the language it was intended for is much, much older and more renowned (the latter of course is just superfluous information, however)? Tell me how one of these will run any better:
<img src="myimage.jpg"> - HTML
<img src="myimage.jpg" /> - XHTML

The first will run faster since the interpreting engine (the browser) will not have to parse the "/."

Radon3k

I didn't think of it like that. Thanks for the insight. 🙂 Would standard HTML compliancy work then? 😉

Mordecai

HTML is much better for a standard. (I almost typed butter, good thing I caught that.)

Radon3k

That makes sense. Having said that, I'm not sure what editor I choose then. Do you do all of your coding by hand or by a visual program such as Dreamweaver?

Mordecai

I use PHPEdit, it's great. A bunch of bugs, though... My buttons are in French.

Radon3k

Yes, that's why I didn't use it, was because the buttons were in French. I thought I had downloaded it before, it sounded familiar. The screen shot made it click in my head. I think I'll give AnyEdit a try.

Weedpacket

Originally posted by Mordecai
Umm, how does adding a slash to some tags make something more "compliant," when the language it was intended for is much, much older and more renowned (the latter of course is just superfluous information, however)?

Well the "compliance" is to XML instead of SGML. Anyone (apart from seriously large corporations) use SGML? It means only needing an XML parser, not an XML parser and an HTML parser. I can see savings there.

That's pretty much it.

jstarkey

Originally posted by Mordecai
Yeah, the site's down.

Umm, how does adding a slash to some tags make something more "compliant," when the language it was intended for is much, much older and more renowned (the latter of course is just superfluous information, however)? Tell me how one of these will run any better:
<img src="myimage.jpg"> - HTML
<img src="myimage.jpg" /> - XHTML

The first will run faster since the interpreting engine (the browser) will not have to parse the "/."

That's incorrect. The / closes the tag so now it no longer has to look for a close (when in compliant mode, not quirks mode). View info on this page and you'll see that it's in quirks mode which means the browser is second guessing every tag is sees, knowing that the developer is allowed to make mistakes because the browser probably knows how to correct them.

In XHTML it knows that the code is correct so up to 11 correction libraries are not needed by the browser. It parses much, much faster. In most cases you won't even see the page being built. It just appears. Try it sometime on a complex, table-heavy page.

Then there's the issue that the browser manufacturers agreed back in 2000 to phase out HTML. The parsing engines are all going to be moved to parsing XML and no longer HTML. This means that in the coming years, any HTML page you have will need to be converted to a compliant (wellformed) langauge -- XML.

Radon, Bluefish is also a good editor that supports PHP. They started supporting XHTML years ago, so it's matured. I've been mirroring it for around 2 years ago and the dev list is extremely active. They're very on top of the development.

Dreamweaver does the same.

barand

Originally posted by Mordecai

The first will run faster since the interpreting engine (the browser) will not have to parse the "/."

Why? Now it knows it doesn't have to look for a </img> tag.

Mordecai

Originally posted by barand
Why? Now it knows it doesn't have to look for a </img> tag.

That's what jstarkey said--however, the browser should know there is no </img>. It probably has a list of tags that are required to be ended, and tags that are single.

Weedpacket

XHTML compliance goes a bit further than just /> (ah, so having two lists to look through is faster than having one?). Tags names and attributes are lower case, attribute values must be quoted (either ' or "); closing tags are no longer optional, and so on.

There's a chapter in the XHTML spec that lists the differences between it and HTML. They all contribute to making the syntax more rigid, with fewer "oh I don't feel like doing that today" bits. More rigid syntax makes for leaner parsers (that, not incidentally, are easier to write). Leaner parsers makes for faster parsing.

Mordecai

I suppose it has its benefits, but it's still rather useless in my opinion--why rewrite something that already works (and is used by millions)?

And whether or not two lists are faster than one, it all depends on how well it's programmed and how long the lists are. So there's no real way of telling. I suppose that since, theoretically, they all have the same number of tags, looking through only one list would be faster.

goldbug

Remember that its not actually XHTML unless the proper MIME type is passed to the browser. Too bad IE can't stomach the "proper" MIME type. (tries to download it) 🙂

Its 'application/xhtml+xml' not 'text/html' for those wondering.

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#media-types

goldbug

Originally posted by Weedpacket
There's a chapter in the XHTML spec that lists the differences between it and HTML. They all contribute to making the syntax more rigid, with fewer "oh I don't feel like doing that today" bits. More rigid syntax makes for leaner parsers (that, not incidentally, are easier to write). Leaner parsers makes for faster parsing.

It also enforces a much more standardized markup, which is a good thing ((TM), Martha Stewart). I don't know about you guys, but I hate editing pages that have sloppy markup all over (no ending </p>, no alt attributes in image tags, attribute values not quoted all the time, etc...)
And I'll just chill about the (bad) use of alt="" attributes for tooltips, for now 🙂

jstarkey

Originally posted by Mordecai
I suppose it has its benefits, but it's still rather useless in my opinion--why rewrite something that already works (and is used by millions)?

HTML is very broken. Can you imagine how slow the web would be if apache corrected everyone's PHP code? How much more RAM and CPU every server would require? We'd have a lot more PHP devs in the world, but the language would mature a half the rate it currently is, while the apache foundation spent years trying to perfect their correction libraries.

I can't even begin to guess how many lines of regexp it takes to correct html pages. How about code to determine when and where to put a missing /tr? Now, to do that reliably across 10 million pages? When all it takes is for HTML to join the rest of the world and require that it be coded correctly.

stolzyboy

Originally posted by jstarkey
When all it takes is for HTML to join the rest of the world and require that it be coded correctly.

Ooorah! John! Well said!

Mordecai

Originally posted by jstarkey
When all it takes is for HTML to join the rest of the world and require that it be coded correctly.

I'd be fine with that if they did it in the first place. 🙂

I guess I just don't like change...