Page MenuHomePhabricator

Inline styles: Wikipedia:Contact us page is horribly formatted - new contact/feedback page
Closed, ResolvedPublic


The footer is shown near the top

Bullet point lines are shown in the middle of the page, and only one word per line

Version: unspecified
Severity: normal


TitleReferenceAuthorSource BranchDest Branch
Exclude Wiktionary main namespacerepos/commtech/autosuggest-sitelink!54samwilsonexclude-wiktionarymain
Remove Wikisource 'Index' namespacerepos/commtech/autosuggest-sitelink!41samwilsonno-index-nsmain
Exclude Wikisource's Page namespacerepos/commtech/autosuggest-sitelink!38samwilsonexclude-page-nsmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:50 PM
bzimport set Reference to bz31591.
bzimport added a subscriber: Unknown Object (MLST).

IIRC it's pulling up a non-mobile-formatted view and it renders pretty badly in the tiny iframe.

Yes. This is going to require some content work to make it mobile friendly. Any objection to opening up a content component ?

(In reply to comment #2)

Yes. This is going to require some content work to make it mobile friendly. Any
objection to opening up a content component ?

Seems sensible..

philinje wrote:

Other UI work will likely result in not fixing this, but providing a button to a new contact/feedback page.

The problem is inline styles in the contact page.
I'm not sure how we get round this sort of thing (which I'm noticing a lot on the mobile site where pages assume they are always on desktop - also see bug 30406)

One possible solution I can think of is scrubbing inline styles of any element marked with a class no-mobile-styling which would empower admins a generic way to fix this sort of thing.

A second solution (at least for this page) would be to force a redirect to the desktop site, especially taking Phil's comments and [1] into account.



So there are two separate issues here.

  1. two column layouts suck on mobile. we need to restyle these anytime it happens. on any page
  2. the current contact us page is not actually useful for a mobile device. the only points that make any sense right now to keep are article quality related.

Let's move forward with the ideas in the contact us form and then table the two column layout discussion for now.

philinje wrote:

Just to clarify, the new Contact form is a highly condensed form of this page, intended to simplify and reduce the actions a user could take. So the new page is all the user would see in Mobile View. The Contact page on the main site would only appear in Desktop View. In the case of this page, it would be nice if we could force a re-direct to the Mobile View (formatting issues aside)!

The problem is that these 2 column layouts are hard to detect as they use inline styles rather than styling via Common.css . I would suggest some refactoring of the content rather than changing the mobile site to deal with this.

I'm not so keen on the idea of a redirect. is not the same as the new contact form. They are separate pages. If I link to Wikipedia:Contact_us in an article there may be a good reason. For example I might write in an article 'To report a copyright violation see the other matters section on the [[Wikipedia::Contact_us|Contact us]] page. If the user is then redirected to the mobile page this sentence no longer carries meaning. It is for that reason I think that instead of redirecting we should simply ensure that when users go to they always get the desktop site. This is my opinion is the right thing to do.

(.. or if we can sort out the 2 column layout problem via common.css and class changes do not force the redirect at all and show them the normal contact us page)

philinje wrote:

Sorry Jon, I was making the point about re-direction in jest. Hence the exclamation point. You are right, we need to deal with inline styles in general, but probably not in the context of this bug.

It might be a good idea to open a new bug about inline styles, especially as they pertain to 2-column layouts.

I think you posted the wrong bug Tomasz that points to this one!

(In reply to comment #12)

I think you posted the wrong bug Tomasz that points to this one!

FAIL! :)

Marking this as another example of inline styling problems see bug 35704