Page MenuHomePhabricator

VML not available to IE
Closed, ResolvedPublic

Description

Author: emmiller

Description:
Vector Markup Language is a way to draw lines in a browser, similar to SVG,
except that it is available in Internet Explorer. VML is required, at least, by
my Google Maps Extension for MediaWiki.[1] However, as described on Microsoft's
site[2], VML must be explicitly enabled with an XML namespace in a page's <html>
tag in order to work in Internet Explorer. For example, a page needs all
instances of:

<html>

Changed to:

<html xmlns:v="urn:schemas-microsoft-com:vml">

Currently, MediaWiki does not have this namespace defined in any skins. I am
attaching a patch that fixes this for MonoBook and derivatives of Skin.php. This
change is non-intrusive to other browsers.

As a side note, right now I have my users hacking the template files themselves,
and this patch will save them a lot of trouble!

  1. http://www.mediawiki.org/wiki/Google_Maps_Extension
  2. http://www.microsoft.com/mind/0100/VML/VML.asp

Version: 1.9.x
Severity: minor

Details

Reference
bz7667

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:25 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz7667.
bzimport added a subscriber: Unknown Object (MLST).

emmiller wrote:

Adds appropriate xmlns attribute to MonoBook.php and OutputPage.php

attachment enable_vml_rev17200.patch ignored as obsolete

VML is non-standard and not supported by any browsers other than IE; we will not use it.

emmiller wrote:

(In reply to comment #2)

VML is non-standard and not supported by any browsers other than IE; we will

not use it.

Other browsers have SVG to provide the same functionality; this patch
essentially brings IE to feature parity with them. I think it'd be a shame to
remain in the vector graphics Stone Age for refusal to support the world's most
popular browser. MediaWiki's skins include non-standard CSS to support IE; why
not change a line of code to support its non-standard vector graphics engine as
well? I'm trying to give my IE users the same features as Firefox users, not
more. Please reconsider.

Well, if IE really is using XML namespaces here you don't need it on the <html> element anyway, as I understand it;
you can simply include the namespace definition on the wrapper element (probably a <div>) for your custom extension's
output.

emmiller wrote:

Nope, unfortunately, I've tried that. I've also tried setting the appropriate
namespace attribute in the <html> tag using JavaScript, but IE has a terribly
hackish implementation here. If it doesn't see that namespace the first time it
reads the <html> tag, it turns off VML irreversibly. I've wrestled with this
problem for a long time, I've scoured the web and the Google Maps API
listserver, and there's just no way around it. I treat this patch as a last
possible resort.

I know it's ugly, I know 99% of wikis won't use it, and I know it's just so
*Microsoft*, but at worst the change is harmless and at best it lets some of us
enjoy the coolness of Google Maps embedded in a wiki. :)

Bleah. :)

Ok, what I'd recommend then is having a way to add arbitrary namespace specifiers onto the root element, sort of a
bastard cousin of $wgMimeType. Custom installations, or extensions, could then add to this array and they'd get spit
out automagically by skins/OutputPage.

Default value might be, say:

$wgXhtmlNamespaces = array(

'' => 'http://www.w3.org/1999/xhtml', // main namespace, no prefix

);

which could then be extended at runtime like:

$wgXhtmlNamespaces['v'] = 'urn:schemas-microsoft-com:vml';

emmiller wrote:

add XHTML namespaces generically

Here's the bastard cousin. :)

I think having an empty string key is a bit kludgy. This patch defines two
variables: $wgXhtmlRootNamespace (defaults to "http://www.w3.org/1999/xhtml")
and $wgXhtmlNamespaces (defaults to an empty array). These are then evaluated
in OutputPage.php and MonoBook.php (by way of SkinTemplate.php, as seems to be
the idiom). Please let me know if I've missed anything, or if there's something
you think should be done differently. Thanks!

Attached:

Good job, commited as r18943.