Thread: Anyone purely self-taught?

We can probably agree a complete, bounded, definition is not possible. I agree with your description. But it still leaves room for debate.

I've been faced with computational problems when writing HTML many times before; The HTML <link> tag is used to define the relationship between two documents. They are needed for many things; to have the browser display an icon on the address bar; to define what device a document should be displayed on (handheld, tty, print, braille, aural, ...), to define content-types and charsets, to include stylesheets.

HTML sole purpose in life is to provide content with new and correct semantics in the context of the parser used to interpret it. In this context how can anyone think of it as a programming language? However, tags like <div> and <span> take the markup to a new higher level in which it is possible to define our own new semantic tokens and attribute them to the content. The decision to do so, or not, coupled with how and where it should be done, is largely based on our knowledge of the browser rendering engine (the HTML "compiler") and the need or not alter how the content is to be rendered. This is too solving a computational problem.

For this reason I'll end the way I started; We can probably agree a complete, bounded, definition of what is a Programming Language is not possible anymore. It becomes easier today to say what is not a programming language, than to say what it is.

I do agree HTML is not a programming language. But that is mostly based on my own (at the present time and probably skewed) view of what one should be. And that always includes a compiler or interpreter and the ability to perform the following operation x + y. Other may not agree. And they will be as right.

Originally Posted by mike_g

Fair enough dreamweaver cost an arm and a leg plus a kidney or two, but the product is less likely to have errors in it than something hand coded and it make a job as an HTML coder kind of obsolete.

I would say HTML WYSIWYG editors are the main responsible for the general feeling W3C has been talking to brick walls all this time.

It you want standards compliance and accessibility in one go, you do it by hand. Dreamweaver is no different than any other tool that writes code for you, be it HTML or C++. In the end, the code sucks and becomes a nightmare to maintain, and it isn't standards compliant or does it obey accessibility guidelines, no matter the claims.

Originally Posted by abachler

Wow, calm down Mario, noone said those were the only requirements, but those are two absolutes, without them it cant be a programming language. Although you can still program with a scripting language.

I was calm. I've seen however that quote numerous times. It was taken out of context and used as a means to say what a program language is, when the intention was to say what a programming language should be. It's really not your fault. It has been conveyed that way into our minds.

I believe it was Stroustrup who said that. Can't really be sure. And yet on C++ Programming Language, he has the following to say on 1.3.2 Philosophical Note (note the title and how ironic it now seems since he too agrees it is a matter of philosophy):

"A programming language serves two related purposes: it provides a vehicle for the programmer to specify actions to be executed, and it provides a set of concepts for the programmer to use when thinking about what can be done."

If you agree we can define a programming language by looking at its objectives (and I believe we can), we see how that contrasts to the IO/FLOW quote that is so widespread.

Mike, the problem is that WYSIWYG editors can't generate proper HTML/CSS because they can't infer into the value of the semantics we intend for our content. So the results are sometimes remarkable.

Screen readers depend exclusively on the semantics we provided on the HTML. CSS is completely irrelevant to them. The now infamous table tags where you should have had CSS is just one example. Worst, is the fact that your generated HTML may have the completely wrong structure for screen readers. Depending on the complexity of the page you are drawing, the footer can appear in the middle of the HTML, or the header at the bottom. All it takes for it to be rendered correctly is a <div> tag and CSS absolute positioning. But screen readers know nothing of that.

The fact HTML is only a way to express semantics is exactly what makes it both a powerful tool, a very easy one to go wrong, and a very hard one to get right by code generators.

It should definitely be possible to generate correct and flawless HTML code.
The best would of course be a compiler approach. You design your web page in the editor, then compile it and it generates the correct HTML code.
All the WYSIWYG editors out there right now are very poor in this regard. They do not generate fully compliant code and creates a mess out of the code. It could all be so simple if they would just do it right.

It could all be so simple if they would just do it right.

For everyone except them.

Originally Posted by mike_g

But WSISWG editors are perfect for laying out divs. The whole tables issue is completely irrelevant to the tools.

But that is exactly the problem, don't you see?
DIVs have no semantical value. They are intended to provide structure to the content and as an helper for CSS ability to give rendering instructions to an engine (visual or not). Since W editors were so much bashed over their abuse of tables, their turned on DIV and are now abusing it, providing an HTML with an overpopulation of DIV tags simply for the sake of positioning.

Look, I don't generally do this. But this is one of those issues I'm passionate about. Below there are two links. You will see there is not a single table on those two websites, anywhere whatsoever. The div tags are also kept to a minimum they only provide structure and only rarely are indeed used as tools for positioning purposes. The code is simple and elegant. You should also check the CSS (I believe you have access to it with your browser developer bar, if not point to mzcss.css and quiet.css

It was tested on IE7, IE6, Safari, Opera, WebMonkey, and on several other browsers and systems (namely Windows, Linux and BSD). It was also tested on Lynx text browser and by three screen readers; JAWS, Orca and Thunder.

MZProperty took me one week (not counting the PHP code). Quiettech page took me around 30 minutes. None of those two websites code could ever hope to be so simple if I were to use a W editor. They were developed by hand with WeBuilder and TopStyle Pro and the same or higher speed than could be achieved with a W editor.

http://www.mzproperty.co.uk
http://www.quiettech.co.uk

I don't think you can ever expect to see that kind of code on Dreamweaver. I never did.

IMHO It simply makes production faster, and more accurate.

I hope to have proved it is only if you don't know your (X)HTML/CSS well enough.

Originally Posted by mike_g

Nice website.

Not even near what I would like it to be. But thanks.
It still has a few code issues I would like to handle. MZProperty for instance needs to be moved to XHTML and the CSS is patchy at a few points.

Fair enough you need to know a few things, and sure its easy to make a mess of the code by using a ton of divs when you only need a few, but again thats the users fault not the tools.

Hehe, I give up.
If you prefer to believe that code generators can equal or do better than the human mind, so be it

I think http://www.quiettech.co.uk looks nice.
But they both seem to violate a "rule" (which I don't care for very much anyway) how each row should contain about 13 words or less. What's your take on this?