Titanium JIRA Archive
Alloy (ALOY)

[ALOY-89] Platform and form factor specific files for styles

GitHub Issuen/a
TypeTechnical task
PriorityMedium
StatusClosed
ResolutionDuplicate
Resolution Date2012-09-11T15:22:46.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsXML
Labelsn/a
ReporterTony Lukasavage
AssigneeTony Lukasavage
Created2012-07-16T09:12:43.000+0000
Updated2014-01-28T23:28:55.000+0000

Description

We need a format by which we can specify platform and form factor specific files for styles. We also need to define what valid values for form factor are. Here's a couple ideas: * myStyle.ios.tablet.json * myStyle.ios.json * myStyle.tablet.json What should the names of the form factor values be? * tablet, large, screen, etc... for larger form factors * handheld, small, phone, etc... for smaller form factors

Comments

  1. Russell McMahon 2012-07-16

    Looking at the platform sample we should use folders where an entire markup, controller or style file can be put. When targeting the platform then the default file should be replaced with the file in the platform directory. The targets should be what we use for platforms today, "iphone", "ipad", "android", "mobileweb". For mixing styles within a style file we should use media queries see the tasks for adding media query support to Alloy (ALOY-87). Basically we should use the platform, max/min width, pixel density to grab appropriate styles. Defining which device is a handheld, small or a phone could get tricky.
  2. Tony Lukasavage 2012-07-16

    Allowing the flexibility of determining styles based on min/max width/height and pixel density is great, but it introduces some complexity. We need to start establishing a specificity priority now for each of these criteria. For example, say I have a platform-specific, a height-specific, a platform and height-specific, a density-specific, a global, and a class style that all apply to a single element. We need to clearly define the precedence of all style modifiers as a set of rules that makes sense to developers.
  3. Russell McMahon 2012-07-17

    For now can the query attributes be platform, min/max width, and density? For precedence could we use a left to right rule like in regular javascript expression bool expression processing?
  4. Tony Lukasavage 2012-07-17

    We can take a shot at those. I would include min/max height as well. What about orientation? Is that a whole different beast? Probably, since that's the one that would require re-styles of all the elements. It's the only dynamic one. Maybe a separate ticket should be created for that. left to right doesn't solve the problem I posed in the last comment, where multiple styles specifications can apply to one element, each one of those styles having a different level of specificity. We need to identify how those levels of specificity will be prioritized.
  5. Russell McMahon 2012-07-17

    Yup we need height as well. I would keep the levels of specificity as simple as possible. Does it make sense just to have a base then a set of overrides, for example, ".container": { "backgroundColor":"white" } [platform=android] ".container": { "backgroundColor":"blue" } If a rule from top to bottom matches the last rule wins. Later maybe we could use stacking or overlapping. http://zomigi.com/blog/essential-considerations-for-crafting-quality-media-queries/
  6. Russell McMahon 2012-07-17

    We can go through styles one at a time but a better solution is to do it in bulk.
  7. Tony Lukasavage 2012-07-18

    AFAIK, we don't have the option to apply the styles in bulk. That will require changes to the core Titanium API. I'm also concerned about using min/max height/width instead of just specifying a generic "small" or "large" form factor, at least for the first pass. My main reasons for this are: * Height and width depend on orientation, and we weren't planning on handling that yet. If we are going to handle that now, this becomes a bigger task since we would then need to handle dynamic changes to the styles without the ability to apply them in bulk. * It would be *way* easier for developers to simply specify "small" versus "large", or "handheld" versus "tablet". Rules from top to bottom won't make a lot of sense though if more specific rules are at the top. For example: 
       ".container[platform=android,size=small]": {
       "backgroundColor": "#fff"
   }
   ".container[platform=android]": {
       "backgroundColor": "#000"
   }
   ".container[size=small]": {
       "backgroundColor": "#888"
   }
    In the above case on a small, android device, obviously the first case would be the one to apply, but it would get overwritten by less specific styles if we processed from top to bottom. We need to identify the priority of each of the media query criteria as they relate to the identifiers. I propose this: We still apply all relevant styles, but we use the following prioritization to apply then in a specific order. * We already established that in order of precedence: ID > class > Titanium UI component * We could then say that in media queries: platform > size > density ** Normally I would say that "platform" wasn't necessarily more important than the other criteria, but in the world of Titanium, there are potentially platform-specific style parameters that may misbehave on the wrong platform. For this reason, I think it needs to be held above all other criteria to ensure the integrity of the app. I'm not 100% on the order, so I'd love to hear feedback on it. * If there's a tie in these priorities, then the last style takes precedence * The number of criteria in the media query should be irrelevant in determining prioritization, except when the media query criteria are of equal priority. In that case, the highest number of criteria wins. In the below example, the platform style should still overrule the size/dpi style: 
    ".container[platform=ios]": {}, 
   ".container[size=large,dpi=264]": {}
     I also suggest to ensure all this that works as expected, we incorporate testing right off the bat, much like Jeff did in the optimizer code. This will be hellish to debug in a generated project if there's any failings in the prioritization, so a test-driven approach would probably suit us well.
  8. Tony Lukasavage 2012-09-11

    This will be handled by ALOY-246 and ALOY-247.

JSON Source