Extending wikilinks syntax

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Extending wikilinks syntax

KALAN-4
Recent studies by Håkon Wium Lie
<http://www.princexml.com/howcome/2009/wikipedia/> clearly show that
XHTML markup generated by widespread templates such as {{coord}} is
overcomplexified. This is mostly what we are able to fix, but
sometimes we aren’t due to the limitations we have created for
ourselves (Håkon simply pointed it out as he couldn’t know the reasons
behind it; this is why having a fresh look is useful). Perhaps the
most serious limitation is:

We don’t allow attributes for wikilinks.

This limitations results in several disadvantages, for example:
* Each time someone wants to style a link, they have to create a
<span> or something else somewhere inside or outside the link text. In
most cases, this is against the semantics and clarity.
* We can’t give ids to links so that we can use them in CSS and JS.
* Implementations of certain microformats (such as XFN, “url” property
in hCard/hCalendar, etc) inside templates is impossible.

I propose to extend wikilinks syntax by making links being parsed the
same way as we parse file-links.

That is, [[Special:Userlogout|log
out|id=logoutlink|style=color:red|title=This will log you out]] will
be a wikilink with style, title and id attributes. The current syntax
is a subset of my proposal, so nothing should break.

As the syntax for external links leaves us no opportunity to clearly
extend it in the same spirit, I currently think of merging it with
external links’ syntax, leaving the current single-brackets for
backward compatibility. Besides these advantages, it will make our
syntax even friendlier (have you seen newbies trying to insert http://
into the double brackets?), and it will make us implicitly prohibit
Protocol://-like titles (they all are erroneous creations by newbies
anyway).

— Kalan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Andrew Dunbar
2009/6/20 Kalan <[hidden email]>:

> Recent studies by Håkon Wium Lie
> <http://www.princexml.com/howcome/2009/wikipedia/> clearly show that
> XHTML markup generated by widespread templates such as {{coord}} is
> overcomplexified. This is mostly what we are able to fix, but
> sometimes we aren’t due to the limitations we have created for
> ourselves (Håkon simply pointed it out as he couldn’t know the reasons
> behind it; this is why having a fresh look is useful). Perhaps the
> most serious limitation is:
>
> We don’t allow attributes for wikilinks.
>
> This limitations results in several disadvantages, for example:
> * Each time someone wants to style a link, they have to create a
> <span> or something else somewhere inside or outside the link text. In
> most cases, this is against the semantics and clarity.
> * We can’t give ids to links so that we can use them in CSS and JS.
> * Implementations of certain microformats (such as XFN, “url” property
> in hCard/hCalendar, etc) inside templates is impossible.
>
> I propose to extend wikilinks syntax by making links being parsed the
> same way as we parse file-links.
>
> That is, [[Special:Userlogout|log
> out|id=logoutlink|style=color:red|title=This will log you out]] will
> be a wikilink with style, title and id attributes. The current syntax
> is a subset of my proposal, so nothing should break.
>
> As the syntax for external links leaves us no opportunity to clearly
> extend it in the same spirit, I currently think of merging it with
> external links’ syntax, leaving the current single-brackets for
> backward compatibility. Besides these advantages, it will make our
> syntax even friendlier (have you seen newbies trying to insert http://
> into the double brackets?), and it will make us implicitly prohibit
> Protocol://-like titles (they all are erroneous creations by newbies
> anyway).

I have to agree we need ways to specify CSS id's and classes for
links from within templates to avoid ugly HTML bloat.
When adding support for them it shouldn't be any extra work to
add support for the other attributes as long as everyone can agree
on a decent syntax.

Andrew Dunbar (hippietrail)

> — Kalan
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
http://wiktionarydev.leuksman.com http://linguaphile.sf.net

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Tim Larson-2
In reply to this post by KALAN-4
I thought the point of wiki syntax was to make things simpler.  By the time
you add support for all these HTML features, you might as well just have
people write the HTML!

I'm not saying that supporting HTML features is bad, mind you.  Just an ironic
observation.


Tim

--
Tim Larson

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Steve Bennett-8
In reply to this post by KALAN-4
On Sat, Jun 20, 2009 at 6:12 PM, Kalan<[hidden email]> wrote:
> We don’t allow attributes for wikilinks.
...

> That is, [[Special:Userlogout|log
> out|id=logoutlink|style=color:red|title=This will log you out]] will
> be a wikilink with style, title and id attributes. The current syntax
> is a subset of my proposal, so nothing should break.

Are there more convincing examples? Wikitext is there to serve up
*content*, not to write the GUI with. It seems normal to me that a
logout link would be written as an http:// style link - not a
wikilink. Similarly, I'm having trouble picturing why a normal
wikilink should be styled with colour or special attributes.

Any better examples of why this would be a good thing? The other
example provided, coord strikes me as exactly the kind of weird
special case (it generally displays in the title area!) that deserves
to generate weird special xhtml...

