Commit graph

18 commits

Author SHA1 Message Date
Timo Tijhof a5fe72696b Remove extra <span> from Vector tabs
No longer needed as of I8237976e0587.

Bug: T236410
Change-Id: I5a59c136de4572e5f11b52cc11bc93251c972369
2019-10-25 15:22:57 +00:00
Simon Legner 6b99f35cbe Cleaning a[redundant] is done in BaseTemplate
Relates to I630410aea2852f7a72fea67bbf256b3561ea0f3f.

Change-Id: I0e0ccad14236dfbfc82f38e8e4316a431dd38d7a
2019-08-21 18:03:47 +00:00
Timo Tijhof d56792addb Fix <h1> to be present even if title is "0"
Regression from 74b9803d9a, caused by a bug in LightNCandy which
caused {{foo}} to render "0", and {{#foo}} to pass as true with "0", but then
in {{#foo}}<b>{{foo}}</b>{{/foo} render as empty string producing "<b></b>".
In other words, the conditional is passing and the inner block is executed,
but the placeholder is mistakenly converting "0" => null => "" (empty string),
causing the <h1> to render but without any text in it.

Work around this bug by simply removing the conditional. Several other skins
already don't have this conditional and it's unclear why or in what
situation MediaWiki would send OutputPage to SkinTemplate without a title.

I think it would make sense in such rare case to still have a consistent
layout for extensions and gadgets to interact with and not omit the H1
element, but render it with the value that OutputPage gave it, even if it
is the empty string.

Bug: T219864
Change-Id: I6e04b512d2fe2e949ff5385cb38ceebe392fb255
2019-04-02 19:47:38 +01:00
Jdlrobson 74b9803d9a Start extracting rendering from PHP into Mustache
This reverts commit 8d0377d926
now a conversation has happened.

Bug: T217172
Change-Id: Id51bbd4358bdcc1131c11e13d5548e9c0474e711
2019-03-05 13:22:24 +00:00
Isarra 8d0377d926 Revert "Start extracting rendering from PHP into Mustache"
This reverts commit a3ca2c3e16.

Reason for revert: This requires wider discussion before moving
forward, and a more complete implementation even once we do have
consensus.

No associated task exists on which to view or continue this
discussion: linked task briefly mentions Mustache in general as an
option as part of a much wider topic, but doesn't concern this
specifically.

Issues that should be discussed include:
* What the intent even is here: is this for one skin only? Is this
  the intended path forward for all of them? Depending on which, we
  have other issues: for the former case, that it is quite
  unhelpful in terms of maintenance and further development having
  more random code diversity out there, especially in this
  half-completed state; or if it is indeed intended for all of them,
  that an RfC is needed before anything is merged, as that is a very
  significant change.
* That using Mustache in MediaWiki does add (usually minor)
  performance overhead; we need to clearly establish in the task that
  this is indeed worth it here.

Change-Id: I0bafa55b554aa8a38553e20c75859ec5eec2c062
2019-01-28 16:49:48 +00:00
Timo Tijhof d306e07824 template: Avoid raw HTML parameter for jump link labels
Change-Id: I6c638118988b6fbea95697817edf8c59c0ef6a6b
2019-01-22 21:13:05 -08:00
Timo Tijhof 9cc0ca983c template: Remove is_callable check for getIndicators()
The VectorTemplate class extends BaseTemplate, which has defined
this method since MW 1.25. The Vector skin master branch supports
MW 1.29+ only.

Change-Id: I83c6add9e8c02df028ca5905934e7d367dbe2209
2019-01-22 21:13:05 -08:00
Timo Tijhof a3ca2c3e16 Start extracting rendering from PHP into Mustache
Bug: T140664
Change-Id: I249fead8e1c7bc5dc295457bd46b05e7ed389414
2019-01-22 21:13:05 -08:00
Fomafix c68a21e78a Remove space before Xml::expandAttributes()
Xml::expandAttributes() outputs a space at the beginning before it
outputs the attributs.
This change avoids a double space between the attributes.

Before this change the HTML contains:

  <a class="mw-wiki-logo" href="..."  title="...">

After this change the HTML contains:

  <a class="mw-wiki-logo" href="..." title="...">

Change-Id: I486d26bd56a4410766f40b78466c2f3559f3a1ff
2019-01-14 06:46:33 +01:00
Fomafix 82cbdb8111 Avoid empty class="" without value
Before this change the HTML contains:

<div id="p-personal" role="navigation" class="" ...>
or
<div id="p-personal" role="navigation" class=" emptyPortlet" ...>

After this change the HTML contains:

<div id="p-personal" role="navigation" ...>
or
<div id="p-personal" role="navigation" class="emptyPortlet" ...>

Change-Id: Ic686b958940afc958693d0031ac31e5f783960a9
2019-01-13 20:02:01 +01:00
Volker E da6d4eb280 Remove unnecessary div wrapper on overflow menu
Unordered lists can be absolute positioned down to IE 7.
Outdated selector `.vectorMenu ul` remains for a release cycle
until HTML cache is renewed.

Bug: T209558
Change-Id: Id18ca9a8d705572b1f7e17920ef52b80e9aec373
2018-11-14 20:41:08 -08:00
jenkins-bot 7fd98697f1 Merge "Let Html::element do the output encoding" 2018-06-12 19:52:25 +00:00
Fomafix eccd074386 Let Html::element do the output encoding
Change-Id: I07913d3cd1851df06de912a0257b01a5fae7c125
2018-06-12 16:56:24 +02:00
Fomafix 44fd986540 Use $this->getMsg instead of wfMessage
Change-Id: Ief31c2d9037b5786657507e28ae75b6e467cccb4
2018-06-12 16:39:57 +02:00
Timo Tijhof b843094a2d Re-implement and improve mw-jump links with pure CSS
* Improve their accessibility by giving both links
  a full label "Jump to x" and "Jump to y" instead
  of "Jump to: ", "x", "y".

  This also makes things much better for localisation, for which
  we generally discourage use of concatenation.

* Use pure CSS for the toggling of the visibility on focus,
  instead of relying on JavaScript. Especially given the
  JS comes form core's 'jquery.mw-jump' module, which is
  considered technical debt per T195256. Alternatively,
  that could be copied to vector.js, but pure CSS
  is possible, so why not.

* Use plain <a> links in the HTML instead of wrapped in a <div>.
  This solves the long-standing problem whereby the margin
  between #contentSub and #mw-content-text had to be awkwardly
  negated and overridden in core and on various to make sure that
  the wrapper itself would become visible as needed, in a way that
  has margin around this. This whole problem doesn't apply when
  simply using inline links that aren't part of the regular flow
  with .mixin-screen-reader-text. On focus, the individually
  focussed link appears in regular flow, without the need for
  any custom styles.

* This uses :not(:focus) to naturally make it render in the default
  way on focus, and visibibly hidden/clipped otherwise.
  This is supported in IE9+ and Android 2+.
  There is a way to make it work with CSS2 for IE7-8, by applying
  the mixin to '.mw-jump-link' only and then undoing all of
  'position', 'width', 'height', 'clip', and 'margin' on :focus.
  But I'm not sure that's worth it here. The fallback in IE7-8
  for not supporting ":not(:focus)" is that the accessibility
  link is simply visible always, which seems like a good fallback
  for accessibility, and doesn't hurt anything.

Bug: T195256
Change-Id: Icaadb290f692b3617688d32cbb66dfb007f1c82c
2018-05-24 00:08:02 +00:00
Max Semenik eb145c8ce4 Don't use deprecated Sanitizer::escapeId()
Change-Id: I96354291594f1fcb8a263318e93fd1c059aa006d
2018-04-13 16:30:27 -07:00
Isarra b473ce1ff6 Remove unnecessary $portals['SEARCH'] = true;
Search is skipped in the sidebar 20 lines down regardless. This does
nothing.

Change-Id: If6d3dd21280211fa3511ce010a3f3fda6185a7ef
2018-03-17 18:50:55 +00:00
Timo Tijhof 2fa3b7f69a Move class files to includes/
Cleans up the top-level directory a bit.

Change-Id: I29d3b8b7098def77e643232a386d8ba834d35704
2018-03-12 16:52:48 -07:00
Renamed from VectorTemplate.php (Browse further)