• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Web Site programming

Please identify an alternative technology that will output, as easily and as well as html + css, ONE 'content' file to the following range of media types:

  • speech and sound synthesizers
  • braille tactile feedback devices
  • paged braille printers
  • small or handheld devices
  • printers
  • projected presentations, like slides
  • computer screens
  • fixed-pitch character grid, like teletypes and terminals
  • television-type devices

Today you are right(ish) - there is not much of a legacy. Tomorrow, there will be - users will demand very rich online experiences - HTML and co will not be able to deliver it. You might be right - I'll retain judgement - let's come back here in 5 years and see...
 
I happen to think that CSS is needlessly complicated and hideously verbose (not to mention that its standards are poorly implimented in most browsers) but I do understand that the whole point of it is that styles are placed centrally in one file, so that one does not have to type it in everywhere one wants to apply it.

Right - and I see no good reason why I should have to mentally interpret styles in order to see what they are like. The tools I use should be self-evident.

I think it is more likely that mark-up will become increasingly important. The variety of devices that can access the web is only going to increase, and therefore the same content will have to be presented in many more forms then today, on many devices that may not be able to present with GUIs, fonts or colours.

I agree with the variety argument but I do not see how this translates into a greater role for markup language. I draw the opposite conclusion.

Of course not. Graphical user interfaces are graphics, and furthermore user interfaces. Mark-up languages are ways to organise information, not to present them graphically. The information may be presented graphically, but also in other ways, such as sound. I don't think mark-up languages are the outdated legacy technology here, as I think organising information will continue to be important, even if the current user interface paradigms are long gone.

The WWW is no longer just a bunch of HTML documents, it is a universally accessible set of rich applications. We typically retrieve, insert and update data via our internet applications - this is not what HTML was intended for and it does not do it well.

I'm happy to have drawn criticism on this - let's come back to the argument in 3 years time (I think / hope that jref will still be around).
 
Today you are right(ish) - there is not much of a legacy. Tomorrow, there will be - users will demand very rich online experiences - HTML and co will not be able to deliver it


Please identify:
  • Where I am wrong(ish)
  • What constitutes 'not much (or anything) of a legacy'
  • An example of a rich online experience that HTML and co will not be able to deliver (please define the 'and co' at the same time) (ETA: please do not cite xForms)

You might be right - I'll retain judgement - let's come back here in 5 years and see...

I freely admit that I might be wrong and welcome feedback, ideas and suggestions

However, I try to adopt a Pareto Principle approach to my work and think that 'if it ain't broke, don't fix it'

Consequently, I ain't gonna entertain vague generalisations as evidence that I need to rethink my approach, as to do so would be a waste of time and effort; where would I start?
 
Last edited:
The tools I use should be self-evident

Well, yeah, ok, they're your tools...

So... who is the should aimed at?

We typically retrieve, insert and update data via our internet applications - this is not what HTML was intended for and it does not do it well.

Ermmm... who said that HTML was anything other than a mark-up language?

If you actually have a point to make here, what is it?
 
Last edited:
I think BenBurch means that (unlike html + css + javascript combinations) an author can use Flash to dictate not only the content but also the presentation (fonts, colours, widths, heights, etc) and the behaviour (onLoad, onClick, onBlur, etc)...

So, the output is WhatYouHardCodeIsWhatTheyGetAndTheyCanLikeItOrLumpIt

Bingo!

Tell him what he's won, Jay...

;)
 
Thanks - I'm thinking of buolding a large site with PHP/Mysql. Are the pages generated by this able to be freely spidered. Hope I'm not being a pain.

Yes, seeing as they output what you program them to, eg. whatever flavour of HTML+CSS you prefer, your pages will look no different from hard-coded ones.

Bear in mind that there are a few nifty things that can be time-consuming to build yourself, depending on what you want to do. Things like legible urls ("example.com/articles/great_article_title" instead of "example.com/?cat=articles&id=1241") and such. I'd recommend building off an existing open-source CMS, where most of these issues have been solved and you can bring your experience with HTML/CSS to bear. Sometimes you have to tweak these existing systems quite far to get the result you want, but building PHP/MySQL applications from scratch is a lot of work. Again, depending on what you want to do. Have a look at opensourcecms.com, that lets you compare and even try out all the OSS options.
 
