{
	"id": "97350",
	"key": "ALOY-89",
	"fields": {
		"issuetype": {
			"id": "8",
			"description": "A technical task.",
			"name": "Technical task",
			"subtask": true
		},
		"parent": {
			"id": "97343",
			"key": "ALOY-87",
			"fields": {
				"summary": "Platform and form factor specific styling, like media queries",
				"status": {
					"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
					"name": "Resolved",
					"id": "5",
					"statusCategory": {
						"id": 3,
						"key": "done",
						"colorName": "green",
						"name": "Done"
					}
				},
				"priority": {
					"name": "High",
					"id": "2"
				},
				"issuetype": {
					"id": "7",
					"description": "gh.issue.story.desc",
					"name": "Story",
					"subtask": false
				}
			}
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [],
		"resolution": {
			"id": "3",
			"description": "The problem is a duplicate of an existing issue.",
			"name": "Duplicate"
		},
		"resolutiondate": "2012-09-11T15:22:46.000+0000",
		"created": "2012-07-16T09:12:43.000+0000",
		"priority": {
			"name": "Medium",
			"id": "3"
		},
		"labels": [],
		"versions": [],
		"issuelinks": [
			{
				"id": "18970",
				"type": {
					"id": "10020",
					"name": "Depends",
					"inward": "is dependent of",
					"outward": "depends on"
				},
				"outwardIssue": {
					"id": "97499",
					"key": "TIMOB-10007",
					"fields": {
						"summary": "TiAPI: Be able to set a group of adhoc properties to any proxy at runtime - see description",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "High",
							"id": "2"
						},
						"issuetype": {
							"id": "7",
							"description": "gh.issue.story.desc",
							"name": "Story",
							"subtask": false
						}
					}
				}
			}
		],
		"assignee": {
			"name": "tlukasavage",
			"key": "tlukasavage",
			"displayName": "Tony Lukasavage",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"updated": "2014-01-28T23:28:55.000+0000",
		"status": {
			"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
			"name": "Closed",
			"id": "6",
			"statusCategory": {
				"id": 3,
				"key": "done",
				"colorName": "green",
				"name": "Done"
			}
		},
		"components": [
			{
				"id": "12326",
				"name": "XML",
				"description": "View XML and parsing"
			}
		],
		"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.\r\n\r\nHere's a couple ideas:\r\n\r\n* myStyle.ios.tablet.json\r\n* myStyle.ios.json\r\n* myStyle.tablet.json\r\n\r\nWhat should the names of the form factor values be? \r\n\r\n* tablet, large, screen, etc... for larger form factors\r\n* handheld, small, phone, etc... for smaller form factors",
		"attachment": [],
		"flagged": false,
		"summary": "Platform and form factor specific files for styles",
		"creator": {
			"name": "tlukasavage",
			"key": "tlukasavage",
			"displayName": "Tony Lukasavage",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "tlukasavage",
			"key": "tlukasavage",
			"displayName": "Tony Lukasavage",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "207805",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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\".\r\n\r\nFor 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.  \r\n",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-16T13:51:03.000+0000",
					"updated": "2012-07-16T13:57:49.000+0000"
				},
				{
					"id": "207808",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-16T14:04:07.000+0000",
					"updated": "2012-07-16T14:04:07.000+0000"
				},
				{
					"id": "208202",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "For now can the query attributes be platform, min/max width, and density?\r\n\r\nFor precedence could we use a left to right rule like in regular javascript expression bool expression processing?",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-17T16:23:48.000+0000",
					"updated": "2012-07-17T16:23:48.000+0000"
				},
				{
					"id": "208208",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.\r\n\r\nleft 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.\r\n\r\n",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-17T16:29:33.000+0000",
					"updated": "2012-07-17T16:29:33.000+0000"
				},
				{
					"id": "208238",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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,\r\n\r\n\r\n\".container\": {\r\n\t\t\"backgroundColor\":\"white\"\r\n\t}\r\n[platform=android]\r\n\".container\": {\r\n\t\t\"backgroundColor\":\"blue\"\r\n\t}\r\n\r\nIf a rule from top to bottom matches the last rule wins.\r\n\r\nLater maybe we could use stacking or overlapping.\r\nhttp://zomigi.com/blog/essential-considerations-for-crafting-quality-media-queries/",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-17T23:30:56.000+0000",
					"updated": "2012-07-17T23:30:56.000+0000"
				},
				{
					"id": "208239",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "We can go through styles one at a time but a better solution is to do it in bulk.",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-17T23:38:24.000+0000",
					"updated": "2012-07-17T23:38:24.000+0000"
				},
				{
					"id": "208269",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "AFAIK, we don't have the option to apply the styles in bulk. That will require changes to the core Titanium API.\r\n\r\nI'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:\r\n\r\n* 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.\r\n* It would be *way* easier for developers to simply specify \"small\" versus \"large\", or \"handheld\" versus \"tablet\".\r\n\r\nRules from top to bottom won't make a lot of sense though if more specific rules are at the top. For example:\r\n\r\n{code:javascript}\r\n\".container[platform=android,size=small]\": {\r\n    \"backgroundColor\": \"#fff\"\r\n}\r\n\".container[platform=android]\": {\r\n    \"backgroundColor\": \"#000\"\r\n}\r\n\".container[size=small]\": {\r\n    \"backgroundColor\": \"#888\"\r\n}\r\n{code}\r\n\r\nIn 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.\r\n\r\nI propose this: We still apply all relevant styles, but we use the following prioritization to apply then in a specific order.\r\n\r\n* We already established that in order of precedence: ID > class > Titanium UI component\r\n* We could then say that in media queries: platform > size > density\r\n** 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. \r\n* If there's a tie in these priorities, then the last style takes precedence\r\n* 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:\r\n{code:javascript}\".container[platform=ios]\": {}, \r\n\".container[size=large,dpi=264]\": {}{code} \r\n\r\nI 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.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-18T05:49:23.000+0000",
					"updated": "2012-07-18T05:59:35.000+0000"
				},
				{
					"id": "218457",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "This will be handled by ALOY-246 and ALOY-247. ",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-09-11T15:22:46.000+0000",
					"updated": "2012-09-11T15:22:46.000+0000"
				}
			],
			"maxResults": 8,
			"total": 8,
			"startAt": 0
		}
	}
}