| 2013-10-22 14:46:59 |
Kyle Nitzsche |
bug |
|
|
added bug |
| 2013-10-22 14:48:25 |
Kyle Nitzsche |
description |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes fore pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no sing there's no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuU class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes for pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no sing there's no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuU class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
|
| 2013-10-22 14:49:05 |
Kyle Nitzsche |
description |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes for pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no sing there's no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuU class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes for pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuU class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
|
| 2013-10-22 14:50:12 |
Kyle Nitzsche |
description |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes for pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuU class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
We currently have two places where Ubuntu HTML "widgets" are implemented: JavaScript and CSS. Some widgets exist in JavaScript and in CSS, but some only exist in CSS with no corresponding JavaScript class.
For example, we have shape.css that uses a selector that assumes the shape is declared like this: <div data-role="shape" ... >. But there's no Shape class in JavaScript and therefore no place to document how we expect an Ubuntu HTML5 shape to be declared. The same goes for pages, and other widgets too.
So we have a couple problems. These are not technical problems, but rather they create a framework that is difficult to learn, communicate, understand and use.
Problem 1: It is difficult to determine the complete set of Ubuntu widgets from source. One has to read all the JavaScript and all the CSS (or consult hand-crafted external documentation) to understand what's available.
Problem 2: With the coming move to generated API docs from source using yuidoc, there is no single type of source file in which we can document how every Ubuntu widget is declared in HTML.
A solution is to set the standard that every Ubuntu HTML5 widget (including all that are mentioned in CSS) should have a corresponding JS class and should be a part of the UbuntuUI prototype class. For example, we should have shape.js and page.js (among other currently missing types). And the UbuntuUI prototype should follow the current pattern and provide constructor functions for each:
shape: function() {...}
page: function() {...}
These prototype constructor functions should exist even when there are apparently no useful functions in the classes themselves (but there alway is, with one additional function described below). That is, we should have a page class that looks something like this:
/**
* An Ubuntu app consists of a Pagestack made of one or more Pages. Each page displays full-window.
* @class Page
* @constructor
* @example
Declare in HTML like this:
<div data-role="page" id="ID">
[...]
</div>
*/
var Page = function (id) {
this.id = id;
};
Page.prototype = {
/*
* placeholder for future methods
*/
};
Although it appears that there is no useful function for the class, there actually can be. I propose adding the following to the UbuntuUI class prototype:
/**
* Gets the Ubuntu HTML element
* @method getEl
* @param {UbuntuWidget} widget - An UbuntuUI widget object
* @return {Element} - The HTML element
*/
getEl: function(widget) {
return document.getElementById(widget.id);
},
This allows one to obtain the HTML element from any Ubuntu widget type that has a class, like this:
var mypage = UI.page("PAGEID");
var mypageEl = UI.getEl(mypage) |
|
| 2013-10-22 17:57:13 |
David Barth |
ubuntu-html5-theme: status |
New |
Confirmed |
|
| 2013-10-22 17:57:18 |
David Barth |
ubuntu-html5-theme: importance |
Undecided |
Medium |
|
| 2013-10-22 17:59:32 |
Kyle Nitzsche |
ubuntu-html5-theme: assignee |
|
Kyle Nitzsche (knitzsche) |
|
| 2013-11-01 20:57:17 |
Kyle Nitzsche |
ubuntu-html5-theme: status |
Confirmed |
Fix Committed |
|
| 2014-01-08 08:32:55 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/ubuntu-html5-theme |
|
| 2014-01-08 08:43:23 |
Launchpad Janitor |
ubuntu-html5-theme (Ubuntu): status |
New |
Fix Released |
|
| 2014-02-24 15:13:34 |
Kyle Nitzsche |
ubuntu-html5-theme: status |
Fix Committed |
Confirmed |
|
| 2014-02-24 15:13:50 |
Kyle Nitzsche |
ubuntu-html5-theme: assignee |
Kyle Nitzsche (knitzsche) |
Alexandre Abreu (abreu-alexandre) |
|
| 2014-02-24 15:55:43 |
Kyle Nitzsche |
tags |
|
docs html5-block |
|
| 2014-02-24 15:56:01 |
Kyle Nitzsche |
tags |
docs html5-block |
docs html5-blocker |
|
| 2014-02-24 16:13:55 |
Daniel Holbach |
ubuntu-html5-theme (Ubuntu): status |
Fix Released |
Confirmed |
|
| 2014-06-06 13:35:09 |
suckadickforfree |
ubuntu-html5-theme: status |
Confirmed |
Incomplete |
|
| 2014-06-06 13:35:24 |
suckadickforfree |
ubuntu-html5-theme: status |
Incomplete |
Opinion |
|
| 2014-06-06 13:35:45 |
suckadickforfree |
ubuntu-html5-theme: status |
Opinion |
Fix Committed |
|
| 2014-06-06 13:41:31 |
suckadickforfree |
ubuntu-html5-theme (Ubuntu): status |
Confirmed |
Invalid |
|
| 2014-06-06 13:53:29 |
Colin Watson |
ubuntu-html5-theme: status |
Fix Committed |
Confirmed |
|
| 2014-06-06 13:53:31 |
Colin Watson |
ubuntu-html5-theme (Ubuntu): status |
Invalid |
Confirmed |
|
| 2015-03-27 10:22:16 |
David Barth |
ubuntu-html5-theme: importance |
Medium |
Wishlist |
|
| 2015-03-27 10:22:19 |
David Barth |
ubuntu-html5-theme (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2015-03-27 14:48:03 |
David Barth |
tags |
docs html5-blocker |
docs |
|
