Re: HTML5 script start tag should select appropriate content model according to src

Jacques Steyn wrote:
>  From a users point of view, code applications should operate like word 
> processors -- recall how early windows based word processors allowed 
> authors to get down to code level? Well, who does that today? Same 

My belief is that HTML would never have taken off if people had not been 
able to hand code it, as I think one of the reasons for its early 
success was that competing technologies relied on the sale of expensive 
authoring tools for their revenue stream.

> should happen for HTML coding. The Application Developers should see to 
> it that the HTML Coding App add tags properly (strictly, well-formed, 
> valid) while a user should just get on with the job.

The result of just doing that is DIV/SPAN HTML.  HTML is not HTML 
without information which goes well beyond the visual appearence on the 
a GUI display.  Unless the author understands the grammar of that 
information they will not produce semantically valid HTML.

You cannot solve this by simply creating a tool that quizzes the author 
for the missing information, as it will fail in the market without 
management support, as users will always prefer a tool that doesn't nag 
them for information, or, like with alt currently, will provide bogus 
information to get rid of the nag.

> I base this on a Multimedia degree I taught: I suspect the ninds of 
> creative people and of coders work quite differently. Over the past 10 

I suspect you are viewing HTML from the marketing tool point of view.
My impression of the marketing workflow is something like this:

- Come up with a idea for the visual appearence and a few headlines;
- convince web browser to create this appearance;
- flesh out the text content slightly;
- bring in search engine optimisation consultant;
- if forced to do so, bring in accessibility consultant, to bolt on
   accessibility.

Non-in house web applications tend to have a similar workflow, but with 
extra steps for the programming, and probably without the SEO step.

As well as having a poor result for accessibility, this conflicts with 
the original design aims of HTML, which were as a medium for written 
communication, and which has a workflow more like:

- decide what you want to say;
- create document outline;
- flesh out with text;
- mark up text to indicate semantics;
   (the original HTML workflow ends here)
- add images to illustrate points;
- add styling to improve appearence or merge in house style style sheet
   for consistent branded look.

What I think Phillip has suggested, is that with this workflow, the part 
up to the inclusion of informative images is done, using HTML, by 
someone expert in the content matter, and the rest is done, in CSS, by 
someone with more artistic leanings.

The more I think about, the more I'm convinced that the marketing 
workflow needs something much closer to the PDF workflow, where the 
first stage uses a graphical format and the SEO and accessibilty experts 
then add the tagging layer to encode the semantics.  (Whilst saying 
this, as a consumer, I find the result of the marketing workflow very 
frustrating, because I simply cannot find the information needed to make 
good decisions.  I prefer my art as art, not as a surrogate for the 
quality of technology products.)

Something that I find amusing is that the people who use the marketing 
workflow seem to end up using HTML and the people who use the content 
driven workflow (instruction manuals, white papers) use PDF!  My own 
theory is that such functions are seen as the poor relations of the 
promotional side of marketing, so they get the hand me down tools.  The 
lack of good basic vector graphic support in web browsers has been an 
issues as well, but I've noticed a reduction in vector graphics in PDFs.

The consequence of using a document writing tool for graphic art work is 
that you have to learn lots of tricks to do things that would be easy in 
a language designed for the purpose.

Received on Monday, 30 April 2007 21:40:35 UTC