Talk: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

Grids

Open questions:

Do we want a grid system?
- https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system#What_is_a_grid_system_and_why_is_it_needed.3F
What kind of grid do we want?
How does it relate to the separate skins for mobile (MobileFrontend)?
How does it relate to on-wiki HTML/wikitext?
If content such as tables, images, and templates don't use the grid system, we'll continue to have to use specific references to those elements to make everything responsive.
Is a grid on a skin-by-skin basis or applies to all skins?

Presentation and demo

https://www.youtube.com/watch?v=1eIXvurhoD0 presentation by Pau, length 5m 43s. Can we add this to Commons later? Sure

Break screen into rectangles. Different size rectangles by device size (palm, lap, and desk).
Each element indicates how much space it occupies for each screen size (palm-one-half, lap-two-thirds, etc.)
Semantic classes: size specifications can be at a second level (mixin) of stylesheet in LESS, leaving only the semantic names like 'sidebar' or 'content-area' or whatever in your actual HTML

Grid demo: https://github.com/pauginer/agora-grid/

http://pauginer.github.io/agora-grid/

Christian (Wikia): we also have to consider ads. Proposes only apply a grid to content area instead of the whole skin.
- (Content area will vary depending on what your component is -- content area is good for content; within some other container for a popup dialog or wizard from ane xtension)
Brion: Mobile has both fixed and variable screen sizes.
On-wiki LESS processing a requirement for doing a grid in the way proposed in the RFC? Brion and Trevor say yes, otherwise content like images/tables won't be able to access it.
Proportional (10%) widths rather than pixel (200px) widths for image transclusions?
- How does this impact bandwidth? & server storage / cacheing of thumbnails?
- Does this mean the death of raster graphics?
Struggle between skins and theming and new design artefacts – presentation done by skin vs. wikitext vs. …?
Trevor: Reduce amount of explicit layout control wikitext has. Instead, let the skins do layout?

^ skins could potentially be what defines the grid mappings for classes. They're all blocks of things! Bloc kof sidebar! Block of content! Block of ad!

Wikia: talk to our guys, we have experience with this :D

Note that desktop/tablet is in one skin, mobile is done differently for wikia
roughly similar to what we're doing for now

Next steps

Next steps:

we agree grid is interesting
fixed-width and proportional
grid within content, and grid within skin (but separate grids; keep content distinct)
skin should have more control?
-> Pau & Trevor own this
-> let's try to get some working on-wiki demos in the next couple months!

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!

note CSS audit tool in Chrome is handy -- we tend to load styles that aren't actively used

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?

what should it look like for an editor
- separate namespace?
- parser function? (trevor says NO)
- ??

Implementation?

<style> 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.)
{{#css: .bla {} }} 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?

HTML5 scoped styles aren't fully supported everywhere (http://caniuse.com/#search=scope ) (are hardly supported, you mean)
there are some shims possible though

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?

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")

Simple dependencies?

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

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 <div class="mw-content-text"> 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)