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
2009/6/20 Kalan kalan.001@gmail.com:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
On Sat, Jun 20, 2009 at 6:12 PM, Kalankalan.001@gmail.com 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
On Tue, Jun 23, 2009 at 12:11 AM, Steve Bennettstevagewp@gmail.com 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.
On Wed, Jun 24, 2009 at 2:13 AM, Aryeh GregorSimetrical+wikilist@gmail.com 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
On Thu, Jun 25, 2009 at 5:33 AM, Steve Bennettstevagewp@gmail.com 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.
On Thu, Jun 25, 2009 at 11:59 PM, Aryeh GregorSimetrical+wikilist@gmail.com 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
On Thu, Jun 25, 2009 at 9:25 PM, Steve Bennettstevagewp@gmail.com 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.
On Fri, Jun 26, 2009 at 12:07 PM, Aryeh GregorSimetrical+wikilist@gmail.com 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
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennettstevagewp@gmail.com wrote:
- 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.
On 26/06/2009, at 3:21 PM, Aryeh Gregor wrote:
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennettstevagewp@gmail.com wrote:
- 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 agarrett@wikimedia.org http://werdn.us
On Fri, Jun 26, 2009 at 11:46 AM, Andrew Garrettagarrett@wikimedia.org 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.
On Sat, Jun 27, 2009 at 12:21 AM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
On Fri, Jun 26, 2009 at 8:22 AM, Steve Bennettstevagewp@gmail.com wrote:
- 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.
Yeah, bad use of word. I did assume it would be a small group of HTML-trusted editors, not the thousand-odd admins we have, who could do this.
Steve
On Tue, Jun 23, 2009 at 12:11 AM, Steve Bennettstevagewp@gmail.com 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 GregorSimetrical+wikilist@gmail.com 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
On Thu, Jun 25, 2009 at 4:18 PM, Kalankalan.001@gmail.com 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?
On Fri, Jun 26, 2009 at 05:25, Aryeh GregorSimetrical+wikilist@gmail.com 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
On Thu, Jun 25, 2009 at 5:32 PM, Kalankalan.001@gmail.com 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.
On Thu, Jun 25, 2009 at 2:48 PM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
On Thu, Jun 25, 2009 at 5:32 PM, Kalankalan.001@gmail.com 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
Robert Rohde wrote:
On Thu, Jun 25, 2009 at 2:48 PM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
On Thu, Jun 25, 2009 at 5:32 PM, Kalankalan.001@gmail.com 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
Victor Vasiliev wrote:
I suggest to use <a> for external links extended syntax and parametrized [[]] for internal links so we can easily distinguish them. --vvv
Kalan explained it "<a>s may be used by spammers, by the way."
A talk page gets added the text 'This page explains it <i>pretty well</i> <a href="http://example.com">some webpage</a>'
Currently, you see the html garbage, realise at first sight that it's a spambot and revert. If <a> were an accepted syntax, you would doubt if it's spam or a person trying to use wikisyntax.
It's sad not being able to use the logical tag, but I oppose making valid the spammers messages.
wikitech-l@lists.wikimedia.org