Don't use Word for editing Webpages! - Subaru Enthusiasts Car Club of the Sierras

cody · 2007-03-01, 06:34 PM

I always save DOC files as HTM before I post them on our Intranet Home Page at work. It's just too easy with Word 2003. I used to print them to PDF, but Adobe reader takes forever to load on some of our slower machines. I know zilch about web design though. The new site looks great!

Jesus, the season is fast approaching! I need to get on the ball if I want to do my 60K maintainance before it starts!

sperry · 2007-03-02, 08:57 AM

Quote:

Originally Posted by cody

I always save DOC files as HTM before I post them on our Intranet Home Page at work. It's just too easy with Word 2003. I used to print them to PDF, but Adobe reader takes forever to load on some of our slower machines. I know zilch about web design though. The new site looks great!

Jesus, the season is fast approaching! I need to get on the ball if I want to do my 60K maintainance before it starts!

Here's regular html:

Code:

<html>
  <head>
    <title>Some Title</title>
  </head>
  <body>
    Some Content
  </body>
</html>

Here's the same page generated by Word:

Code:

<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 11">
<meta name=Originator content="Microsoft Word 11">
<link rel=File-List href="Some%20Title_files/filelist.xml">
<title>Some Title</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>Scott Perry</o:Author>
  <o:LastAuthor>Scott Perry</o:LastAuthor>
  <o:Revision>1</o:Revision>
  <o:TotalTime>1</o:TotalTime>
  <o:Created>2007-03-02T16:55:00Z</o:Created>
  <o:LastSaved>2007-03-02T16:56:00Z</o:LastSaved>
  <o:Pages>1</o:Pages>
  <o:Words>1</o:Words>
  <o:Characters>12</o:Characters>
  <o:Company>International Game Technology</o:Company>
  <o:Lines>1</o:Lines>
  <o:Paragraphs>1</o:Paragraphs>
  <o:CharactersWithSpaces>12</o:CharactersWithSpaces>
  <o:Version>11.6568</o:Version>
 </o:DocumentProperties>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" LatentStyleCount="156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=EN-US style='tab-interval:.5in'>

<div class=Section1>

<p class=MsoNormal>Some Content</p>

</div>

</body>

</html>

DON'T USE WORD TO EDIT WEBPAGES!

cody · 2007-03-02, 09:22 AM

It works though. You're a victom of your own OCD.

Nick Koan · 2007-03-02, 09:30 AM

Quote:

Originally Posted by cody

It works though. You're a victom of your own OCD.

No, he's like any programmer and hates badly generated code.

sperry · 2007-03-02, 09:38 AM

Quote:

Originally Posted by cody

It works though. You're a victom of your own OCD.

It doesn't "work". Take that Word output, now imagine there's some real content in there, bloated all to hell, and edit it with VIM in a linux shell. Chances are, it can't be done... at least not in any sort of timely manner. IMO, that's broken. Just because you live in a windows world, and can get by w/ half-ass broken documents doesn't mean the rest of us have OCD.

Plus, when it comes to bandwidth, your word document formatting could actually cost me money. The Word document is 30 times larger than the hand-edited one... if we were using 30 times more bandwidth around here for the same content, it would noticeably effect the quality of service, not to mention the cost of hosting.

Dean · 2007-03-02, 10:24 AM

And you write all your code in assembly language???

Human friendly "development" tools will always make bigger, uglier "code" that will often be significantly less intelligible when viewed at the lowest level.

But that is the price for improved "time to market" and other buzz word marketing terms.

Get over it. "save as web page" works even if you don't care for the underlying code.

sperry · 2007-03-02, 10:41 AM

Quote:

Originally Posted by Dean

And you write all your code in assembly language???

Human friendly "development" tools will always make bigger, uglier "code" that will often be significantly less intelligible when viewed at the lowest level.

But that is the price for improved "time to market" and other buzz word marketing terms.

Get over it. "save as web page" works even if you don't care for the underlying code.

Word is *not* a "human friendly development tool". Get Dreamweaver or something if you want an editor for html. Word is a huge PITA for editing with, and generated terrible code that doesn't look anything like it's supposed to!

If I "save as web page" and it doesn't look the way the editor previewed it, then it doesn't work.

As far as real RAD and code generation tools... you obviously haven't coded anything in the last 10 years... Good tools generated good code, that at the lowest level is extremely clear and matches best practices for software coding. Bloat is there in the code because it makes it easier to maintain the code, but code is *compiled into machine language*, which removes the bloat. A good compiler will turn long-winded code into the same machine language as if I had written it in assembly language.

