Stewart Stremler wrote: >.. > Well, I should have said "_any_ /particular/ MIME types". My error. > > If I choose to only use text/plain, who are you to go about forcing > application/activex down my throat?
I argue (in agreement) that websites that hide their information in non-text formats or otherwise make the information difficult to retrieve may be doing themselves a disservice, as well as making you and me unhappy. In my opinion text/html has proved to be useful and undeniably successful. Good sites delivering text/html degrade gracefully for (say) lynx users. And text/xhtml or text/xml can also yield text-only content. Serving application/xml is starting to sound like it's trying to go the force feeding route. Don't know how this will develop. One possibility is that text/xml will be understood to be implied by application/xml, but I agree that the application part seem to be a deviation from the simpler web ideas. > > [snip] >>> You might as wish that the W3C would provide better standards; every >>> time I go look at "W3C standards" I start wondering what sort of drugs >>> they're smoking (and why they're on such a power-trip). They're not as >>> bad as ECMA, but still... >> Perhaps not all agree, but I think the W3C standards have been >> enormously successful at resolving the horrors of html incompatibily >> that haunted the good-old v3.0 browser days. > > Not really. They just legitimized various bad habits. I kinda disagree. I see the html (from 3.2 on, and much more so in 4.0) as providing standard mechanisms for achieving what the bad-habits indicated people wanted (for the most part). > >> I think that CSS is really really really good idea, and works fairly >> well. It still needs work, but it sure makes webpage maintenance >> possible rather than black art. If you're not worried about maintenance, >> then it sorta doesn't matter, I guess. > > I have spent more time futzing with CSS than I have in creating content. > This is not a beneficial tradeoff. Why were you worrying about presentation? Just create the content without any fancy styling. Headings, paragraphs lists all do pretty good for simple data without any CSS. See, eg http://www.useit.com/papers/ > > The least maintenance-approach to web-pages seems to be CGI or other > "programs that emit html". Stuff like Blosxom and wikis let the content > creators concentrate on content, and pushes the appearance off to some > code somewhere. Yes, if you need to advance beyond simple stuff, and don't want to do it for a living, then plugging content into a generator is excellent. > > CSS... is just ugly. Plus, the promise that the user can "adjust" > things to suit themselves is not borne out by the implementations in the > browsers. I find CSS less ugly than mixing content with presentation as in the tables-days. It is highly likely that programs that emit html use CSS, because it's easier to write the generator that way. > >> I am convinced that xhtml is the right successor to html, and gets us >> closer to various benefits (including the "semantic web"). Although I >> agree there are some transition pains, it seems to me that the trend >> setters are coping fine, and developing good examples and practices. > > I see an ever-increasing reliance on javascript to accomplish simple > tasks, meaning that everyone is caught up in the red queen's race. It > is a mistake to think that all movement counts as progress. I am in agreement that javascript is very often misused. Some authers write pages that do not load or display properly or whose links do not work with javascript disabled -- yech! :-( I wouldn't treat it as evil, though (just in need of securing). I think there is a definite place for javascript that enriches web capabilities. If you don't need those capabilities (eg, google maps), then you can forgo the interactive parts. It would be nice if all authors paid appropriate attention to graceful degradation. > >> The W3C is bound to suffer the same problems as all standards bodies. >> But I wouldn't give up on standards, and I wouldn't rate W3C as any >> worse than other groups (although I am just speculating on this last >> point, without any firsthand expertise). > > It all depends on whether the standards body is trying to produce a good > standard, or trying to justify their existence. I think the W3C is of > the latter sort. Could be, I guess. I'm sure that many standards groups suffer from that. Anyone else care to voice their opinion on this? > >>>> This goes further to other web developers as well (I admit to my own >>>> laziness at times when just trying to get a page or several pages done >>>> quickly and I skip the standards verification step. >>> So is it a problem with the browser developers or the web developers? >> Standards adherence is a problem with browser developers. Maybe always >> will be, since standards will likely always be evolving. The best they >> can do is attempt to meet standards at given milestones and selectively >> support ongoing improvements. > > Or we should take an axe to many standards and reduce 'em to the > simplest useful subset. In reality, I don't think so. People want newer/better. And producers want people to want newer/better -- and often give it to them before they want it, eh?. If something useful like the web does not continue to evolve along standards-controlled paths, then it will evolve in other ways. I happen to think that the other way may be more chaotic. Perhaps you disagree. > >> Writing valid html (or xhtml or css) is not too hard if you do it for a >> living, or do a lot of it, or just do it for satisfaction. There are >> validators readily available, and while they themselves are imperfect, >> they are _pretty good_. >> http://validator.w3.org/detailed.html >> http://jigsaw.w3.org/css-validator/ > > CSS is just freakin' *tedious* and error-prone. > > Hard, no. Boring, mind-numbing, tedious, counter-intuitive, backwards, > baroque... all of these, yes. > > So, we have tools create it. We collect recipes so that we can crib, > as figuring out the right thing to do is a black art. We divorce the > data -- the content AND the CSS -- from the realm of human- > comprehensible. It gets so complicated we require *tools* to tell us > if it's correct and/or strictly legal. > > Where's the upside again? > > Oh, yeah, it's shiny. > > Can't fight shiny. I'm sorry but I don't understand your point. CSS is unnecessary. Are you griping that others use it? ;-) Maybe you want _some_ shiny, but don't like html or css. Maybe write in lyx and export to html? > >> Checking your code with a validator can be a useful debugging step. > > ...or simply avoid doing anything complicated enough to require a > validator. Well, sure, but there is another benefit to validation. Browsers still attempt to produce useful display even with invalid html. Some might say that xml will make that go away, but I'm guessing not. The difficulty with browsers trying to figure out something reasonable to do with invalid code is that there is no (um) standard for what might be reasonable. Authors benefit by checking for stupid mistakes that might cause unintended content differences for different viewers. > > There are aspects of CSS that are useful and clever. The rest? Bleah. > >> The biggest challenge these days is (still) coping with the remaining >> browser differences, but I am impressed with the suggestion to first >> write valid code, then adapt as required to either achieve acceptable >> appearance on the common browsers, and/or at least fail gracefully (ie, >> to an unstyled appearance). > > That's the wonderful theory, yes. It's generally good advice. > >> Did I mention that I like CSS? > > Did I mention that I'm generally unimpressed with CSS? :) > Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
