Talk:Architecture Summit 2014/UI styling

Session: UI Styling -- https://www.mediawiki.org/wiki/Architecture_Summit_2014/UI_styling

Agenda

 * 3 minute lightning talk Grid system
 * 20 minute discussion
 * 3 minute lightning talk Scoping site CSS
 * 20 minute discussion
 * 3 minute lightning talk Allow styling in templates
 * 20 minute discussion

Allow styling in templates
[Jon Robson presenting.] Note problems with multiple skins vs inline styles vs global styles vs site styles -- confusion and madness! Fixed widths/magins play hell with mobile (small screen) there are no media queries in inline styles! Tried to ban inline styles but that didn't fly. ;) Stylesheets associated with a template?.... could this solve some problems? What do we need exactly? Implementation?
 * note CSS audit tool in Chrome is handy -- we tend to load styles that aren't actively used
 * what should it look like for an editor
 * separate namespace?
 * parser function? (trevor says NO)

* tag in the template, extract to header? <- invalidation issues? (invaliding based on template edit could be slow for major templates), parsing/ResourceLoader issues – we'd have to implement a lot of stuff from scratch

* load via ResourceLoader special modules?

* Template:Foo/common.css], [[Template:Foo.css?

** /common.css could be more familiar to editors (and would also function as a normal subpage) and would allow one to provide different styles for different skins (for dark themes, etc.)

* is horrible. But awesome and uncyclopedia can't live without it anymore. Oops.

** but you can share them in shared templates

** but that may make debugging harder

What about scoped CSS? See also template data for VE template editor -- this is done embedded (with a parser hook that saves to page_props table) Could have a combination of embedded styles for simple things *and* separate namespace for shared style modules? Write a good UI and nobody cares about the backend. Except eveyone who has to deal with it. SOLID PREVIEW TOOL PLEASE YES. CAN YOU MAKE IT? (we have the technology) <- check out wikia's theme designer etc for sample ideas? Simple dependencies?
 * HTML5 scoped styles aren't fully supported everywhere (http://caniuse.com/#search=scope ) (are hardly supported, you mean)
 * there are some shims possible though
 * editable LESS variables -> a good place for skin integration (somewhat related: https://bugzilla.wikimedia.org/show_bug.cgi?id=51912 "Make Wikipedia distinct by styling of a prominent UI feature differently than the default")

Template:Foo could depend on Template:Foo.css or Style:Foo.less

Or Template:Infobox Country.css could depend on Template:Infobox.css and Template:Flags.css

RL determines which CSS files templates on a page requested, and adds a module combining them. If templates request the same CSS files multiple times, they are not loaded multiple times.

People already have trouble with gadget dependencies… it might be better to solve this by either using #REDIRECTs or LESS @imports (for importing other wiki pages)

What's complex about gadget dependencies?

Everything, clearly, given how often people break them. Snrk.

Not a lot, and yet they're apparently hard to get right. I've messed up dependencies myslef a few itmes.

Next steps: Jon & friends will lock down some details, code it up...
 * code a prototype
 * make a working beta with sample templates
 * seed some template conversions
 * get feedback
 * no guarantee on scoped styles (but it might be a good idea to look at ways to accomplish similar)
 * PROVISIONAL TIMELINE: TWO MONTHS (arbitrary!)

Scoping site CSS
Right now, every site just has two CSS files for each skin. E.g. Vector has MediaWiki:Common.css and MediaWiki:Vector.css. Common.css is shared for all skins on the wiki. Lots of people can edit those shared pages, can get bloated, confusion can reign. Should we scope things to distinguish content-oriented styles and skin-oriented styles? Should we make it harder/impossible to edit site skin? (Wiki sovereignty rights.... hmmmmm)

or just keep them separate for clarity?

avoid Common.css being a dumping ground?

have a MediaWiki:Content.css with limitations?


 * example adjustments like fonts/sizes for indic & other asian languages -- is there a better way we can manage that?

** core MW does some of that already, in ResourceLoaderUserCSSPrefsModule – still it seems valuable to me to let sites change this (faster deployment cycle etc.)

Better bug reporting system so the fixes can get submitted by non-devs and merged?

avoid framing in terms of who gets to do what; keep it in terms of being able to get specific things done Does this problem mostly go away if we have per-template styles? Only mostly. Namespaces are often styled differently... (yeah, even on mw.org, the Help namespace)

[still need a UI.css and a Content.css or something?]

side note from Trevor: content styles sometimes *should* be used in dialogs that show small bits of content, while content styles can leak into UI. consider avoiding assumption of a single id for all content side note from Christian: Consider side-effects of added specificity to these CSS selectors. (like performance or?) (like breaking other styles – adding '#content' will make the rules have higher specificity / "priority") Possible proposal: * repurpose MediaWiki:Common.css as UI/skin stuff * add MediaWiki:Content.css for generic in-content-area stuff that's not elsewhere tied to templates

If these are functionally identical, one is just going to be unused.

Content.css would be used in mobile view, print output for instance, while Common.css would not.... if i understand correctly

so there may be some visible difference...

Would this be solved by styles in templates as discussed above?

some styles are global -- may not be tied to a template Hm, true. The overlap is still interesting.

Template styles can also vary by skin - a vector theme will be very different from a dark one...

Brion: Reasonable to separate Content.css and UI.css even if they both are still editable on-wiki Trevor: skins having the "same API" based on content IDs and classes is WAY harder than we thought back in the day. Might be much better to treat each skin as its own skin and customize them distinctly. [brion sidebar -> we need better JS APIs for extensions to interact with skin UI] Outcomes: * Common.css will stay * Content.css will arrive and be scoped to or whatever * We will encourage people to use Content.css or per-template styles for their content stuff * ^ Juliusz's RFC etc * let's figure out good ways to help editing & preview -> (who's interested?)

Vertical text

 * Browsers mostly don't quite support it yet (but they're getting there?)

Firefox is the only browser not supporting atm. others are still prefixed


 * CSSJanus will need fixing for vertical (we need language -> rotation map, like we have for directionality, for this (this information is currenlty not in CLDR: http://unicode.org/cldr/trac/browser/trunk/common/properties/scriptMetadata.txt (it wouldn't be too complicated to just put together a list)(some languages can switch too -- Chinese, Japanese, Korean can be horizontal or vertical, and are often vertical in print)(and Mongolian changes direction depending on script.)
 * Talk to Roan & Trevor some time about that
 * Scripts need rotating. style.top becomes style.left, width > height, $.slideUp > $.slideLeft, etc. hopefully some way to make this at least semi-automatic.
 * Having vertical text available for CJK wikis might require automatic rotating of inline styles as well... (-> CSSJanus vertical support :D)