Absolutely positioned elements broken by update to CSS
Bug #1451937 reported by
Robert Schroll
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu HTML5 UI SDK |
Fix Released
|
Undecided
|
Alexandre Abreu | ||
webapps-sprint |
Fix Released
|
Undecided
|
Alexandre Abreu | ||
ubuntu-html5-theme (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
My app Crosswords [1] uses absolute positioning to layout most of its elements. A year ago, it worked with the toolkit; now it's broken. I believe the problem was caused in 168.3.21, which added the rule:
html, body,
[data-role=
[data-role=
position: relative;
width: 100%;
height: 100%;
}
This means absolutely positioned elements inside the content will be positioned in reference to the content element. Before, all of these elements had been statically positioned, so absolutely positioned elements were positioned relative to the viewport.
Related branches
lp:~dbarth/ubuntu-html5-theme/cmdline-tool
- PS Jenkins bot: Needs Fixing (continuous-integration)
- Ubuntu HTML5 Theme Developers: Pending requested
-
Diff: 78 lines (+74/-0)1 file modifiedubuntu-html5-theme (+74/-0)
Changed in ubuntu-html5-theme: | |
status: | Confirmed → Fix Released |
Changed in webapps-sprint: | |
status: | In Progress → Fix Released |
To post a comment you must log in.
The fundamental problem here is that CSS doesn't offer any separation between a "public API" and private implementation details. And because they're "cascading", a basic change can end up affecting all sorts of elements.
While we could fix this particular problem, avoiding this class of problems is more difficult. Some ideas:
1) Don't ship the toolkit on the device. Make developers include a known-good version in their app.
2) Aggressive versioning. Every time you make a change that could break apps, bump a version number. But this would required app authors to keep updating their apps. Also gives a bunch of versions to potentially backport fixes to. I don't see that this is any better than (1).
3) Publish a supported implementation "API" -- particular layout and display techniques that will be guaranteed to work. Developers can either stick with those and use the system toolkit or implement more complicated layouts and ship a known-good version of the toolkit in their packages.