Right - and I see no good reason why I should have to mentally interpret styles in order to see what they are like. The tools I use should be self-evident.
I kind of agree with you on this. When designing the style of a document it is in many cases better to use a visual editing tool that shows you what the style might look like. But that's not WYSIWYG, it is only WYSIWYG-ish. There are no guarantees that it is going to look the same to your audience.

A problem with visual editing tools may be that designers are encouraged to design their styles using fixed pixel coordinates and fixed font sizes instead of flexible styles that adapt to the user's preferences. That often leads to text I can't increase in size with CTRL-Scrollwheel, pictures appearing on top of text, text disappearing behind invisible spacers, and more ridiculous stuff like that.

I agree with the variety argument but I do not see how this translates into a greater role for markup language. I draw the opposite conclusion.
The greater role for markup language is caused by the fact that the styles you design may not be rendered by the device your site is viewed on, but with proper markup it can still be understood. The picture you wanted to appear on a specific pixel coordinate may fall outside the screen for some of your audience, or on top of the text for others, but with proper markup browsers that ignore your styles can still present it in an understandable way.

The WWW is no longer just a bunch of HTML documents, it is a universally accessible set of rich applications. We typically retrieve, insert and update data via our internet applications - this is not what HTML was intended for and it does not do it well.
Crazily enough, all that has to be translated to a 7 bit text standard designed for Teletype before it is sent. That's some serious legacy technology right there. HTML keeps it all together, it's marking up what is text, what is script, image, sound or video. Without markup, your browser wouldn't know what to do with what is being sent.
 
Arent you glad though that it is at least 7 bits? I had to deal with 5-bit teletypes years and years ago, and they were a PITA. There was a code to shift up to the second set of characters and another to shift down. If you missed a shift transition, you got weird results. And you couldn't send a shift before each character or a real physical teletype where that shift meant a physical movement up or down of the carriage mechanism would have reacted very badly to it. And there was no lowercase whatsoever;

Ita2.png
 
This is a very fair comment:
Call me old fashioned but, in the absence of a crystal ball, I'll opt to develop web sites - not apps (what this thread is about - note the OP was written by a newbie) using industry standards, thanks

In my defence, I was originally commenting on the apparent distaste for WYSIWYG expressed in the thread. I think that distaste is misplaced. I personally would (and do) develop websites using currently pervasive technology (i.e. HTML etc...). But I find it generally lacking.

I do not like this technology much, I think it was designed for a legacy purpose (I think this is a self-evident fact). I believe that in future there will be more application-friendly pervasive technologies (than html). I believe that there are examples of this today but my arguments have been more about the future than today.

Please put this in context - I am thinking 3 years hence not today.
 
I kind of agree with you on this. When designing the style of a document it is in many cases better to use a visual editing tool that shows you what the style might look like. But that's not WYSIWYG, it is only WYSIWYG-ish. There are no guarantees that it is going to look the same to your audience.

I agree, however, more-or-less-WYSIWYG is better than typical web tools what-you-see-bears-no-relation-to-what-you-get.

A problem with visual editing tools may be that designers are encouraged to design their styles using fixed pixel coordinates and fixed font sizes instead of flexible styles that adapt to the user's preferences. That often leads to text I can't increase in size with CTRL-Scrollwheel, pictures appearing on top of text, text disappearing behind invisible spacers, and more ridiculous stuff like that.

Agreed again but this is not a fault with the WYSIWYG idea but with the tools being rubbish.

The greater role for markup language is caused by the fact that the styles you design may not be rendered by the device your site is viewed on, but with proper markup it can still be understood. The picture you wanted to appear on a specific pixel coordinate may fall outside the screen for some of your audience, or on top of the text for others, but with proper markup browsers that ignore your styles can still present it in an understandable way.

Crazily enough, all that has to be translated to a 7 bit text standard designed for Teletype before it is sent. That's some serious legacy technology right there. HTML keeps it all together, it's marking up what is text, what is script, image, sound or video. Without markup, your browser wouldn't know what to do with what is being sent.

I think that html browsers will ultimately just transform into containers for rich content. I think that is de facto largely how the internet is used today. ActiveX, Applet, Streaming etc....these are not html. I have no problem with markup as a pointer to rich content but I do do not think it will be relevant in its own right in the future.
 
...more-or-less-WYSIWYG is better than typical web tools what-you-see-bears-no-relation-to-what-you-get
I'm curious...

Which apps are you thinking of when you say:
  • more-or-less-WYSIWYG
  • typical web tools

To me, the word 'typical' suggests Dreamweaver and FrontPage/Expressions, which are almost WYSIWYGs...

