Last modified: 2014-04-15 20:03:23 UTC
The Parsoid team is considering a simplification of the different mw:ExtLink/* variants to just a single mw:ExtLink type. For most types this should not make much of a difference to VE, but for auto-numbered external links ([http://example.com]) it might, so I am looking for your input. I did some testing on https://www.mediawiki.org/wiki/User:GWicke/TestNumberedLinks. Changes to the text lead to corruption as in this diff: https://www.mediawiki.org/w/index.php?title=User%3AGWicke%2FTestNumberedLinks&diff=772988&oldid=772987 There also does not seem to be any automatic re-numbering when a numbered link is changed into a plain external link. What are you plans for the handling of numbered links?
Maybe this could even be handled in CSS, somewhat like this example: <html><head> <style> body { color: red; counter-reset: numberedlink; } a[typeof~="mw:ExtLink"]:empty:before { content: "[" counter(numberedlink) "]"; counter-increment: numberedlink; } </style> </head> <body> <a typeof="mw:ExtLink"></a> <a typeof="mw:ExtLink"></a> <a typeof="mw:ExtLink"></a> <a typeof="mw:ExtLink"></a> </body> </html> Problems in this simple experiment: * Links are not clickable, and (maybe related) * the content can only be generated :before and :after, but not inside the empty link.
See http://www.w3.org/TR/css3-content/ for the relevant spec.
With a href set this actually works as expected in FF and Chrome: <html><head> <style> body { counter-reset: numberedlink; } a[typeof~="mw:ExtLink"]:empty:after { content: "[" counter(numberedlink) "]"; counter-increment: numberedlink; } </style> </head> <body> <a href="test" typeof="mw:ExtLink"></a> <a href="test" typeof="mw:ExtLink">not empty</a> <a href="test" typeof="mw:ExtLink"></a> <a href="test" typeof="mw:ExtLink"></a> <a href="test" typeof="mw:ExtLink"></a> </body> </html> So it seems that we can actually implement auto-numbered links in pure CSS.
(In reply to comment #3) > With a href set this actually works as expected in FF and Chrome: […] > So it seems that we can actually implement auto-numbered links in pure CSS. That's great. :-) We will still need a way of creating an auto-numbered external link (rather than just being able to copy and alter them), but that's our problem. :-)
Yeah, you need the UI for the creation of empty links. But there is no need to deal with renumbering etc in VE, which simplifies things a lot. Please test this test with IE as well. I am hopeful that it works with IE >= 8.
(In reply to comment #5) > Please test this test with IE as well. I am hopeful that it works with IE >= > 8. In IE9 you get "not empty" but none of the other four links. In IE10 and IE11 you get all five links as expected.
* Supports: - http://caniuse.com/#feat=css-sel3 (CSS3 :empty) - http://caniuse.com/#feat=css-counters (counter-increment) - http://caniuse.com/#feat=css-gencontent (:before) * Test case: http://jsfiddle.net/wTNc4/ - Works fine in IE9: http://cl.ly/image/2r2L1F3U2X0r I wonder why it didn't work for James?
I guess that means that we can go ahead and drop the explicit numbering in Parsoid in favor of pure CSS. We will also drop the /Numbered typeof suffix along with the other mw:ExtLink suffixes. You will then get empty links with typeof="mw:ExtLink" as in this example.
Change 90432 had a related patch set uploaded by Catrope: Add a node type for numbered external links https://gerrit.wikimedia.org/r/90432
Change 90432 merged by jenkins-bot: Add a node type for numbered external links https://gerrit.wikimedia.org/r/90432
Though the code in Gerrit change #90432 is merged, that just adjusts how VisualEditor works with auto-numbered links to support Parsoid's changed behaviour - this bug remains undone. Resetting to ASSIGNED.
*** Bug 57419 has been marked as a duplicate of this bug. ***
Change 98114 had a related patch set uploaded by Catrope: Make autonumbered external links inspectable https://gerrit.wikimedia.org/r/98114
Change 98114 merged by jenkins-bot: Make autonumbered external links inspectable https://gerrit.wikimedia.org/r/98114
*** Bug 57755 has been marked as a duplicate of this bug. ***