Steve

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Tue, Jun 23, 2009 at 12:11 AM, Steve Bennett<[hidden email]> wrote:
> Any better examples of why this would be a good thing? The other
> example provided, coord strikes me as exactly the kind of weird
> special case (it generally displays in the title area!) that deserves
> to generate weird special xhtml...

So what's your proposed alternative?  It's either this or allowing raw
<a> in wikitext, as I see it.  Either one is doable.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Steve Bennett-8
On Wed, Jun 24, 2009 at 2:13 AM, Aryeh
Gregor<[hidden email]> wrote:
> So what's your proposed alternative?  It's either this or allowing raw
> <a> in wikitext, as I see it.  Either one is doable.

Whatever it's doing atm. If a weird ugly hack using <span> is what's
required for weird uncommon link formatting, so be it. I'd much rather
be discussing solutions for common problems.

Steve

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Thu, Jun 25, 2009 at 5:33 AM, Steve Bennett<[hidden email]> wrote:
> Whatever it's doing atm. If a weird ugly hack using <span> is what's
> required for weird uncommon link formatting, so be it. I'd much rather
> be discussing solutions for common problems.

Common this definitely is: it's relevant to the overwhelming majority
of pages on Wikipedia, at least if weighted by views.  It affects all
pages with references and most with infoboxes, for instance.  It's not
a *serious* problem, of course, but that doesn't mean we should ignore
it.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

KALAN-4
In reply to this post by Aryeh Gregor
On Tue, Jun 23, 2009 at 12:11 AM, Steve Bennett<[hidden email]> wrote:
> Any better examples of why this would be a good thing? The other
> example provided, coord strikes me as exactly the kind of weird
> special case (it generally displays in the title area!) that deserves
> to generate weird special xhtml...

Styling a link is just an obvious example that makes sense without
additonal explanations. ([[Special:Userlogout]] already works as a
link, nothing has to change here.)

Microformats are a way to include semantical blocks of data (such as
place or time locators, informations about persons, etc) just inside
an XHTML page. They are already used by several browser extensions and
search engines, and more of such usage can take place in future. Read
more about them at http://microformats.org/.

Additionally, making <a>s have their own ids and classes simplifies
userscripts and CSS.

One more fun thing here: the “hreflang” attribute. Google yourself please :)

On Wed, Jun 24, 2009 at 00:13, Aryeh
Gregor<[hidden email]> wrote:
> It's either this or allowing raw
> <a> in wikitext, as I see it.  Either one is doable.