Agreed again but this is not a fault with the WYSIWYG idea but with the tools being rubbish

Are you familiar with Amaya?

Last time I had a good look/play, I found it a bit clunky. However, call me naively optimistic but I have a hunch (based on my high opinion of those at the w3C) that if/when anyone finally releases a real, cross-platform WYSIWYG for the web, they'll follow the open source route of the Amaya team

w3.org/Amaya » W3C's Editor/Browser

Amaya is a Web editor, i.e. a tool used to create and update documents directly on the Web. Browsing features are seamlessly integrated with the editing and remote access features in a uniform environment. This follows the original vision of the Web as a space for collaboration and not just a one-way publishing medium.

Work on Amaya started at W3C in 1996 to showcase Web technologies in a fully-featured Web client. The main motivation for developing Amaya was to provide a framework that can integrate as many W3C technologies as possible. It is used to demonstrate these technologies in action while taking advantage of their combination in a single, consistent environment.

Amaya started as an HTML + CSS style sheets editor. Since that time it was extended to support XML and an increasing number of XML applications such as the XHTML family, MathML, and SVG. It allows all those vocabularies to be edited simultaneously in compound documents.

I think that html browsers will ultimately just transform into containers for rich content. I think that is de facto largely how the internet is used today. ActiveX, Applet, Streaming etc....these are not html. I have no problem with markup as a pointer to rich content but I do do not think it will be relevant in its own right in the future.

You seem to have done a fair bit of thinking... how much of it was grounded in evidence-based research?
 
I'm curious...
Aren't we all...?

Which apps are you thinking of when you say:
  • more-or-less-WYSIWYG
  • typical web tools

I was thinking in general terms of tools that claim to enable fast web development (or any development).

To me, the word 'typical' suggests Dreamweaver and FrontPage/Expressions, which are almost WYSIWYGs...

And both of them are awful - exactly my point.

Are you familiar with Amaya?

No - is it good...?

Last time I had a good look/play, I found it a bit clunky.

Ok - can I download it to try?

However, call me naively optimistic but I have a hunch (based on my high opinion of those at the w3C) that if/when anyone finally releases a real, cross-platform WYSIWYG for the web, they'll follow the open source route of the Amaya team

We shall see, I suppose.
I do not have a specially high opinion of w3c but let them redeem themselves...:0)

w3.org/Amaya » W3C's Editor/Browser





You seem to have done a fair bit of thinking... how much of it was grounded in evidence-based research?[/QUOTE]
 
You seem to have done a fair bit of thinking... how much of it was grounded in evidence-based research?

I'm happy to admit its just my opinion. Its based upon highly fallible industry experience and personal bias. Please state your statistics to claim the moral high ground.... Really - I would love to go to work tomorrow and be a smart-arse by telling them all something they didn't know.
 
I was thinking in general terms of tools that claim to enable fast web development (or any development).

Care to name some?

is [Amaya] good...?

Like I said, last time I tried it (2+ years ago???) I found it a bit clunky... better than all the rest - but that ain't saying much... which is why I recommend hand-coding in a text editor

You can try it for yourself and form your own opinion

can I download it to try?

yes

I do not have a specially high opinion of w3c

Which industry people and/or organisations do you have a high opinion of?
 
Please state your statistics to claim the moral high ground....

:confused:

When did you stop beating your wife/bishop?

Really - I would love to go to work tomorrow and be a smart-arse by telling them all something they didn't know.

Tell 'em that the WWW is not the Internet

If they say they already knew that, ask 'em why they didn't tell you
 
Notepad++ (http://notepad-plus.sourceforge.net) is based on the same core as SciTE (Scintilla) and is, to my mind, better than SciTE (I've used both). It is open source as well.

The Notepad++ FAQ even includes instructions for running on Linux with Wine, although I'd generally go for a native Linux editor instead.
 
:confused:

When did you stop beating your wife/bishop?

Tell 'em that the WWW is not the Internet

If they say they already knew that, ask 'em why they didn't tell you

Why does this discussion have to descend to insults?

My main point was to defend WYSIWYG and I made some sideline points about the relative importance of HTML in the future of internet applications.

I am very happy for my opinion to be challenged (and I might change it if I hear convincing arguments). I am going out on an argumentative limb purposefully - for validation and review of my thoughts. Remarks about beating my wife or bishop are not really helpful though
 

Back
Top Bottom