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

Of course I am also a bit of a purist -- like to work on code level. And 
when I teach markup, students must use basic text-editors. I agree that 
if one does not understand such basics (eg. proper nesting etc) one 
would not learn the subtleties.
But no, I defintiley do not speak from marketing tool point of view.
I am not convinced though that an author needs to see the code. An 
application can handle that very well -- SGML editors, XML editors, etc 
write well-formed and valid code.

Consider the div/span case. And let me use a word processor application 
(the old AmiPro, now known as IBM Lotus WordPro, which incidentally is 
still by far the best w.p. from usability point of view) as an example. 
Technically page layout is done with "frames" (not HTML frames) which 
are containing boxes. HTML's div would fit this bill. Inline strings are 
marked with span. Why does the user need to know this difference? A 
WordPro No word processor or even DTP user knows this kind of technical 
detail.

I agree with your point about workflow on HTML as medium for written 
communication. But that is valid not only for HTML, but for any medium 
where information chunking is required. It just so happens that HTML 
currently is the most popular one.

Perhaps there is some confusion here about marking the logical 
structures of content, and writing the code for those marked items. 
Marking the logical content is a human excercise. I am not convinced a 
machine will ever be able to do this. But mapping that human activity to 
programmatic code is a dumb task. Of course I agree that humans need to 
do the chunking of info, and "marking" chunks semantically. But that is 
still a "front-end" excercise. Tagging the chunks with markup elements 
can happen in the engine room, and the application program can handle 
that very well.

I also agree with the notion of keeping logical structure and appearance 
separate -- structure marked with some markup language, appearance 
handled by style sheets. But again, the user does not care how this is 
done. Again, the App can handle this.

David Woolley wrote:

>
> 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.
>
>

-- 
___________________________
Dr Jacques Steyn
Head: School of IT
Monash South Africa

+27-11-950-4132 Phone
+27-11-950-4133 Fax
+27-83-296-9122 Mobile

http://sit.monash.ac.za
jacques.steyn@infotech.monash.edu

IDIA: International Development Informatics Association
http://www.developmentinformatics.org/

Received on Wednesday, 2 May 2007 10:31:06 UTC