Orientation, viewport dimensions and synchronicity

[yoavweiss]

While discussing <picture> with @brucelawson, @mathiasbynens and @andreasbovens, we started talking about the at-viewport CSS rule and how it should be defined inlined, to enable viewport based resource fetching (both for external CSS priorities, as well as for <picture> and sizes).

Then we started talking about the manifest's orientation flag, and how it can have a similar impact on the viewport dimensions, even though the manifest is downloaded in an external file, and AFAIK should be a low priority, async download (even though I don't see it explicitly mentioned in the spec).

I also know that in a recent debate regarding the "brand-color" meta tag on blink-dev (that resulted in #225), one of the main reasons for adding yet another meta tag was that the manifest is async, and therefore the color would be added too late, resulting in bad UX.

So, I guess that I have several questions here:

• Is the orientation member supposed to impact the first page view? If so, what's the plan to deal with FOUC, and spurious resource downloads?
• Do you think that there's a place to divide the manifest into sync and async parts? Or otherwise mitigate the impact of semantically sync members on the first page load in an "async manifest" world?
• Should the at-viewport be integrated into the manifest in some way? Or should the orientation member move to CSS? I think they are semantically related, so they may benefit from being defined together.

[kenchris]

Lots of good questions :-)

We already looked into adding something like at-viewport to the manifest and it just feels like it doesn't belong. Anyway you need the info at the time of layout, so being part of CSS makes sense and it is up to the author to make sure they are available at the right time to avoid FOUC.

With orientation that might be a bit harder. Orientation can be changed from JS already via lockOrientation. The author might want to fix an orientation before any layout occurs and not have the Platform UI do any rotation animation.

When saved to launcher etc the orientation manifest entry will be present and the url will start up in the right orientation, no problem there.

So what happens the first time when the manifest is being fetched? I guess it is fine that is changes orientation later (as you would do if you called lockOrientation) but people would like to avoid doing any layout in the wrong orientation before so. How do we ensure that?

[kenchris]

Also keep in mind that orientation in the manifest if more like the default orientation that will be used when lockOrientation hasnt been called or after unlockOrientation is called.

[kenchris]

I guess brand-color has the same issue as orientation. You want it available before you do layout, ie before you end up painting anything (thus white). If brand-color was in CSS and inlined, wouldn't that suffice? The engine would just handle that value immediate when encountered.

[yoavweiss]

I don't see how orientation is inherently different than viewport dimensions. You can probably convince me that both belong in the manifest (assuming we find a sync way to embed them) or that both belong in (inlined) CSS, but I think they belong under the same roof.

If a Web dev modifies orientation via JS after layout, that's on him. But we should strive to make the default way of setting it as performant as possible (in terms of layout, FOUC, and resource download).

[jmajnert]

Please correct me if I'm wrong, but I think the main use case for the manifest is to enable web app installation (bookmarking). Thus in a typical scenario, the user visits a web site, the manifest is downloaded asynchronously and when it's ready, the UA presents an installation/bookmarking UI. By allowing the installation the user enables extra features described in the manifest.
So the properties described in the manifest take effect on next visit to the site.

[marcoscaceres]

@jmajnert sort of correct... we want to instead apply whatever we can from the manifest to the web page as soon as the manifest is acquired (without putting it on the critical path). This is basically: #226

[jmajnert]

I think I missed the discussions where that idea came up. Could you please point me to some rationale?

[marcoscaceres]

@jmajnert Um, I don't think it's written down anywhere. It's just how I assumed it would work. I'm working on an article with @brucelawson about it tho. We hope to have that out in a week or so.

[marcoscaceres]

@yoavweiss asked:

• Is the orientation member supposed to impact the first page view?

No. I assume that devs will want to check the orientation and apply it themselves on first page load (if they need it). There are other preconditions that may apply for orientation change to happen, like being launched in fullscreen.

If so, what's the plan to deal with FOUC, and spurious resource downloads?

As above. Tho, I don't know what exactly a "spurious resource" means in this context?

• Do you think that there's a place to divide the manifest into sync and async parts?

No. Or I really hope not! :)

Or otherwise mitigate the impact of semantically sync members on the first page load in an "async manifest" world?

Critical sync things should remain in the document. The manifest can only be relied on as a progressive enhancement. At least, that's how I'm treating it.

Should the at-viewport be integrated into the manifest in some way? Or should the orientation member move to CSS? I think they are semantically related, so they may benefit from being defined together.

Do you mean something different to what is already in the device adaption spec?
http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor

@kenchris wrote:

So what happens the first time when the manifest is being fetched? I guess it is fine that is changes orientation later (as you would do if you called lockOrientation) but people would like to avoid doing any layout in the wrong orientation before so. How do we ensure that?

Not sure. Need to think about this.

[brucelawson]

On Mon, 30 Jun 2014 20:37:50 +0100, Marcos Caceres
notifications@github.com wrote:

I'm working on an article with @brucelawson about it tho. We hope to
have that out in a week or so.

Travels are completed so I'll be all over that tomorrow (wed) like weevils
on a weasel.

bruce

✄--------------------------------

Bruce Lawson
@brucel
www.brucelawson.co.uk

[jmajnert]

@marcosc @brucelawson How about that article?

[marcoscaceres]

Sorry, I've been slacking off. Close to done.

[marcoscaceres]

Forgot to add a link to the article here after we published. http://html5doctor.com/web-manifest-specification/

[marcoscaceres]

Closing, as questions where answered. The only action from this is to clarify the spec as per: #229