HTML IS NOT CODE... it's not compiled, you have to transfer *all* the data to the client, so the browser can interpret it. There's a reason your old Reno SCCA site took forever to download (aside from the lack of hardware it's running on)... your index file was *massive*, 50% of which was unnecessary CRLFs, because you kept editing it in friggen Word.

If your STi was running on 3 cylinders, it's still running, but it's not working as it was intended. As an IT administrator, shame on you for not knowing the difference between beneficial high-level tools and bloated crappy code. Just because something comes up in a browser doesn't mean it's working right.

Dean · 2007-03-02, 11:27 AM

If you honestly believe compilers create code as good hand coded assembly, you are fooling yourself. And don't even start me on what happens when you use the word "Include".

And if the results of a "Save to web page" meets the needs of the person choosing to use it, it does work, car analogies aside.

HTML is code in this analogy, and word is the compiler from a higher level "language" no matter how good or bad it is.

Again, you may not like the old site, but it worked. and the old index.html file was 755 bytes. And the total page including graphics was under 60K

Many thousands of web pages are developed and maintained in Word, FrontPage, Nvu, Excel, etc... whether you like the results or not, they work. You can choose not to use GUI editors, that is your prerogative, but those tools work for many, just as your C# or other compiler works for you.

Joeyy · 2007-03-02, 11:31 AM

Talk about getting off topic.

DON'T USE WORD TO EDIT WEBPAGES!

Nick Koan · 2007-03-02, 11:37 AM

Actually, a lot of my professors used to argue that compilers could create on par with or even better machine code (e.g. faster and smaller) than coding assembly "by hand". Hand coding assembly is prone to human error and personal coding preference and style. Over the past 50 years of coding the best practices have been worked out for the simple and complex instructions and sequences. We can't guarantee that every assembly programmer can know all of these best practices, but with a good compiler and a decent higher level language, they don't need to.

sperry · 2007-03-02, 12:33 PM

Quote:

Originally Posted by Dean

If you honestly believe compilers create code as good hand coded assembly, you are fooling yourself. And don't even start me on what happens when you use the word "Include".

Dean, I will guarantee you, if you were to develop something in ASM, you would get your ass handed to you by a compiler in terms of performance. Modern processors are so complicated these days, and incorporate so many pipelining tricks, caching algorithms, etc, that unless you knew every last register like the back of your hand (like the guy that wrote the compiler

) you can't approach the efficiency of the compiled code, especially if the person running the compiler knows what they're doing. No one uses ASM anymore, except for simple critical code that runs on an old processor. Hell, event the guys doing in-card 3D graphics have high level languages these days.

Also, I haven't typed "include" in like 5 years... what happened in a 1990's C complier is totally irrelevant with today's development suites, high-level languages, virtualized machines, multi-core processors, distributed architectures, etc. Programming these days is about leveraging existing libraries, not about fitting the executable on a single HD floppy.

Quote:

Originally Posted by Dean

And if the results of a "Save to web page" meets the needs of the person choosing to use it, it does work, car analogies aside.

Like I said, if I write a web page in Word, in the browser it better look exactly as I designed it in Word, or Word has failed as a WYSIWYG editor. Just because people are satisfied with broken software doesn't mean the software isn't broken.

Quote:

Originally Posted by Dean

HTML is code in this analogy, and word is the compiler from a higher level "language" no matter how good or bad it is.

Nope. In that analogy Word is the development tool, HTML is the output binary. The "higher level language" is Word's internal XML format, and the compiler is the "save as" function that converts the XML to HTML. That conversion in Word is less than piss-poor.

Sure, writing a web page in Notepad (or any raw text editor) is akin to coding in assembly, and I know it's not for everyone. But a decent html editor uses a browser for previewing (so you know it's accurate) and generates pretty, hand-maintainable, HTML. Word is the absolute *worst* choice for HTML generation. The whole point of HTML (and *any* markup language) is that it's human readable. Word completely defeats the purpose of the standard.

Quote:

Originally Posted by Dean

Again, you may not like the old site, but it worked. and the old index.html file was 755 bytes. And the total page including graphics was under 60K

The old RenoSCCA site was slow and unmaintainable. Perhaps you don't remember the life cycle of system development, but it ends with "maintain". If you can't maintain the site, it doesn't "work". Remember, that site isn't your personal webpage, it has a very well defined goal of acting as a line of communication between the board of directors and the general membership. If the board is unable to change the information on the site at will, then the site has failed its purpose. Because it takes so much work to maintain, and because it can only be maintained by individuals with significant technical skill, the BoD cannot use the site as they require. I would say that makes the site a failure.

Edit: I just noticed the numbers in that quote...