Allowing <a> as other tags is infeasible because every link should be
indexed in `externallinks` table. Adding <a> as an extension tag may
have difficulties when parsing in complicated templates, and
{{#tag:a|...|href=http...|...}} for just a link looks weird. So I am
convinced that my original proposal is better.

By the way, we can allow some attributes for <img> tags, which take
place in microformats too!

— Kalan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Thu, Jun 25, 2009 at 4:18 PM, Kalan<[hidden email]> wrote:
> Allowing <a> as other tags is infeasible because every link should be
> indexed in `externallinks` table.

Sure, so <a> would have to be indexed in the externallinks table too.
That's perfectly doable.

> By the way, we can allow some attributes for <img> tags, which take
> place in microformats too!

Like which?

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

KALAN-4
On Fri, Jun 26, 2009 at 05:25, Aryeh
Gregor<[hidden email]> wrote:
>> Allowing <a> as other tags is infeasible because every link should be
>> indexed in `externallinks` table.
> Sure, so <a> would have to be indexed in the externallinks table too.
> That's perfectly doable.
The only way as I see it is making <a> an extension tag, which has
disadvantages I stated; also, file-like syntax is my personal
preference (<a>s may be used by spammers, by the way...). Anyway, it’s
up to devs (seemingly Tim in particular) to decide.

>> By the way, we can allow some attributes for <img> tags, which take
>> place in microformats too!
> Like which?
http://microformats.org/wiki/hcard has a field for photo.

— Kalan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Thu, Jun 25, 2009 at 5:32 PM, Kalan<[hidden email]> wrote:
> The only way as I see it is making <a> an extension tag

Why?  We'd be doing this in core, not in an extension.  We could just
adjust Parser.php appropriately.

> Anyway, it’s up to devs (seemingly Tim in particular) to decide.

I am a dev.  I've considered doing this, but doubt I'll find the time
in the foreseeable future.  I don't know whether it would be more
complicated to allow <a> or extended wikilinks.  It would be up to
whoever implements it, should it be implemented.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Robert Rohde
On Thu, Jun 25, 2009 at 2:48 PM, Aryeh
Gregor<[hidden email]> wrote:

> On Thu, Jun 25, 2009 at 5:32 PM, Kalan<[hidden email]> wrote:
>> The only way as I see it is making <a> an extension tag
>
> Why?  We'd be doing this in core, not in an extension.  We could just
> adjust Parser.php appropriately.
>
>> Anyway, it’s up to devs (seemingly Tim in particular) to decide.
>
> I am a dev.  I've considered doing this, but doubt I'll find the time
> in the foreseeable future.  I don't know whether it would be more
> complicated to allow <a> or extended wikilinks.  It would be up to
> whoever implements it, should it be implemented.

If we want to maintain the pretense that ordinary articles should be
reasonably accessible to edit, I'd suggest that using <a> is probably
a better choice than extending the wikilink syntax.  It feels more
natural to keep the special cases somewhat segregated in that way from
the ordinary code.

Just my two cents.

-Robert Rohde

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Victor Vasiliev
Robert Rohde wrote:

> On Thu, Jun 25, 2009 at 2:48 PM, Aryeh
> Gregor<[hidden email]> wrote:
>  
>> On Thu, Jun 25, 2009 at 5:32 PM, Kalan<[hidden email]> wrote:
>>    
>>> The only way as I see it is making <a> an extension tag
>>>      
>> Why?  We'd be doing this in core, not in an extension.  We could just
>> adjust Parser.php appropriately.
>>
>>    
>>> Anyway, it’s up to devs (seemingly Tim in particular) to decide.
>>>      
>> I am a dev.  I've considered doing this, but doubt I'll find the time
>> in the foreseeable future.  I don't know whether it would be more
>> complicated to allow <a> or extended wikilinks.  It would be up to
>> whoever implements it, should it be implemented.
>>    
>
> If we want to maintain the pretense that ordinary articles should be
> reasonably accessible to edit, I'd suggest that using <a> is probably
> a better choice than extending the wikilink syntax.  It feels more
> natural to keep the special cases somewhat segregated in that way from
> the ordinary code.
>
> Just my two cents.
>
> -Robert Rohde
>  

I suggest to use <a> for external links extended syntax and parametrized
[[]] for internal links so we can easily distinguish them.
--vvv

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Steve Bennett-8
In reply to this post by Aryeh Gregor
On Thu, Jun 25, 2009 at 11:59 PM, Aryeh
Gregor<[hidden email]> wrote:
> Common this definitely is: it's relevant to the overwhelming majority
> of pages on Wikipedia, at least if weighted by views.  It affects all
> pages with references and most with infoboxes, for instance.  It's not
> a *serious* problem, of course, but that doesn't mean we should ignore
> it.

If weird syntax is used in a template and that template is used
everywhere, that's still a one-off.

Still no one has given an example of weird link features required for
normal internal links.

Steve

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Thu, Jun 25, 2009 at 9:25 PM, Steve Bennett<[hidden email]> wrote:
> If weird syntax is used in a template and that template is used
> everywhere, that's still a one-off.

From the editor's point of view.  Not from the view of the HTML
source, which is what the original proposal was looking at.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Nikola Smolenski
In reply to this post by KALAN-4
Kalan wrote:
> One more fun thing here: the “hreflang” attribute. Google yourself please :)

There's no need to extend syntax for this.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Steve Bennett-8
In reply to this post by Aryeh Gregor
On Fri, Jun 26, 2009 at 12:07 PM, Aryeh
Gregor<[hidden email]> wrote:
>
> From the editor's point of view.  Not from the view of the HTML
> source, which is what the original proposal was looking at.

I guess.

I'm starting to get the initial pangs of an idea that we should have
different kinds of syntax:

1) Article pages should only be allowed simplified syntax: no parser
functions, nothing funky at all. You want to use weird features, you
must wrap it in a template
2) Normal templates can use the full range of existing syntax
3) A limited number of admin-controlled special templates can use an
even wider range of features, including raw HTML.

Then, if you really specific HTML for a very specific, widely used
template, you could, without opening up any cans of worms.

[The benefit from 1) above is less unreadable wikitext in article
space, though I suspect that's fairly limited already, and unreadable
wikitext is mostly from <refs> and massive templates like {{cite}} ]

Steve

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennett<[hidden email]> wrote:
> 3) A limited number of admin-controlled special templates can use an
> even wider range of features, including raw HTML.

Admins are not going to be allowed to insert raw HTML.  At least, not
ordinary admins.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Andrew Garrett-4

On 26/06/2009, at 3:21 PM, Aryeh Gregor wrote:

> On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennett<[hidden email]>  
> wrote:
>> 3) A limited number of admin-controlled special templates can use an
>> even wider range of features, including raw HTML.
>
> Admins are not going to be allowed to insert raw HTML.  At least, not
> ordinary admins.


They already can, with Javascript, so there's no XSS issue.

--
Andrew Garrett
Contract Developer, Wikimedia Foundation
[hidden email]
http://werdn.us




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Extending wikilinks syntax

Aryeh Gregor
On Fri, Jun 26, 2009 at 11:46 AM, Andrew Garrett<[hidden email]> wrote:
> They already can, with Javascript, so there's no XSS issue.

That ability may be removed in the future, and restricted to a smaller
and more select group.  Witness the problems we've been having with
admins including tracking software.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12