Right. Wikipedia is about interesting and useful information, not about coding.
Fred Bauder > Really good points. I still advocate moving the possibility for these > "ugly" constructs to templates, so that we keep all the magic tricks > we have now, but lose the ability to make an article that is "write > only" by littering it with code that only the wikigods and the parser > itself could decypher. > > Well-formedness checks would be a huge step forward - if the edit form > could catch showstoppers like mismatched braces , brackets, quotes, > and even misused templates it would go a long way towards making the > site safe to edit. > > As for all the deep magic, like parser functions, inline html, and the > like, why do we even need to allow the parser to recognize such > nonsense in article space. Treat templates as a special case and be > rid of just about everything thats not on the editing toolbar. > > There will be some people upset that they cant turn an article into an > elaborate html and css work of art but they will get over it and go > back to writing articles, or if they didn't have any interest in doing > that they will go back to myspace. Either way net gain - article code > becomes readable and we promote the development and expansion of > freely available content, which is the real business we are in. > > On 12/29/10, Brion Vibber <br...@pobox.com> wrote: >> On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier <ro...@wikimedia.org> >> wrote: >> >>> Let me riff on what you're saying here (partly just to confirm that I >>> understand fully what you're saying). It'd be very cool to have the >>> ability to declare a single article, or probably more helpfully, a >>> single revision of an article to use a completely different syntax. >>> >> >> Yes, though I'd recommend jettisoning the word "syntax" entirely from >> the >> discussion at this stage, as I worry it distracts towards bikeshedding >> about >> unimportant details. >> >> Rather, it could be more useful to primarily think of data resources >> having >> "features" or "structure". With images for instance, we don't make >> people >> pay too much attention about whether something's in JPEG, PNG, GIF, or >> SVG >> format. >> >> At the level of actual people working with the system, the file's >> *format* >> is completely unimportant -- only its features and metadata are >> relevant. >> Set a size, give a caption, specify a page if it's a paged format, or a >> time >> if it's a video format. Is it TIFF or PDF? Ogg Theora or WebM? Don't >> know, >> don't care, and any time a user has to worry about it we've let them >> down. >> >> We need to think about similarly concentrating on document structure >> rather >> than markup syntax for text pages. >> >> >> I definitely agree that the idea of progressively moving bits and >> pieces in >> that direction is a wise one. If we can devise a *document structure* >> that >> lets us embed magic templatey _things_ into a paragraph-oriented-text >> document and maintain their structural identity all the way to >> browser-ready >> HTML and back, then we can have a useful migration path: >> >> * identify possibly unsafe uses of templates, extensions, and >> parserfunctions (machines are great at this!) >> * clean them up bit by bit (bots are often good at many common cases) >> * once a page can be confirmed as not using Weird Template Magic, but >> only >> using templates/images/plugins that fit within the structure, it's >> golden. >> * depending on which flavor of overlords we have, we might have various >> ways >> of enforcing that a page will always *remain* well-structured from then >> on. >> >> That might not even involve changing syntax per se -- we shouldn't care >> too >> much about whether italic is <i> or ''. But knowing where a table or a >> div >> block starts and ends reliably is extremely important to being able to >> tell >> which part of your document is which. >> >> >> And heck, even if not everything gets fixed along that kind of path, >> just >> being able to *have* pages and other resource types that *are* >> well-structured mixed into the system is going to be hugely useful for >> the >> non-Wikipedia projects. >> >> -- brion vibber (brion @ pobox.com) >> _______________________________________________ >> foundation-l mailing list >> foundation-l@lists.wikimedia.org >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >> > > > -- > Faith is about what you really truly believe in, not about what you are > taught to believe. > > _______________________________________________ > foundation-l mailing list > foundation-l@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l