Your index file was a frames container... it could have been 100 bytes instead of 700+. Plus, you had to download all of the framed pages to get the content, which was almost 30k just for the top, navigation and main pages (and that's *after* I stripped and pruned main.htm down from over 45k itself!) and doesn't include the size of the link images.

Your site required the transfer of at least 250k (again, not counting images) to get the same pertinent data that I've got in under 18k of text in one index.html. Including my 7k in images images, I'm still 10 times more efficient.

Quote:

Originally Posted by Dean

Many thousands of web pages are developed and maintained in Word, FrontPage, Nvu, Excel, etc... whether you like the results or not, they work. You can choose not to use GUI editors, that is your prerogative, but those tools work for many, just as your C# or other compiler works for you.

Like I said, I'm not suggesting that hand editing HTML is the "best" way. If I were a professional web developer I certainly wouldn't hand edit, I'd use decent tools (like I did when I was a professional web developer). But Word is the worst... absolute worst... way to maintain a website, followed closely by FrontPage. And what the hell is Excel doing in that list? To bring back the car analogy, using Excel for web authoring is like entering a golf cart in the Indy 500... sure it's got a motor and four wheels, but it's the wrong tool to race 500 miles. Just because something saves to HTML doesn't make it a useful tool for editing HTML.

Markup language bloat is a real-deal issue. I see it everyday with the piss-poor XML based protocols we have to code to. We're going to see real-world bandwidth issues in the field because people in decision making positions have decided on tools and methodology without understanding the underlying technology. I bet those people use Word to edit their homepages too.

sperry · 2007-03-02, 12:35 PM

Quote:

Originally Posted by dknv

Back on topic, nice, it works for me today. I like the new webpage, good job Scott.
Couple of questions -
Estimated date when the 2007 Solo schedule will be up and linked there? (I've told people to watch for the updated schedule to be published on renoscca.com.)
Do the links use the client's browser settings, as far as either going directly to the linked page; or is there an option to allow the link to open in a new browser page? (I know some people find that extra prompt annoying, though.)

Thanks!

p.s., Will you add a link for archived or historical content, i.e. the 2006 newsletters?

The schedule is there, it's just in a word .DOC (which is what started this whole tangent..)

Because I can't get to the server from my work PC, I can't edit the schedule and repost it in a more friendly format. I can try to get to it the next time I'm online from home.

Dean · 2007-03-02, 02:07 PM

Edit: please move this to the other thread. It got moved while I was typing.
______________________

You might consider splitting this discussion into another thread if you choose to continue it.

This is not about what you or I could do...

Compilers like GUI editing tools are just that, tools to increase productivity and permit more timely and practical creation of the end product without the requirement to understand all the underlying details.

While it might require significantly more time, a significantly different set of knowledge, and other resources, I believe significantly faster and smaller binaries to accomplish a given task can be done in assembly, period. It may well require many orders of magnitude in terms of that effort to accomplish those savings, but they are attainable.

Don't get me wrong, compilers are great, but a given compiler cannot produce "optimal" "machine" code for every given application no matter how many passes they make, or flags the developer sets. Abstraction is abstraction, and that is what compilers and GUI editors do, abstract the actual work from the human making the request whatever it is. Without detailed knowledge of the entire system, any results will be suboptimal to some extent no matter how small that may be.

Yes, HTML is the binary in my analogy, but you got my point.

Include was in quotes. Are you saying all your programs are entirely your own and don't rely on any external libraries, procedures, APIs, DLLs, etc. or whatever you want to call them? HA! All of those include yet another layer of abstraction was my point.

I get into these types of arguments all the time with developers and management types when they want a more reliable or fault tolerant end to end solution and believe throwing more hardware will magically provide the solution.

No amount of hardware will replace transactional awareness at the application layer. I can provide an infrastructure that runs at 6 9s, but that won't instantly make an entire end to end application 6 9s. The infrastructure is 3-6 layers abstracted from the application, it can't possibly have awareness of the application requirements.

Compilers make great code, but as they do not have complete visibility to the requirements, they will always create suboptimal code. This is why some portions of drivers and such for things such as video cards and network switches/routers that are absolutely time critical are still written in assembly even today.

Back on the web site. The old web site was maintainable at exactly the level relative to the investment of resources in it combined with the ability of the developer and the system on which it was run.

I wish you the best on improving it going forward.

Nick Koan · 2007-03-02, 02:10 PM

Dean, the discussion was split off like 2 hours ago.

Here, let me help you out...

EDIT: Ah, all better.

Dean · 2007-03-02, 02:16 PM

Quote:

Originally Posted by nKoan

Dean, the discussion was split off like 2 hours ago.

Here, let me help you out...

EDIT: Ah, all better.

I got distracted while typing.

sperry · 2007-03-02, 02:50 PM

Dean, all that talk about compilers, and yet no relevance to the problem with Word's awful conversion to HTML?

You might convince me that given enough development time, pure assembly development will out perform high-level language. But ASM is in itself a language... it still needs to be compiled into machine code. So, you might as well just develop in ones and zeros! Compilers are leaps and bounds better than I think you realize... but yes, it is a layer of abstraction. Your general point is taken: higher level languages reduce development effort and/or development time at the cost of code space/efficiency.

But that argument does not correlate to Word. Sure, you're reducing development time by editing in Word, but you're also getting orders of magnitude worse HTML. By using .NET I can program a system in a month that would take 40 years in ASM, and my resulting code would be maybe 1% bloated. By using Word you save maybe 10 minutes on a 60 minute project, get results that don't match your design, don't conform to the standard, and bloat the HTML by 10 times.

You can try to justify it with "but I'm knowingly trading bloat for development efficiency", but the results speak for themselves: Word is a terrible tool for HTML. Something like Dreamweaver (or whatever the pros use these days) would turn a 60 minute job into a 10 minute job and generate HTML that's 99% as good as hand-coded (if not better since it would most likely be more efficient with style-sheets and the like). I'm not arguing that hi-level development tools are bad; I'm arguing that for HTML, Word is not a high-level development tool.

My point with the "include" was to illustrate how outdated you are in terms of the current state of software development. People don't use C/C++, at least not for enterprise level development... it's too low level. I haven't used a makefile since 1998, and I haven't explicitly run a compiler since I started getting paid to program. Tools these days handle the includes out of sight of the developer. External code use is bigger than ever, hell .NET itself is a library that uses other libraries. The shear mass of code needed to do things like a SOAP based service oriented architecture would turn a simple distributed "Hello World" application into a 5 year 20 person development project if you were to do it in C with no external resources. But using these libraries now days is trivial, it's all built into the development tools.

Dean · 2007-03-02, 06:00 PM

This discussion started because you couldn't be bothered to put the schedule in a web friendly format that would have taken 8 seconds. Would it have been perfect, probably not, but that is what translators, exporters, compilers, etc. do. That is my point.

What you put in one end may not match what comes out the other side and is bound to be less than optimal. Heck, since you can't control the "interpreter" or browser that "runs" the "binary" that is the HTML, you have no prayer of ensuring reliable output without quite a bit of testing. And by the way, I retract my earlier concession. HTML is still code, not a "binary". HTML is an interpreted language with browsers being the interpreter.

Bloat is bloat, whether it is created by you choosing to put remarks in your hand coded HTML or it is created by the word HTML export translator.

OMG. I deal with developers using modern tools every day. I am using generic terms. What would you prefer I call the tool that creates your binaries? A "Studio", "Project builder"? Whatever....

Oooh, you can use big acronyms like SOAP, and XML... I architect multi-platform, mutli-site, highly available, highly integrated systems using modern and legacy systems / protocols, N tier applications, middleware, etc... Don't even start throwing around acronyms with me.

I apologize for not placing a "Visual" in front of my C# reference. I don't write code for a living, but work with people who do every day and often have to explain how things really work. I have been moving bits since the 8080 processor and before, so please don't presume to tell me how computers work.

Also, if you don't have to tell your "Studio/Bulder" how to find 3rd party and external libraries, you are either writing very focused "native" applications, or having very little interaction with other diverse systems. But again, my point is made. You have absolutely no visibility to the code you are calling, and have no clue to what extent it is bloated relative to your actual application requirements. How much memory is used, or how many extra branches are taken in that external code in the final binary?

How is that different than the bloat that Word, Front page, etc. add to HTML?

I work with modern developers who have no clue how their application actually executes on a machine, or how jobs, threads, etc impact the system the code is executing on much less other dependent systems.

Windows is compiled, and so is LINUX, why is one faster for some applications vs. the other. Must be compiler optimization.

Word is a terrible tool to create HTML, but an average user like Dave Deborde can click save to web page, and get results they can live with, especially on MS browsers in seconds. Why should they learn DreamWeaver or even Front Page, etc. if they don't need to?

And last but not least, assembly code only needs to be assembled into machine code by an assembler. There is a 1 to 1 not open to interpretation mapping from assembly into machine code. It is not compiled.

Nick Koan · 2007-03-02, 06:21 PM

Dean, I think we're arguing an order of magnitude. Word's "Save as HTML" bloat adds unneeded bloat. Its adds open and close tags right next to one another. It'll fill in a file with whitespace characters and whitespace escapes. And its a pain in the ass to maintain unless you keep the word docs around and do it all again. And this doesn't even scratch the surface of the unnecessary stuff Word does in its HTML generation.

Where as a high level language may include significantly more lines of compiled binary, more often those instructions are not entirely useless. They add some level of security, sanity checking, exception handling, abstraction, etc so that a simple instruction doesn't crash the whole system.

And for me, the tradeoff for coding in higher level languages is a completely acceptable solution compared to the unacceptable way Word makes webpages. They aren't analogous in my mind.

dknv · 2007-03-02, 06:27 PM

As long as we're complaining about documents and objects accessible on renoscca, I have a question - why is the Feb. newsletter cut off on the right margin on pages 15 and 16?
And it seems like it took forever to load.

Also, I'm reasonably savvy with looking for things like schedules on web pages, but I can't find where there is a link to a document showing a Solo schedule. All I see on the main page is a link to a document under the heading for Trials. Someone give me another clue?

Dean · 2007-03-02, 06:34 PM

Quote:

Originally Posted by nKoan

[F]or me, the tradeoff for coding in higher level languages is a completely acceptable solution compared to the unacceptable way Word makes webpages. They aren't analogous in my mind.

But it would have worked and everyone would have been able to view it crummy and large as it might have been, and it is not like he needed to reclaim the space in use by the word doc on his PC.

What is unacceptable about them? They are viewable by the consumer. The consumer's requirement is to see the schedule in a reasonable period of time without requiring an external application. Word exports meet this requirement.

Scott may have other desired features and supportability issues he wants addressed, but consumers often care little for these.

MikeK · 2007-03-02, 06:35 PM

Quote:

Originally Posted by dknv

Also, I'm reasonably savvy with looking for things like schedules on web pages, but I can't find where there is a link to a document showing a Solo schedule. All I see on the main page is a link to a document under the heading for Trials. Someone give me another clue?

The link says 2007 Event Schedule on the right side of the front page

dknv · 2007-03-02, 06:45 PM

Quote:

Originally Posted by MikeK

The link says 2007 Event Schedule on the right side of the front page

Thanks Mike.
It seems like that link is under the heading for Trials, I was looking for something specific to Solo.

Nick Koan · 2007-03-02, 06:48 PM

Quote:

Originally Posted by Dean

But it would have worked and everyone would have been able to view it crummy and large as it might have been, and it is not like he needed to reclaim the space in use by the word doc on his PC.

What is unacceptable about them? They are viewable by the consumer. The consumer's requirement is to see the schedule in a reasonable period of time without requiring an external application. Word exports meet this requirement.

Scott may have other desired features and supportability issues he wants addressed, but consumers often care little for these.

Updatability. If the page needed to be updated, its ugly, unless you re-use the Word document. Once the whole site becomes ugly to edit like that, then the maintainer will start to drag his/her feet (understandably).

But, in a way you're right, the website has one function. That is to get information from the Reno SCCA BoD to the members and potential members in a timely fashion. In my opinion a Word as HTML only satisfies the requirement for members (in a barely acceptable manner), but doesn't satisfy the needs of the BoD to be able to update pages in a timely manner if the HTML is so bad it makes the maintainer unable or unwilling to take the significantly extra time to update the site.

EDIT: And I'm also arguing outside the specific instance. One time as a temporary stopgap, sure, fine whatever. I arguing about building a whole site (even a vanity site) in nothing but Word.

Nick Koan · 2007-03-02, 06:49 PM

Quote:

Originally Posted by dknv

Thanks Mike.
It seems like that link is under the heading for Trials, I was looking for something specific to Solo.

Its actually above both the solo and the trials headings, as it encompasses both.

Dean · 2007-03-02, 07:26 PM

Quote:

Originally Posted by nKoan

But, in a way you're right, the website has one function. That is to get information from the Reno SCCA BoD to the members and potential members in a timely fashion. In my opinion a Word as HTML only satisfies the requirement for members (in a barely acceptable manner), but doesn't satisfy the needs of the BoD to be able to update pages in a timely manner if the HTML is so bad it makes the maintainer unable or unwilling to take the significantly extra time to update the site.

If Scott sets it up so the secretary can upload the minutes and the newsletter editor can upload those, then they can use any tool they wish to create that content.

There are great content management systems that do amazing stuff but those are not supportable at this scale for the opposite reasons. You would spend more time managing the management system than just managing the content manually.

It all goes back to using the right toll for the right reasons. This is true for web content as it is for application code.

I agree with you, and wouldn't use Word to manage a core framed page with embedded much of anything. But it works fine for creating end pages especially Quick and Dirty. So does Excel.

I can't imagine hand coding or even attempting to import some of our Excel sheets into an GUI HTML editor. No matter how bloated the Excel exported HTML code is, I'd live with it.

A schedule is an end document, and thus Word is an acceptable HTML creator IMHO. This is especially true because the creator is likely to maintain it in Word until he is given a better easier tool, and even then, they may not choose to use it. Heck, I never did get some of our past board to stop using spaces for formating and thus had to recreate much of the material they sent me to make it web friendly.

2007-03-01, 06:34 PM	#1
cody Candy Mountain Real Name: Cody Join Date: May 2005 Location: Californication Posts: 7,751 Car: 03 Pussy Wagon, now with more pink! Class: TESP OMG Internet!	Don't use Word for editing Webpages! I always save DOC files as HTM before I post them on our Intranet Home Page at work. It's just too easy with Word 2003. I used to print them to PDF, but Adobe reader takes forever to load on some of our slower machines. I know zilch about web design though. The new site looks great! Jesus, the season is fast approaching! I need to get on the ball if I want to do my 60K maintainance before it starts! Last edited by cody; 2007-03-01 at 06:36 PM.

2007-03-02, 10:24 AM	#6
Dean Señor Cheap Bastarde Real Name: Dean Join Date: May 2003 Location: $99 Tire Store Posts: 9,294 Car: $.04 STI Class: Fast,Cheap & Reliable=STI Deal, did somebody say Deal? Oh, Dean, yeah that's me.	And you write all your code in assembly language??? Human friendly "development" tools will always make bigger, uglier "code" that will often be significantly less intelligible when viewed at the lowest level. But that is the price for improved "time to market" and other buzz word marketing terms. Get over it. "save as web page" works even if you don't care for the underlying code. __________________ I am a Commodore PET --- Now get off my lawn you kids...

2007-03-02, 11:27 AM	#8
Dean Señor Cheap Bastarde Real Name: Dean Join Date: May 2003 Location: $99 Tire Store Posts: 9,294 Car: $.04 STI Class: Fast,Cheap & Reliable=STI Deal, did somebody say Deal? Oh, Dean, yeah that's me.	If you honestly believe compilers create code as good hand coded assembly, you are fooling yourself. And don't even start me on what happens when you use the word "Include". And if the results of a "Save to web page" meets the needs of the person choosing to use it, it does work, car analogies aside. HTML is code in this analogy, and word is the compiler from a higher level "language" no matter how good or bad it is. Again, you may not like the old site, but it worked. and the old index.html file was 755 bytes. And the total page including graphics was under 60K Many thousands of web pages are developed and maintained in Word, FrontPage, Nvu, Excel, etc... whether you like the results or not, they work. You can choose not to use GUI editors, that is your prerogative, but those tools work for many, just as your C# or other compiler works for you. __________________ I am a Commodore PET --- Now get off my lawn you kids...

2007-03-02, 11:37 AM	#10
Nick Koan JDM Cowboy Real Name: Nick Join Date: Oct 2003 Location: Somewhere Posts: 8,642 Car: 2015 Mazda 3	Actually, a lot of my professors used to argue that compilers could create on par with or even better machine code (e.g. faster and smaller) than coding assembly "by hand". Hand coding assembly is prone to human error and personal coding preference and style. Over the past 50 years of coding the best practices have been worked out for the simple and complex instructions and sequences. We can't guarantee that every assembly programmer can know all of these best practices, but with a good compiler and a decent higher level language, they don't need to. __________________ While a standard engine is powered by a belt connected to the crankshaft, a turbo engine runs on its own exhaust steam, making it more energy efficient. -- CNN

2007-03-02, 02:07 PM	#13
Dean Señor Cheap Bastarde Real Name: Dean Join Date: May 2003 Location: $99 Tire Store Posts: 9,294 Car: $.04 STI Class: Fast,Cheap & Reliable=STI Deal, did somebody say Deal? Oh, Dean, yeah that's me.	Edit: please move this to the other thread. It got moved while I was typing. ______________________ You might consider splitting this discussion into another thread if you choose to continue it. This is not about what you or I could do... Compilers like GUI editing tools are just that, tools to increase productivity and permit more timely and practical creation of the end product without the requirement to understand all the underlying details. While it might require significantly more time, a significantly different set of knowledge, and other resources, I believe significantly faster and smaller binaries to accomplish a given task can be done in assembly, period. It may well require many orders of magnitude in terms of that effort to accomplish those savings, but they are attainable. Don't get me wrong, compilers are great, but a given compiler cannot produce "optimal" "machine" code for every given application no matter how many passes they make, or flags the developer sets. Abstraction is abstraction, and that is what compilers and GUI editors do, abstract the actual work from the human making the request whatever it is. Without detailed knowledge of the entire system, any results will be suboptimal to some extent no matter how small that may be. Yes, HTML is the binary in my analogy, but you got my point. Include was in quotes. Are you saying all your programs are entirely your own and don't rely on any external libraries, procedures, APIs, DLLs, etc. or whatever you want to call them? HA! All of those include yet another layer of abstraction was my point. I get into these types of arguments all the time with developers and management types when they want a more reliable or fault tolerant end to end solution and believe throwing more hardware will magically provide the solution. No amount of hardware will replace transactional awareness at the application layer. I can provide an infrastructure that runs at 6 9s, but that won't instantly make an entire end to end application 6 9s. The infrastructure is 3-6 layers abstracted from the application, it can't possibly have awareness of the application requirements. Compilers make great code, but as they do not have complete visibility to the requirements, they will always create suboptimal code. This is why some portions of drivers and such for things such as video cards and network switches/routers that are absolutely time critical are still written in assembly even today. Back on the web site. The old web site was maintainable at exactly the level relative to the investment of resources in it combined with the ability of the developer and the system on which it was run. I wish you the best on improving it going forward. __________________ I am a Commodore PET --- Now get off my lawn you kids... Last edited by Dean; 2007-03-02 at 02:18 PM.

2007-03-02, 09:22 AM	#3
cody Candy Mountain Real Name: Cody Join Date: May 2005 Location: Californication Posts: 7,751 Car: 03 Pussy Wagon, now with more pink! Class: TESP OMG Internet!	It works though. You're a victom of your own OCD.

2007-03-02, 11:31 AM	#9
Joeyy i can has kart? Join Date: Jun 2005 Location: CA Posts: 1,228	Talk about getting off topic. DON'T USE WORD TO EDIT WEBPAGES!

2007-03-02, 02:10 PM	#14
Nick Koan JDM Cowboy Real Name: Nick Join Date: Oct 2003 Location: Somewhere Posts: 8,642 Car: 2015 Mazda 3	Dean, the discussion was split off like 2 hours ago. Here, let me help you out... EDIT: Ah, all better. __________________ While a standard engine is powered by a belt connected to the crankshaft, a turbo engine runs on its own exhaust steam, making it more energy efficient. -- CNN

2007-03-02, 02:50 PM	#16
sperry The Doink Real Name: Scott Join Date: Nov 2002 Location: Portland, OR Posts: 20,335 Car: '09 OBXT, '02 WRX, '96 Miata Class: PDX/TT-6 The way out is through	Dean, all that talk about compilers, and yet no relevance to the problem with Word's awful conversion to HTML? You might convince me that given enough development time, pure assembly development will out perform high-level language. But ASM is in itself a language... it still needs to be compiled into machine code. So, you might as well just develop in ones and zeros! Compilers are leaps and bounds better than I think you realize... but yes, it is a layer of abstraction. Your general point is taken: higher level languages reduce development effort and/or development time at the cost of code space/efficiency. But that argument does not correlate to Word. Sure, you're reducing development time by editing in Word, but you're also getting orders of magnitude worse HTML. By using .NET I can program a system in a month that would take 40 years in ASM, and my resulting code would be maybe 1% bloated. By using Word you save maybe 10 minutes on a 60 minute project, get results that don't match your design, don't conform to the standard, and bloat the HTML by 10 times. You can try to justify it with "but I'm knowingly trading bloat for development efficiency", but the results speak for themselves: Word is a terrible tool for HTML. Something like Dreamweaver (or whatever the pros use these days) would turn a 60 minute job into a 10 minute job and generate HTML that's 99% as good as hand-coded (if not better since it would most likely be more efficient with style-sheets and the like). I'm not arguing that hi-level development tools are bad; I'm arguing that for HTML, Word is not a high-level development tool. My point with the "include" was to illustrate how outdated you are in terms of the current state of software development. People don't use C/C++, at least not for enterprise level development... it's too low level. I haven't used a makefile since 1998, and I haven't explicitly run a compiler since I started getting paid to program. Tools these days handle the includes out of sight of the developer. External code use is bigger than ever, hell .NET itself is a library that uses other libraries. The shear mass of code needed to do things like a SOAP based service oriented architecture would turn a simple distributed "Hello World" application into a 5 year 20 person development project if you were to do it in C with no external resources. But using these libraries now days is trivial, it's all built into the development tools. __________________ Is you is, or is you ain't, my con-stit-u-ints?

2007-03-02, 06:00 PM	#17
Dean Señor Cheap Bastarde Real Name: Dean Join Date: May 2003 Location: $99 Tire Store Posts: 9,294 Car: $.04 STI Class: Fast,Cheap & Reliable=STI Deal, did somebody say Deal? Oh, Dean, yeah that's me.	This discussion started because you couldn't be bothered to put the schedule in a web friendly format that would have taken 8 seconds. Would it have been perfect, probably not, but that is what translators, exporters, compilers, etc. do. That is my point. What you put in one end may not match what comes out the other side and is bound to be less than optimal. Heck, since you can't control the "interpreter" or browser that "runs" the "binary" that is the HTML, you have no prayer of ensuring reliable output without quite a bit of testing. And by the way, I retract my earlier concession. HTML is still code, not a "binary". HTML is an interpreted language with browsers being the interpreter. Bloat is bloat, whether it is created by you choosing to put remarks in your hand coded HTML or it is created by the word HTML export translator. OMG. I deal with developers using modern tools every day. I am using generic terms. What would you prefer I call the tool that creates your binaries? A "Studio", "Project builder"? Whatever.... Oooh, you can use big acronyms like SOAP, and XML... I architect multi-platform, mutli-site, highly available, highly integrated systems using modern and legacy systems / protocols, N tier applications, middleware, etc... Don't even start throwing around acronyms with me. I apologize for not placing a "Visual" in front of my C# reference. I don't write code for a living, but work with people who do every day and often have to explain how things really work. I have been moving bits since the 8080 processor and before, so please don't presume to tell me how computers work. Also, if you don't have to tell your "Studio/Bulder" how to find 3rd party and external libraries, you are either writing very focused "native" applications, or having very little interaction with other diverse systems. But again, my point is made. You have absolutely no visibility to the code you are calling, and have no clue to what extent it is bloated relative to your actual application requirements. How much memory is used, or how many extra branches are taken in that external code in the final binary? How is that different than the bloat that Word, Front page, etc. add to HTML? I work with modern developers who have no clue how their application actually executes on a machine, or how jobs, threads, etc impact the system the code is executing on much less other dependent systems. Windows is compiled, and so is LINUX, why is one faster for some applications vs. the other. Must be compiler optimization. Word is a terrible tool to create HTML, but an average user like Dave Deborde can click save to web page, and get results they can live with, especially on MS browsers in seconds. Why should they learn DreamWeaver or even Front Page, etc. if they don't need to? And last but not least, assembly code only needs to be assembled into machine code by an assembler. There is a 1 to 1 not open to interpretation mapping from assembly into machine code. It is not compiled. __________________ I am a Commodore PET --- Now get off my lawn you kids...

2007-03-02, 06:21 PM	#18
Nick Koan JDM Cowboy Real Name: Nick Join Date: Oct 2003 Location: Somewhere Posts: 8,642 Car: 2015 Mazda 3	Dean, I think we're arguing an order of magnitude. Word's "Save as HTML" bloat adds unneeded bloat. Its adds open and close tags right next to one another. It'll fill in a file with whitespace characters and whitespace escapes. And its a pain in the ass to maintain unless you keep the word docs around and do it all again. And this doesn't even scratch the surface of the unnecessary stuff Word does in its HTML generation. Where as a high level language may include significantly more lines of compiled binary, more often those instructions are not entirely useless. They add some level of security, sanity checking, exception handling, abstraction, etc so that a simple instruction doesn't crash the whole system. And for me, the tradeoff for coding in higher level languages is a completely acceptable solution compared to the unacceptable way Word makes webpages. They aren't analogous in my mind. __________________ While a standard engine is powered by a belt connected to the crankshaft, a turbo engine runs on its own exhaust steam, making it more energy efficient. -- CNN

2007-03-02, 06:27 PM	#19
dknv EJ207 Join Date: Dec 2002 Location: 39n53, 119w90 Posts: 2,698 Car: RX-8 Class: CS maybe	As long as we're complaining about documents and objects accessible on renoscca, I have a question - why is the Feb. newsletter cut off on the right margin on pages 15 and 16? And it seems like it took forever to load. Also, I'm reasonably savvy with looking for things like schedules on web pages, but I can't find where there is a link to a document showing a Solo schedule. All I see on the main page is a link to a document under the heading for Trials. Someone give me another clue?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
The word is out!!	sti deede	Off Topic Chat	35	2006-06-19 10:34 AM
Word of the Day: Pogonip	Dean	Off Topic Chat	20	2005-01-20 01:34 PM
So, is it okay to start a sentence with the word, So ?	MattR	Off Topic Chat	9	2004-03-11 10:32 PM