Page MenuHomePhabricator

Obsolete style attributes like bgcolor are ignored by mobile site
Open, MediumPublic

Description

https://en.wikipedia.org/wiki/User:TheDJ/bgcolor

https://en.m.wikipedia.org/wiki/User:TheDJ/bgcolor (since fixed since table cells no longer have a default background in minerva)

The TD cell should be green. But in the mobile site it is red. This is because bgcolor is deprecated and unlike style="background-color" does not override skin stylesheets.

I think that this is an argument to make the parser/sanitizer start automatically converting these wikicode attributes into proper inline style attributes. Attributes are very easily overridden by CSS styling, and therefore break easily. With divergent skins on multiple platforms (and lets not even talk about the apps, textextract etc) it's increasingly more difficult to know how your authored wikicode content with attributes is going to look like to a reader.


Version: unspecified
Severity: normal
See Also:

Details

Reference
bz66413

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:14 AM
bzimport set Reference to bz66413.
bzimport added a subscriber: Unknown Object (MLST).

The background is white for me. Minerva (the mobile skin) sets the background for *everything* to "none". CSS always overrides old style HTML attributes.

There was a discussion on wether to convert all HTML attributes to CSS, but I can't find it. It mainly concerned tables.

Since these are deprecated, the question should be wether to 1) allow and leave untouched, 2) convert to CSS, or 3) cease support and remove them from the whitelist.

Yeah this is a sort of perennial discussion on this front. basically 'bgcolor' is valid in the wikitext sense, but obsolete as HTML output. So if we can make it 'better' HTML, we probably should. Alternatively we could start thinking about a way to deprecate it in wikitext, but that isn't that easy to do.

Surely Minerva could do [bgcolor] { background-color: attr(bgcolor); } on top of its reset CSS?

We've already had the code to "rewrite" deprecated HTML elements and attributes and it was reverted because it did more harm than good, see bug 40632.

(In reply to Bartosz Dziewoński from comment #3)

Surely Minerva could do [bgcolor] { background-color: attr(bgcolor); } on
top of its reset CSS?

There is a truckload of other old attributes that will need to be handled as well. If we want to keep supporting obsolete attributes, translation to CSS is the only option. Do we have some official specification of what attributes wiki markup is supposed to support?

@Bartosz, well I think we at LEAST should fix the reset skin of the mobile website indeed, to take this problem into account.

But I also never agreed with the full revert of the cleanuppresentationalattributes patch. I still think that for the majority of the attributes it was a sane approach. For align perhaps less so, but that is just one of them. The bigger problem is that we really should start thinking about what we want to do, if obsolete html is starting to cause problems in a newer skin like mobile, we can be sure that there are going to be other places where this is going to be a problem.

Support it in wikicode -> make it work by translating it to modern inline css form.
Don't support it in wikicode -> think about a strategy to get the content fixed.

We really shouldn't be supporting these deprecated and obsolete standards at all. Attempts to save should return to the user that they attempted to use EE element or FF attribute and that is no longer valid and they should use MM element or NN attribute instead.
Doing this will prevent people from maintaining these bad coding habits and when browser do flat out stop supporting them there won't be a bunch of new pages with all kinds of funky funk going on. The only thing left will be mostly archives and rarely used templates or pages which are less likely to be an issue.
Once the inflow of these elements is stopped, then cleaning out the backlog of the old ones that should be updated will be possible.

There is an ongoing RfC about this on enwiki at [[Wikipedia:Village pump (proposals)#RfC: Should deprecated/invalid/unsupported HTML tags be discouraged?]] that would allow softening the transition that should be happening to eliminate these elements from MediaWiki wikis. This discussion shouldn't prevent or hold back discussion on making the core warn/refuse these bad elements as this is something that should be addressed on every project.

Hey everyone, I have no opinion on this. I just knew it was done poorly before and backfired, and wanted anyone who would try doing this again to know this as well. By all means go ahead, and don't CC me on patches. :P

The previous attempt was rushed. I'm willing to take a stab, but I like to inventory which tags and attributes are currently supported, and which ones we want to support.

This will rear it's ugly head soon enough again, Just learned that apparently in the newest version of FF, they will start dropping border=, which will make table cells unbordered, unless they are currently using the wikitable or another defined table class..

I expect complaints of 'broken' content to start streaming in :)

He7d3r set Security to None.

Good! Now we have an actual example of an obsolete attribute being removed from a browser. That will kill any argument claiming "but these attributes still work and will be supported forever!".

This is an excellent oppertunity to kill all obsolete attribs. Maybe translate a few basic attribs, like table align, but I favor just switching to CSS instead and let content break. Presentation is not critical to content anyway, so breaking it should not be detrimental.

I'm a little confused the box is green on mobile in latest Firefox and Chrome on the mobile site.

This specific case was fixed because the skin no longer specifies a 'background' CSS statement (which will always overrides HTML attribute bgcolor's) for wikitables.

The general issue remains however that such attributes are very easily overridden by CSS styling, and that thus break easily and with divergent skins on multiple platforms (and lets not even talk about the apps, textextract etc) it's increasingly more difficult to know if your authored wikicode content is broken or not.

Thanks for clarifying! I agree we should sort this out.

I've been documenting HTML5 output compliance issues at https://www.mediawiki.org/wiki/Parsing/Notes/HTML5_Compliance and ran into this bug report.

ssastry triaged this task as Medium priority.Jan 5 2017, 11:28 PM