Introduction

In response to discussion on last august FXTF F2F, this document was prepared for introductory investigation of JavaScript APIs required for Level of Detail.

Assumed contents for Level of Detail

The typical form of the contents which this investigation assumes is as follows. They are the hierarchical contents by which tiling was performed for each level of a detail. It is characteristic that each resources are embedded using iframe. It is because our usecase is interactive geographic information system, so graphics must be operated by DOM.

<!DOCTYPE html>
<html>
<head>
 <title>Hierarchical Tiling by iframe sample</title>
 <style>
  iframe {border:0;position:absolute;}
  .highRes {width:150px;height:150px;}
  .midRes {width:300px;height:300px;}
  .lowRes {width:600px;height:600px;}
 </style>
</head>
<body>
 <div class="levelOfDetailGraphics" id="scalableMap" style="transform:matrix(1,0,0,1,0,0);width:600px;height:600px">
  <span id="lowResTiles" class="levelOfDetail">
   <iframe src="low_0-0.svg" class="lazy lowRes" style="top:0px;left:0px"></iframe>
  </span>

  <span id="midResTiles" class="levelOfDetail">
   <iframe data-original="mid_0-0.svg" class="lazy midRes" style="top:0px;left:0px"></iframe>
   <iframe data-original="mid_1-0.svg" class="lazy midRes" style="top:0px;left:300px"></iframe>

   <iframe data-original="mid_0-1.svg" class="lazy midRes" style="top:300px;left:0px"></iframe>
   <iframe data-original="mid_1-1.svg" class="lazy midRes" style="top:300px;left:300px"></iframe>
  </span>

  <span id="highResTiles" class="levelOfDetail">
   <iframe data-original="high_0-0.svg" class="lazy highRes" style="top:0px;left:0px"></iframe>
   <iframe data-original="high_1-0.svg" class="lazy highRes" style="top:0px;left:150px"></iframe>
   <iframe data-original="high_2-0.svg" class="lazy highRes" style="top:0px;left:300px"></iframe>
   <iframe data-original="high_3-0.svg" class="lazy highRes" style="top:0px;left:450px"></iframe>

   <iframe data-original="high_0-1.svg" class="lazy highRes" style="top:150px;left:0px"></iframe>
   <iframe data-original="high_1-1.svg" class="lazy highRes" style="top:150px;left:150px"></iframe>
   <iframe data-original="high_2-1.svg" class="lazy highRes" style="top:150px;left:300px"></iframe>
   <iframe data-original="high_3-1.svg" class="lazy highRes" style="top:150px;left:450px"></iframe>

   <iframe data-original="high_0-2.svg" class="lazy highRes" style="top:300px;left:0px"></iframe>
   <iframe data-original="high_1-2.svg" class="lazy highRes" style="top:300px;left:150px"></iframe>
   <iframe data-original="high_2-2.svg" class="lazy highRes" style="top:300px;left:300px"></iframe>
   <iframe data-original="high_3-2.svg" class="lazy highRes" style="top:300px;left:450px"></iframe>

   <iframe data-original="high_0-3.svg" class="lazy highRes" style="top:450px;left:0px"></iframe>
   <iframe data-original="high_1-3.svg" class="lazy highRes" style="top:450px;left:150px"></iframe>
   <iframe data-original="high_2-3.svg" class="lazy highRes" style="top:450px;left:300px"></iframe>
   <iframe data-original="high_3-3.svg" class="lazy highRes" style="top:450px;left:450px"></iframe>
  </span>
 </div>
</body>
</html>

The sample of the map which can actually be displayed.

APIs required for Level of detail

This chapter briefly investigates whether APIs required for the above-mentioned assumption are in the existing specs. The specifications which are tightly related on this document are CSSOM View Module and CSS Device Adaptation Module Level 1.

Events for start, end and during transition of zooming and panning.

First, as CSSOM-VIEW shows, there are two kinds of zooms ('page zoom' and 'pinch zoom') which a browser offers natively. And also, there is zoom by application controlling transforms of css and svg.

Note: CSS device adaptation module has called pinch zoom as 'magnifying glass type zoom''. Furthermore, CSS device adaptation module seems to treat such magnifying glass type zoom just as zoom.

Zoom by application

There are custom events.

For page zoom

There is resize event. Where, it has a issue.

For pinch zoom

There are gestureend event (iOS only) and scroll event. They have issues. (issue for gestureend, for scroll)

For scroll

There is scroll event. It has a issue.

APIs for obtaining a zoom ratio

page zoom

There is devicePixelRatio Where, it has a issue.

pinch zoom

There is nothing. (issue)

APIs for checking whether the element is contained in the viewport or viewing area

API for checking whether the element is contained in the viewport

There is getBoundingClientRect (CSSOM-VIEW). It has a issue.

API for checking whether the element is contained in the viewing area

viewing area is a concept often seen within CSS Device Adaptation Module.

There is also getBoundingClientRect and also have issue.

The issues on existing APIs

getBoundingClientRect

In iPhone (iOS7.1.2), getBoundingClientRect returns the value from the upper left corner of the viewing area. On the other hand, Android Chrome returns the value independent of pinch zoom & pan (probably actual-viewport?). (view test)

It seems that the spec says that it should return the position from viewport. Even if that is right, we even want to get BoundingClientRect based on the viewing area.

Pinch zoom

There is no attribute which provides pinchZoom ratio.

Issues on embedded Window such as iframe

The embedded child Window who was generated by iframe has the following issues.

resize event

On Edge and IE, resize event does not occur at the time of page zoom.(view test)

gestureend event

The gestureend event occurs only within window which captured that gesture, although pinch zoom affects the nested entire contents. (view test (on iOS) )

The gestureend event does not always react to all the pinch zoom (magnifying glass type of zoom). Because this event has not responded to the pinch zoom semantics itself. For example, it does not respond to double tap zoom.

scroll event

The scroll event occurs by neither pinch zoom nor scroll caused by it.

devicePixelRatio

When parent's iframe element has transforms, all the browsers generate devicePixelRatio of a child's window without taking transforms into consideration. (view test1 and test2)

A child's document cannot perform control of the representation according to the actual magnification on a device, unless magnification is provided from parents. Specification seems to have said nothing about such transforms.

rotation and skew

What is an appropriate computing equation in case such transforms has a non-diagonal (rotate and skew) components? I (stakagi) think that use of the scale value which I prepared as a patch for css transforms2 is relevant.

Points in question

How do viewing area and viewport behave as folloing case? ; If scrolling occurs during pinch zooming (magnifying glass type of zooming) , what will happen to viewport? Is it viewport which is not actual viewport or initial viewport, either?
- How about adding the detailed explanation about them to spec?
- How about adding clear API for getting to know viewing area?

It seems that the definition of page zoom and pinch zoom is unclear. And also, it seems that CSSOM-VIEW spec has said that Device Adaptation Module explains it.
- How about adding those definitions to spec. A description of the appropriate term may be required about pinch zoom such as magnifying glass type zoom.

Are dppx of resolution (CSS3-VALUES) and devicePixelRatio (CSSOM-VIEW) the same semantics?
- How about adding those relations to spec?

How about adding the event for pinch zoom and scroll accompanying it?

How about adding non-normative explanation of the entire transformation process in which CSS Pixel is rendered on a screen according to page zoom, pinch zoom, viewport and CSS/SVG transforms.

Further investigation on nested Window by iframe etc. is required.