I read through this and was getting worried until I read "...[they]
ignore all this and use px values..." This is exactly what I did
when I came across the em units and couldn't get a pleasing result
for my preview dialogs.
A related issue is that I use Angular Bootstrap with Less for our
CSS management. Bootstrap has a capability for "responsive" UIs and
it will modify the scale and layout of content based on the "media"
properties provided by the browser platform. Therefore, it is
contrary to the vision of the bootstrap religion to try to design
presentation elements to fit within a particular frame. The idea of
using "em" rather than "px" was a step in the right direction but
doesn't handle the practical complexity of trying to design scalable
page presentations.
Now, thanks to the requirements reminder from Samuel, I see that I
do need to return to the annotation hints for my dialogs and set the
units back to ems and find out a better way to deal with the
outcome. ;-)
On 5/29/14, 12:35, Samuel Padgett
wrote:
I have some doubts about our
use of relative length units for delegated UIs in OSLC.
In OSLC 2.0, widths and heights
for dialogs and resource previews must always use relative
length units [1] [2] [3]. We make the additional statement
that em and ex units are relative to the default system font.
For instance,
"Height size MUST be expressed in relative
length units as
defined in the W3C
Cascading Style Sheets Specification (CSS 2.1) Em and ex units are interpreted
relative to the default system font (at 100% size)"
The second sentence to me seems
to contradict the first. In CSS, em is calculated relative to
the font size of the parent element, not the system font. As a
dialog consumer, how do I adjust for the difference?
The other issue I see is that I
can't accurately size myself as a dialog since I have no idea
what font size is used on the emedding (outer) page. If the
outer page uses a larger font than me, my dialog will be
bigger than I want. If the outer page uses a smaller font, the
dialog will be smaller than I want. It's not based on my
content and font, but the font of the outer page.
The real OSLC implementations
I've seen just ignore all this and use px values. I did some
searching and couldn't find any history for why we require
relative units.
I propose we remove the
requirement and simply say use any valid CSS length value.
[1] http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Resource_Preview
[2] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Resource_Dialog
[3] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#Dialog_Resizing
--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC
|