- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Wed, 16 Jul 2003 00:09:09 -0400
- To: "Kevin A Sesock" <sesock@okstate.edu>, <w3c-wai-ig@w3.org>
>>> please pester more people with it, how about the html / xhtml lists? >>> @include menu.html is every bit as valid as linking to an image, css, >> or script. >> Personally I cannot agree with you. Using a client-side methodology >> to include content and structure is a Bad Idea. > Why is this, in particular? This is what CSS is doing, <snip> Yes and no... CSS imported using the @include adds *style*, not content. If you don't have the web pretty you still get the web content, which is usually the real reason people come to any site... for it's content, not it's designer's(sic) artistic skills (some sites excluded - art sites are for art...) > I thought the big move these days with extensibility? Pull the layout > out of the html to separate form and content. Be able to create your > own data structures with xml, etc. Why would it be a problem to be able > to reference a document in another document? ahhh... re-read the proposal. Referencing a document in another document is as old as html itself... remember the anchor tag (<a href...>)? No, what Mr. Chetwynd is proposing is using *client side* methodology to include content, which is extremely dangerous from both accessibility and usability perspectives. For if the user agent does not support a particular form of client side inclusion (be it JavaScript's document.write or Jonathan's latest scheme to use @include menu.html) then SIGNIFICANT AND IMPORTANT INFORMATION IS LOST TO THAT USER. If my user agent did not support the @import scheme as indicated above, then the navigation component of the site would not be available to me or my user agent. Do you think this is a positive or beneficial thing? Progressive or useful? > I do agree that lack of support would be a problem, but then again, if > and when something like this were to be recognized as truly a standard > (in that it's time to start using them), as CSS, XML, DTD, and a host of > other standards have been, they will already be relatively mature and will > have been integrated into browsers for a long time. This broad statement is based upon what exactly? DTD may very well be a standard (and, according to the HTML 4.01 Standard of 1999 a *MANDATORY* element in every HTML document), most WYSIWYG authoring tools (sadly, including Dreamweaver) do not include a DTD in their final output (unless manually added by the savvy developer). Audio Style sheets have been "standardized" for over 4 years now, yet no commercial browser or assistive technology yet supports them (please people, if I am wrong correct me). One of the fastest growing segments of net delivery is to cellular phones (et al), especially in Europe... I am currently unaware of any of those generation of user agents which support JavaScript/EMACScript. When 85% of the web pages I view cannot pass a simple validation to HTML 4.01 Transitional, how can you talk about mature implementation of Standards within the web community? > My personal feeling is > that backwards compatibility for every version of every browser is asanine > and pointless. You, like everyone else, are entitled to your opinions. If you can convince the people who pay you to develop web content of this opinion, then you can sleep knowing that your paycheck is safe. I suppose you are too young/new to really remember the "best viewed with wars" eh? Backwards compatibility (or more precisely graceful degradation) is not asinine, it is in fact an art rarely practiced today by Dreamweaver jockeys who figure if it looks good in IE 5.5 or higher then it must be OK. Do not confuse developing to faults or quirks of older, less refined browsers with developing clean, valid HTML. All stakeholders must accept the fact that a web page is not a print medium output... it's perfectly OK to look different in different browsers, as long as it "works" structurally and semantically. The pixel perfect "designers" are the dangerous ones, not those who clamour for standards compliance. I had a recent client tell me to lock down the font on their site to 9 points because it looked more professional. Who is asinine here? >Why must we rely on server-side inclusion for things along these lines? I >understand truly dynamic content, but (and maybe this is me being idealistic), >I thought the standards were not only to inspire combatability (pun intended) >but also to ease the job of the developer. Isn't that one of the many reasons >behind CSS? Once again, do not confuse style with substance. Why not use client side inclusion/scripting/etc.? If you can tell me which browser I am using tonight, then I will give you the golden key. But the problem is, you really can't now can you. You can't tell if I am using a Windows OS, a Mac OS or a different OS again to view web content. I *might* be using a mainstream browser... then again, maybe not. Perhaps I am using an assistive technology, but which one, and why? (or am I?) So how can you be sure that the user agent / machine configuration I am currently using supports client side anything? More importantly, why do you feel you have the right to judge me or the technology I choose to use should I decide to use a combination of technologies which do not support your client side wishes? Do you think omitting key content (@include menu.html... MENU for gosh sakes...)is a positive thing? If I don't get a style sheet... well, too bad, I don't get to see your lime green text on pink and yellow background. (Trust me, I could live without that anyway <grin>). You pose your question, I believe, honestly and in search of a real answer. The simple answer lies in the truth that you cannot know what technologies the end user (your customer) is using, so do not assume that to deliver key content or functionality that *their* machine/system/set-up can deliver client side anything... be sure, and do it from your end, the server end. Key rule of thumb, if it's mission critical, keep it server side. >Again, I may be idealistic, No, not idealistic, but perhaps naive... and I mean no offence. This is not about burying our heads in the sand or wishing to remain in 1996, but rather ensuring that we do not repeat the mistakes of the past. Use the "new" technologies and developments to their full advantage whenever possible, preach the gospel of upgrading to standards compliant user agents, *develop* to the existing standards and encourage all that you work with to do the same. But never lose sight of the fact that content is, was, and always will be king. And from that perspective, I would NEVER do anything that could possibly remove content from my site, least of all relying on a client side solution to deliver it. Cheers! JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca 1.866.932.4878 (North America)
Received on Wednesday, 16 July 2003 00:09:18 UTC