Any comments on this before I put it live everywhere?
docs: http://www.mediawiki.org/wiki/Extension:ImageMap demo: http://test.wikipedia.org/wiki/ImageMap
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling wrote:
Any comments on this before I put it live everywhere?
docs: http://www.mediawiki.org/wiki/Extension:ImageMap demo: http://test.wikipedia.org/wiki/ImageMap
Just the comment I already made at http://bugzilla.wikimedia.org/show_bug.cgi?id=1227#c12
"IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view.
What would be slicker would be if we can rig up a visual editor for the thingy; compare with adding notations to images on flickr.
That might end up spitting back the same extension code, or we might integrate it more directly into the image page, or something else. (cf the long-ago talk of having a separate namespace for tables... man I wish we'd done that instead of what we did, it would make a lot of thing simpler)"
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On 1/5/07, Brion Vibber brion@pobox.com wrote:
"IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view.
The syntax lacks discoverability, which could be addressed by making it more verbose. Beyond that, I don't think the deficiencies of our general approach to extensions should be held against this particular one.
What could be a long term solution? Perhaps a combination of the following: a) a general namespace devoted to syntax that is passed to extensions, e.g., Render: b) a hook mechanism that makes it possible to define a frontend for creating or updating data of a particular type (extension tag).
When following a red link to e.g. [[Render:Timeline US history]], one would be taken to a selection box to choose the extension which should be used for rendering. If a frontend is defined for that extension, one could use it to create (and later edit) the timeline. But when editing such a page, one could also switch to "Edit source" mode to modify the extension code directly, and that would be the only mode available if no front-end is given.
In such a model, tables could be turned into an extension. Their frequent interaction with templates would complicate things, however.
Brion Vibber wrote:
Tim Starling wrote:
Any comments on this before I put it live everywhere?
docs: http://www.mediawiki.org/wiki/Extension:ImageMap demo: http://test.wikipedia.org/wiki/ImageMap
Just the comment I already made at http://bugzilla.wikimedia.org/show_bug.cgi?id=1227#c12
"IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view.
What would be slicker would be if we can rig up a visual editor for the thingy; compare with adding notations to images on flickr.
That might end up spitting back the same extension code, or we might integrate it more directly into the image page, or something else. (cf the long-ago talk of having a separate namespace for tables... man I wish we'd done that instead of what we did, it would make a lot of thing simpler)"
Yes, the user interface sucks. I was aiming with this extension to implement image maps in a manner consistent with the rest of MediaWiki -- a robust implementation but limited in scope. It sucks as much as everything else we have.
So do you want it or don't you? I'm not writing a visual editor right now, so unless anyone else wants to step forward, it's this or nothing. Will the extension be a help or a hindrance when we get around to revolutionising MediaWiki's ease of use?
-- Tim Starling
Tim Starling-2 wrote:
Brion Vibber wrote:
"IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view. What would be slicker would be if we can rig up a visual editor for the thingy; compare with adding notations to images on flickr.
Yes, the user interface sucks. I was aiming with this extension to implement image maps in a manner consistent with the rest of MediaWiki -- a robust implementation but limited in scope. It sucks as much as everything else we have.
Think of it as incremental development: we get the code up and running, prove that it can cope with every stupid thing that anybody is likely to throw at it, and a nice pretty interface can be added later.
So do you want it or don't you? I'm not writing a visual editor right now, so unless anyone else wants to step forward, it's this or nothing. Will the extension be a help or a hindrance when we get around to revolutionising MediaWiki's ease of use?
It's got my vote. Am I safe in thinking this might well be a good way to put the dreaded {{click}} template to rest?
HTH HAND
On 05/01/07, Phil Boswell phil.boswell@gmail.com wrote:
It's got my vote. Am I safe in thinking this might well be a good way to put the dreaded {{click}} template to rest?
That came to mind when I was messing about with it, too.
Rob Church
Rob Church wrote:
On 05/01/07, Phil Boswell phil.boswell@gmail.com wrote:
It's got my vote. Am I safe in thinking this might well be a good way to put the dreaded {{click}} template to rest?
That came to mind when I was messing about with it, too.
It would be nice to have some simpler syntax for that particular case. It's probably better than {{click}}, but it still lacks elegance.
Also I think to replace {{click}} it would need a portable implementation of the "default" directive.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling wrote:
So do you want it or don't you? I'm not writing a visual editor right now, so unless anyone else wants to step forward, it's this or nothing. Will the extension be a help or a hindrance when we get around to revolutionising MediaWiki's ease of use?
It'll probably do for now, I just hate knowing we'll have to keep it around forever for compatibility. ;)
- -- brion vibber (brion @ pobox.com)
On 05/01/07, Tim Starling tstarling@wikimedia.org wrote:
Any comments on this before I put it live everywhere?
I feel like a total doofus, but how do you give coordinates for four corners (in rect) using four single numbers?? The order must be significant, but the documentation doesn't say what it should be. Likewise with poly, how are the numbers interpreted as coords exactly?
thanks, Brianna user:pfctdayelise
On 1/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 05/01/07, Tim Starling tstarling@wikimedia.org wrote:
Any comments on this before I put it live everywhere?
I feel like a total doofus, but how do you give coordinates for four corners (in rect) using four single numbers?? The order must be significant, but the documentation doesn't say what it should be. Likewise with poly, how are the numbers interpreted as coords exactly?
It's all specified in the HTML specifications: http://www.w3.org/TR/html4/struct/objects.html#h-13.6. Rectangles are determined by just two points, and pair of opposing corners, so four numbers make sense for that. More specifically: for rectangles it's left-x, top-y, right-x, bottom-y; for circles it's center-x, center-y, radius; and for polygons it's just the x, y coordinates of each point in turn. All coordinates are relative to the top left pixel, which is 0, 0.
On 05/01/07, Simetrical Simetrical+wikitech@gmail.com wrote:
It's all specified in the HTML specifications: http://www.w3.org/TR/html4/struct/objects.html#h-13.6. Rectangles are determined by just two points, and pair of opposing corners, so four numbers make sense for that. More specifically: for rectangles it's left-x, top-y, right-x, bottom-y; for circles it's center-x, center-y, radius; and for polygons it's just the x, y coordinates of each point in turn. All coordinates are relative to the top left pixel, which is 0, 0.
That's wonderful; I'm glad we have a clear specification document with which to...ah, but it's implemented? Hm.
That someone had to ask how to use the feature indicates that we need much clearer documentation, perhaps with a tutorial and a few nice diagrams.
Volunteers?
Rob Church
On 05/01/07, Simetrical Simetrical+wikitech@gmail.com wrote:
On 1/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 05/01/07, Tim Starling tstarling@wikimedia.org wrote:
Any comments on this before I put it live everywhere?
I feel like a total doofus, but how do you give coordinates for four corners (in rect) using four single numbers?? The order must be significant, but the documentation doesn't say what it should be. Likewise with poly, how are the numbers interpreted as coords exactly?
It's all specified in the HTML specifications: http://www.w3.org/TR/html4/struct/objects.html#h-13.6. Rectangles are determined by just two points, and pair of opposing corners, so four numbers make sense for that. More specifically: for rectangles it's left-x, top-y, right-x, bottom-y; for circles it's center-x, center-y, radius; and for polygons it's just the x, y coordinates of each point in turn. All coordinates are relative to the top left pixel, which is 0, 0.
Oh, well why didn't I think to look there? :P
I actually guessed right, but was confused because it didn't appear to work. I had my "default" line before my "rect" line, and then my rect was ignored and just the default link applied everywhere. Is that desirable?
cheers, Brianna
On 1/4/07, Simetrical Simetrical+wikitech@gmail.com wrote:
On 1/4/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 05/01/07, Tim Starling tstarling@wikimedia.org wrote:
Any comments on this before I put it live everywhere?
I feel like a total doofus, but how do you give coordinates for four corners (in rect) using four single numbers?? The order must be significant, but the documentation doesn't say what it should be. Likewise with poly, how are the numbers interpreted as coords exactly?
It's all specified in the HTML specifications: http://www.w3.org/TR/html4/struct/objects.html#h-13.6.
Sorry again for what may be a naive question, but if you're going to use HTML semantics why not just use HTML?
Any parser of wikitext at this point must understand HTML anyway, and doubly so for a renderer. I appreciate that other wiki markup intends to make the text more human-friendly, but in this particular instance I suppose it's not really possible to make image coordinates human friendly, and the proposed syntax has a one-to-one correspondence with "more complicated" HTML but with a syntax nobody has seen before.
Evan Martin wrote:
Sorry again for what may be a naive question, but if you're going to use HTML semantics why not just use HTML?
Any parser of wikitext at this point must understand HTML anyway, and doubly so for a renderer. I appreciate that other wiki markup intends to make the text more human-friendly, but in this particular instance I suppose it's not really possible to make image coordinates human friendly, and the proposed syntax has a one-to-one correspondence with "more complicated" HTML but with a syntax nobody has seen before.
Mainly because HTML requires URLs. We don't use those. Also the HTML can get quite complicated, for instance, on my test wiki, this:
<imagemap> Image:Test1.jpg|thumb|200px|hello rect 0 0 50 50 [[Image:Test1.jpg|test1]] </imagemap>
becomes:
<map name="ImageMap_1"><area shape="rect" href="/w2/index.php/Image:Test1.jpg" coords="0,0,25.6313131313,25.6313131313" alt="test1" title="test1" /></map><div class="thumb tright"><div class="thumbinner" style="width:202px;"><div style="position: relative;"><img src="/w2/images/thumb/f/f8/Test1.jpg/200px-Test1.jpg" alt="hello" width="200" height="206" longdesc="/w2/index.php/Image:Test1.jpg" class="thumbimage" usemap="#ImageMap_1"/></div> <div class="thumbcaption"><div class="magnify" style="float:right"><a href="/w2/index.php/Image:Test1.jpg" class="internal" title="Enlarge"><img src="/w2/skins/common/images/magnify-clip.png" width="15" height="11" alt=""/></a></div>hello</div></div></div>
Using ImageMap you get all the complexity of MediaWiki image links for free.
-- Tim Starling
On 1/4/07, Tim Starling tstarling@wikimedia.org wrote:
Any comments on this before I put it live everywhere?
docs: http://www.mediawiki.org/wiki/Extension:ImageMap demo: http://test.wikipedia.org/wiki/ImageMap
-- Tim Starling
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Is it a good idea to allow the user to not have the desc page link at all? That's one of the reasons {{click}} is bad, since so many images are CC-BY or GFDL and need the link to comply with the licenses.
Rory Stolzenberg wrote:
Is it a good idea to allow the user to not have the desc page link at all? That's one of the reasons {{click}} is bad, since so many images are CC-BY or GFDL and need the link to comply with the licenses.
If I leave out the option, someone will write a JavaScript/CSS hack to hide the link, 5 seconds after it goes live. With the feature included, the security is no worse, but the ease of use and portability are better.
-- Tim Starling
On 05/01/07, Rory Stolzenberg rory096@gmail.com wrote:
Is it a good idea to allow the user to not have the desc page link at all? That's one of the reasons {{click}} is bad, since so many images are CC-BY or GFDL and need the link to comply with the licenses.
There is nothing wrong in providing a feature for users to use. Provided, that is, that the user base knows when it's appropriate to use an image, and when it's not.
If a user wants to know the licencing information for an image, s/he can access the image description page, where this information is held. It is acceptable, however, for us to use free-licenced images to beef up our interface...we're not deliberately obscuring access to the licence information at all.
Ultimately, like a lot of our features, it comes down to trusting the user base to use what we've provided in a sane and legal fashion. If we couldn't do that, and if we couldn't trust the users to also do some self-policing of wikis...well, we wouldn't have *editing*, let alone image uploads or usage...and then where would we be?
Rob Church
wikitech-l@lists.wikimedia.org