I'm in the process of setting up my own website, but was disappointed that OWB always crashed when trying to access the website. After switching my site from using XHTML to pure HTML, OWB could suddenly view the site without trouble.
Here is a similar website that causes OWB to crash. It also uses XHTML. So XHTML pages seem to be problematic.
To help the Amiga OS OWB port developers squash this bug, it might help if people check whether pages are XHTML and post which ones do and don't work here. If we can narrow down what causes the crash to specific content then finging and fixing the problem should be much easier. It would also be interesting to know if OWB on other platforms also have trouble with those pages.
You can recognize XTML pages because they start with an xml tag. Usually there's an xml tag followed be a doctype tag, and then an html tag.
So it has a tag missing the "/". Still, OWB shouldn't crash, even on sites with errors in the markup.
Hans
This is correct, of course. But more interesting: Did you now try fixing your markup problem and see whether OWB stops crashing?
If so, we have at least established that XHTML pages are not problematic for OWB, only buggy XHTML pages -- which is of course still an OWB bug.
Best regards,
Niels
I can't fix the markup. The site that I linked to isn't mine. Even with my site, fixing the errors that the validator lists is too much effort. My site contains various inserts (e.g., clustr-maps) that the w3 validator doesn't like. It also complains about markup generated by TinyMCE, the CMS page editor that I'm using. For example, it complains about the align="justify" attribute that TinyMCE uses to format paragraphs. Nevertheless, all browsers that I've tried correctly interpret this attribute. I'm starting to wonder how valid the w3 validator is.
Finally, XHTML is not supported properly by browsers. For example, Firefox 2 doesn't support Javascript's Document.write() method with XHTML pages. Google's services tend to use these, causing Firefox to render pages incorrectly. I've decided to stick to plain HTML.
I can't fix the markup. The site that I linked to isn't mine.
Pity. Couldn't you just make a copy of the page locally, fix the missing end tag in that and see how OWB reacts? Quote:
Even with my site, fixing the errors that the validator lists is too much effort. My site contains various inserts (e.g., clustr-maps) that the w3 validator doesn't like. It also complains about markup generated by TinyMCE, the CMS page editor that I'm using. For example, it complains about the align="justify" attribute that TinyMCE uses to format paragraphs. Nevertheless, all browsers that I've tried correctly interpret this attribute. I'm starting to wonder how valid the w3 validator is.
In general, I would trust the W3C validator over *any* tool, with the possible exception of a plain text editor combined with the official specs. Are you sure that attribute you mention is actually corretly used according to the XHTML standard and the DTD the page refers to? Quote:
Finally, XHTML is not supported properly by browsers. For example, Firefox 2 doesn't support Javascript's Document.write() method with XHTML pages. Google's services tend to use these, causing Firefox to render pages incorrectly. I've decided to stick to plain HTML.
Document.write() is not part of the XHTML standard, it's part of DOM (AFAIK). I think the real issue is that the HTML standards are much more loose/forgiving on many points than XHTML, so a lot of markup slack is not caught when using plain old HTML as the yardstick.
I can't fix the markup. The site that I linked to isn't mine.
Pity. Couldn't you just make a copy of the page locally, fix the missing end tag in that and see how OWB reacts?
I might try that.
Quote:
In general, I would trust the W3C validator over *any* tool, with the possible exception of a plain text editor combined with the official specs. Are you sure that attribute you mention is actually corretly used according to the XHTML standard and the DTD the page refers to?
I have no idea as I know very little about web standards (not my area of expertise). All I can say is that every browser that I tried supports this attribute and renders the text the same way. Seeing as all browsers support it, it might as well be in the spec.
Quote:
Document.write() is not part of the XHTML standard, it's part of DOM (AFAIK). I think the real issue is that the HTML standards are much more loose/forgiving on many points than XHTML, so a lot of markup slack is not caught when using plain old HTML as the yardstick.
The problem is that Google Adsense and Analytics depend on it. IE7 supports it, but not Firefox 2. Apparently Opera may also not support this method. Having to implement browser-specific workarounds is a real pain.
I'm hoping that others will take a closer look at XHTML pages and OWB as well.
Also you might want to have a look at HTML-Kit as an HTML editor (and more)... Even if it's on windows, I find it really good as it doesn't "bloat" your code with unnecessary crp (like Dreamweaver, Ultradev, Frontpage and the likes !).
Jerry
Defender of my A1XE-G4 / AOS4 Final Update ! Looking for a new toy ? Then try a GP2X...
Also you might want to have a look at HTML-Kit as an HTML editor (and more)... Even if it's on windows, I find it really good as it doesn't "bloat" your code with unnecessary crp (like Dreamweaver, Ultradev, Frontpage and the likes !).
Jerry
The CMS that I use has a built in editor called TinyMCE that almost works properly in OWB. The code that it generates looks pretty compact, and with a little more development, OWB should be able to use it perfectly.
The site that I linked to in my first post is a demo of the CMS. You can log in to their admin pages to see what it looks like.
Here is a similar website that causes OWB to crash.
Although the main site doesn't crash with OWB Blastoise on Linux for example http://demo.silverstripe.com/admin/ crashes on Linux as well. It works with OWB Doduo (on Linux, I did't manage to build a working AmigaOS4 executable yet).
I have no idea as I know very little about web standards (not my area of expertise). All I can say is that every browser that I tried supports this attribute and renders the text the same way. Seeing as all browsers support it, it might as well be in the spec.
I've been away from the thread for some days, but this one just caught my eye and forced me to comment again.
IMHO, standards like those from the W3C are not supposed to be descriptive, but normative. Given that, you're almost saying the equivalent to: Since all cars can kill people when hitting them, this might as well be part of the requirements to the car makers.
I have no idea as I know very little about web standards (not my area of expertise). All I can say is that every browser that I tried supports this attribute and renders the text the same way. Seeing as all browsers support it, it might as well be in the spec.
I've been away from the thread for some days, but this one just caught my eye and forced me to comment again.
IMHO, standards like those from the W3C are not supposed to be descriptive, but normative. Given that, you're almost saying the equivalent to: Since all cars can kill people when hitting them, this might as well be part of the requirements to the car makers.
Sorry, but that just doesn't work. The browsers have all been designed to support the attribute in question, in the manner that it's being used. A car, on the other hand, hasn't been designed to kill people. The browser has to be written specifically to support the attribute; whereas, the car doesn't need to be designed to kill people in order for it to be able to do so.
I see two possibilities; either it's in the spec, and the w3c validator is wrong, or, it's a "non-standard" extension that everyone supports.
nbache wrote: @Hans IMHO, standards like those from the W3C are not supposed to be descriptive, but normative. Given that, you're almost saying the equivalent to: Since all cars can kill people when hitting them, this might as well be part of the requirements to the car makers.
Sorry, but that just doesn't work. The browsers have all been designed to support the attribute in question, in the manner that it's being used. A car, on the other hand, hasn't been designed to kill people. The browser has to be written specifically to support the attribute; whereas, the car doesn't need to be designed to kill people in order for it to be able to do so.
Okay, I admit, the example might not be the best one (but a car analogy is obligatory in debates like this one, you know ).
My point was that since the W3C spec is "the law" (it's a normative specification), anything some - or even many - browsers choose to support which is not prescribed therein is their own responsibility, and it is only fair if usage of such features is pointed out by the official tool for checking conformance to the specification.
Demanding that such features are accepted by the validator is equivalent to demanding that they should be part of the standard, and that is only for the legislative body (in this case W3C) to decide.
Quote:
I see two possibilities; either it's in the spec, and the w3c validator is wrong, or, it's a "non-standard" extension that everyone supports.
I see a third possibility: Your tool uses it incorrectly, which is pointed out by the validator, but not incorrectly enough for all those browsers out there to fail to "support" it.
If I understand you correctly, we are talking about the align="justify" attribute to the <p> tag, right?
Like this:
<p align="justify"> Some text. </p>
I have just tested adding it to one of my own pages, and it validates fine. (If you don't believe me, here's the page I used, try it yourself: http://nielsogjette.dk/tindex.html - just click the W3C icon on the page to invoke the validator on it).
Can you show me the page where that was rejected? Maybe I can figure out what is wrong with it.
I just figured out why I'm getting the error, and you aren't. The doctype for my page is set to HTML 4.01 strict, not loose. The problem is, even if I try to specify loose in the template, the CMS changes is back to strict.
I just figured out why I'm getting the error, and you aren't. The doctype for my page is set to HTML 4.01 strict, not loose.
Right, that must be it. If I force the validator to revalidate my page as strict XHTML, I also get that error (and a few others like it, e.g. for border and bgcolor). To remain compatible to current Amiga browsers, we have to stay with the transitional DTD, as the strict one requires the use of CSS (defined or inline styles) instead of most of those attributes.
Quote:
The problem is, even if I try to specify loose in the template, the CMS changes is back to strict.
Don't you just hate tools that think they know better? Maybe you can get away with changing the doctype of the resulting html file after saving it from the tool.
Quote:
Seeing as it works, I'll just leave it as-is.
That's of course always a way out . But at least we found out that it wasn't some previously unfound bug in the validator (which was why I wanted to investigate further).
The problem is, even if I try to specify loose in the template, the CMS changes is back to strict.
Don't you just hate tools that think they know better? Maybe you can get away with changing the doctype of the resulting html file after saving it from the tool.
It's a PHP-based CMS. I could of-course look through the source to find and change the offending code, but, I'm not familiar with PHP and I have more than enough other things to do.
Quote:
Seeing as it works, I'll just leave it as-is.
That's of course always a way out . But at least we found out that it wasn't some previously unfound bug in the validator (which was why I wanted to investigate further).[/quote]
Absolutely, thanks for your help. I know that fixing it would be the best solution, but I really want to focus on my own projects. I'm not a web designer.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
p (like Dreamweaver, Ultradev, Frontpage and the likes !).
