There is a community demand in Wikisource to activate the AllowImageTag extension so that we may use the <img> tag in the wikicode - excepting external images. The central discussion is found here:
https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2013-10#To_change_a_configuration_setting_concerning_images
Version: master
Severity: enhancement
URL #2: https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2013-09#More_on_unlocking_images
See Also: T12809
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | Feature | None | T56144 Set $wgAllowImageTag to true on en.wikisource but continue limiting access for only wiki-project hosted files | ||
| Open | None | T56306 img tag attribute src should be managable/restricted |
To enable that configuration variable would cause privacy issues with external images, So that would need to fixed up.
I've read your paragraphs of text, But i'm not seeing how using <img></img> compared to [[File:]] is going to improve anything.
We specifically don't want to link to external sites or use external files. We wish to use <img> with images from the commons and other trusted Wikimedia sites. The extensions can be easily be configured as
https://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages (leave set to 'false') and https://www.mediawiki.org/wiki/Manual:$wgAllowImageTag (change setting to 'true')
I don't think $wgAllowImageTag obeys $wgAllowExternalImages or $wgAllowExternalImagesFrom at the moment. See https://www.mediawiki.org/wiki/Special:Code/MediaWiki/65286#c6617
On 2013-09-16 I received an email signed by Andre Klapper indicating that $wgAllowImageTag is being set to 'true' on Wikisource. Was this implemented already? Thanks.
(In reply to comment #3)
I don't think $wgAllowImageTag obeys $wgAllowExternalImages or
$wgAllowExternalImagesFrom at the moment. See
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/65286#c6617
I have added created bug 54306 as a dependency.
(In reply to comment #4)
On 2013-09-16 I received an email signed by Andre Klapper indicating that
$wgAllowImageTag is being set to 'true' on Wikisource. Was this implemented
already? Thanks.
I cant see wgAllowImageTag in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php .
(In reply to comment #4)
On 2013-09-16 I received an email signed by Andre Klapper indicating that
$wgAllowImageTag is being set to 'true' on Wikisource. Was this implemented
already? Thanks.
No, You received a email from bugzilla when Andre changed the title of this bug report, The same type of email you got when I changed the report title.
Aravind: Please make clear which parts of the URL that MZMcBride pasted are not clear, and which your resulting specific questions are. (On a related note, http://catb.org/~esr/faqs/smart-questions.html might be an interesting read.)
aravikn wrote:
Andre, yet again I'm so sorry. I read through the URL but I did not understand much as I'm a newbie here.
This bug doesn't make sense.
What specific functionality does wikisource want with the <img> tag. The thread at https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2013-10#To_change_a_configuration_setting_concerning_images is confusing. I think he's talking about srcset, but its really unclear. If he is talking about srcset, allowing users access to raw <img> tag is wrong approach.
Note setting up the <img> tag in this way, would break GlobalUsage, and probably make commons unhappy.
Unless the usecase is made clear, I'm inclined to WONTFIX this bug. I'm marking this as stalled until someone explains why wikisource wants this.
This is nothing to do with srcset. The underlying problem is the inability to control the style of the html around the image, which is needed to closely reproduce the original.
some background at
https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2013-09#More_on_unlocking_images
The original issue was partially seeking a way to avoid the srcset "bloat" and partially due to the apparent inability of the IMG tag to successfully inherit certain CSS stylings from the mark-up's default thumb-ish DIV container. This is not all that unexpected because inline level elements rarely inherit such settings from other [parent] inline elements (DIV --> SPAN inherit successful more often than not; DIV --> A --> IMG inherit not so much).
Since the initial thought to request to what amounted to a wiki mark-up-less IMG tag (note: never requesting ability to use that IMG tag for non wiki-hosted image files btw), "we" decide to, again, dump the entire mark-up approach to image files and achieve successful inheritance through a template solution instead.
Template:FreedImg allows both for successful inheritance of "parent" element settings all the way "down" to the IMG tag without triggering srcset at the same time. Simply put, this means one can manipulate any re-size (or similar) change in a browser window and the Image in question will automatically re-size across more than srcsets "waste of time" 1.5 x, 2.0 x or 2.5 x dimensions accordingly.
The trade-off is if the original file has large dimensions, the first click-in loading of that image might take a bit longer than what is comfortable to some but less and less of an issue as technology speeds things up over time. See it in action.... load the test page and then go about re-sizing your browser window -- note how the images are "freed" from the settings imposed by the normal wiki mark-ups image container's scheme, retains the rationale of placing an image in a container in the first place (e.g. floating text to image's left or right) and manage to re-size itself as needed (or not).
Questions?
In closing: Having the IMG tag "back" from wiki mark-up's influence would still help matters on this & other fronts for Wikisource -- just like getting heading elements H1 thru H6 back would - but by no means is anything higher than low-importance/feature request at this point in time.
Is it Wikisource's intent to reproduce the original layout and style of digitised pages? Would that include the font used? I know it's not part of technical discussion, but I imagine there might be some value in separating the content and the presentation from each other.
It sounds like the comments from Wikisource are looking for a way to essentially hardcode the styling (padding, margin, font, border etc.) of each thumbnail. Which would essentially go into the realm of web design and front-end web development instead of authoring content.
I think it'd be interesting to support some level of customisation or theming per-book (somewhat similar to what ePub supports, and what Kindle, and iBooks are doing). E.g. to declare how headings should look for a particular group of pages, as well as a handful of different thumbnails styles perhaps. But doing it all inline is probably not what you really want. It would presumably be rather intrusive to the average contributor. And even for tech-savvy contributors, a lot of tedious repetition and approximation (going to use absolute position and hardcoded line breaks as well to reproduce the same page distribution?).
Setting a text-size relative line length (e.g. 50em) as part of the theme for a book (that, together with the rest of the theme is declared once per book and can be toggled by the reader) would be quite exciting however.