[Foundation-l] [Wikitech-l] Big problem to solve: good WYSIWYG on WMF wikis

[Fred Bauder]

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 <brion at pobox.com> wrote:
>> On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier <robla at 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 at 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 at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>