Consider the following Lua code:
local styles = { 'border-left-color', 'purple' }
local box = mw.html.create('div')
:css(styles)
:css('border', '1px solid white')
:css('border-left-color', 'brown')The expected behavior is that the color of the element's left border will be brown, however it will be white. The new value 'brown' of the 'border-left-color' property will replace the old one 'purple', but will remain "above" the declaration of the shorthand 'border'. When the object will be converted into a string, the output would be
<div style="border-left-color:brown; border:1px solid white;"></div>
The issue comes from lines 358-373 in mw.html.lua, which look to find whether that property is already used and if so - replace the value in it's current position. The code should probably be changed to:
for i, prop in ipairs( t.styles ) do
if prop.name == name then
table.remove( t.styles, i )
break
end
end
if val ~= nil then
table.insert( t.styles, { name = name, val = val } )
end
return tIt should be also noted that when storing shorthand and longhand contradicting values in one table and passing it to mw.html:css, for example
local styles = {
['border'] = '1px solid white',
['border-left-color'] = 'brown'
}
local box = mw.html.create('div'):css(styles)the order of the properties in the results is undefined, since named fields in a Lua table have no defined order. It may in practice match the order of the code in most cases, but can break randomly. This limitation, however, seems inherent and the only way around it seems to be not passing a single table with contradicting shorthand and longhand CSS properties.