Re: file writer discontinued?
On 7/26/14 3:40 PM, "Harald Jordan" wrote: > As a media-applications developer¹s companies chief developer I am trying to > find a way to get involved in the happenings around the html file api¹s. > Could you please give me a tipp where to start finding out why the html5 file > writing stuff was discontinued? Decision note: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0010.html Or you may search the archive for related mails: http://www.w3.org/Search/Mail/Public/search?keywords=FileWriter&hdr-1-name=s ubject&hdr-1-query=&index-grp=Public_FULL&index-type=t&type-index=public-web apps
Re: [Screen Orientation] Best Practice wording comment
On 7/28/14 3:01 AM, "Mounir Lamouri" wrote: >> >> I suggest adding a "permanent" relationship qualification and/or >> "cross-devices" dimension in that sentence. > >Fixed: >https://github.com/w3c/screen-orientation/commit/d1adfa1b1419d534c8b124331 >a70c7a322451008 Better. Thanks >> 2. I am noting that the definition 1 and 2 of "reading current screen >> orientation type" is going to require that IEMobile and iOS change the >> reporting of their current screen.width and screen.height to the correct >> orientation, and stop reporting portrait only. I suppose that's a good >> thing > >Do you mean that they do not update the screen.width and screen.height >when the screen rotates? Correct, IEMobile and iOS browsers always report the portrait values. Chrome mobile fixed that at version 18. It's been documented by ppk: http://www.quirksmode.org/mobile/tableViewport.html Perhaps you could enforce that fix by being even more explicit such as: "1. If the 'screen.width' is greater than the 'screen.height', return landscape-primary or landscape-secondary." The portrait only behavior is error prone, and need to be corrected.
[Screen Orientation] Best Practice wording comment
Just took a peak at the latest spec [1], since Chrome Canary breaks my code made for the previous spec and I have to update to a dual screen.orientation object|string context (It was previously a string). Good to see the new 'natural' keyword and angles. 1. One minor comment on the "Best Practice 1" box for the phrase: "Never assume any kind of relationship between the screen orientation type and the screen orientation angle" "Any kind" seems too strong a statement, since there is a relationship between type and angle during the length of a browsing context/runtime as mentioned afterwards. I suggest adding a "permanent" relationship qualification and/or "cross-devices" dimension in that sentence. 2. I am noting that the definition 1 and 2 of "reading current screen orientation type" is going to require that IEMobile and iOS change the reporting of their current screen.width and screen.height to the correct orientation, and stop reporting portrait only. I suppose that's a good thing even if it might break a few scripts. https://w3c.github.io/screen-orientation/#screenorientation-interface -Bruno
Re: Screen Orientation Status
On https://www.w3.org/Bugs/Public/show_bug.cgi?id=25088 : You cannot fire on window without also having the window.orientation property (with its own issues*). That would break existing code relying on the webkit api (expecting to read a value on window.orientation). I am not sure, I was able to get my point across previously, for lack of feedback on it, but I strongly believe that mixing 'device' orientation and 'screen' orientation is a mistake going forward and important point. In the not so distant future, we will likely use screens 'attached' to mobile devices. In that, the screen will be entirely independent from the mobile table/phone/watch/etc. Sample use case: Let's imagine an ipad like 'iScreen' plugged to an iPad with dual screen capability with two different browser viewport on each screen. When the iPad rotates, it shall only fire for the iPad screen, not the external iScreen if the later doesn't rotate, and vice-versa. How will you differentiate those two from an implementation standpoint? I have no idea how that goes, but I'd like to raise that question. *In that case, the window events would not, and shall not be expected, to fire at the same time. IMO, one component here *must* remain 'mobile device/embedded screen' based. And the other purely screen (either external or embedded). Or I think there will be implementation hurdles or confusion down the road. Unless I am mistaken, the webkit window.orientation API speaks of 'device' as purely of an 'embedded screen device'. Accordingly, I think we should clearly dissociate 'device' from 'screen', or it may narrow and limit the scope of usage. I don't think that a unique API without the above distinctions is the appropriate forward compatible way to go. If Screen Orientation must fire at the window level, perhaps let's use a different name such as window.screenorientationchange. -Bruno On 4/3/14 2:36 PM, "Mounir Lamouri" wrote: >Hi, > >I have just updated the specification WD, solving most of the >outstanding issues: >https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html (it >is hot off the press, be gentle with typos and nits) > >There are now only two outstanding bugs now: >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25053 >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054 > >I have an idea on how to handle them but I would like to discuss those >during the F2F next week. > >Implementation status: >- Implemented and shipped prefixed in Firefox Desktop, Firefox Mobile >and Firefox OS; >- Implemented and shipped prefixed in IE11 Mobile; >- Currently being implemented in Blink for Chrome Android >(implementation match current ED). > >Note: the implementations are not compatible with the current ED but no >implementer raised concerns about the changes when discussed here. > >Path to LC: >Unless there are new outstanding issues being raised, I would like to go >to LC when the two bugs above are fixed. Hopefully just after the F2F. > >Test suite: >None yet. No test suite coordinator at the moment. > >Thanks, >-- Mounir
Re: Screen Orientation API Spec (from phrasing confusion)
>On 3/13/14 10:59 AM, "Mounir Lamouri" wrote: > >>I recently landed a usage counter for window.orientation. It will take >>some time to roll to Chrome Android stable but hopefully we will find >>out if window.orientation is actually used a lot. If that's the case and >>other UA want to implement it, we could incorporate that into this >>specification. In any case, I would like to add this feature but not as >>|window.orientation|. >> >> >>Your use case will be taken care of, see this bug: >>https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698 > >You could alternatively just have a 'natural' orientation boolean flag, >to help assessing the angle at the initial rotation level >(without having to first rotate to find out). > >The flag would also add the ability to lock to the "natural" orientation. > >My main rebuttal of the orientation values is not the lack of angle, but >rather the lack of instant identification of this 'natural' orientation >state. We can figure out the mapping to angles with such a flag. > >So should it a better or easier implementation option, perhaps avoiding >redundancy, that would work too, and the only thing needed to address my >case. If you are going to leave it up to the UA. As per the recent change: --- Comment #1 from Mounir Lamouri --- *-primary and *-secondary is now entirely up to the UA: https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528 Ignore my previous/above comment. A flag won't work anymore. The notion of left and right is lost under this new spec change, with the concept of orientation being very different from what it was. I have to scrap mapping to angles, that change deprecates my code. I'll wait until we have angles, or for Mozilla and IE to implement window.orientation for mobile.
Re: Screen Orientation API Spec (from phrasing confusion)
On 3/13/14 10:59 AM, "Mounir Lamouri" wrote: >I recently landed a usage counter for window.orientation. It will take >some time to roll to Chrome Android stable but hopefully we will find >out if window.orientation is actually used a lot. If that's the case and >other UA want to implement it, we could incorporate that into this >specification. In any case, I would like to add this feature but not as >|window.orientation|. > > >Your use case will be taken care of, see this bug: >https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698 You could alternatively just have a 'natural' orientation boolean flag, to help assessing the angle at the initial rotation level (without having to first rotate to find out). The flag would also add the ability to lock to the "natural" orientation. My main rebuttal of the orientation values is not the lack of angle, but rather the lack of instant identification of this 'natural' orientation state. We can figure out the mapping to angles with such a flag. So should it a better or easier implementation option, perhaps avoiding redundancy, that would work too, and the only thing needed to address my case.
Re: Screen Orientation API Spec (from phrasing confusion)
On 3/13/14 10:59 AM, "Mounir Lamouri" wrote:
>> http://msdn.microsoft.com/en-us/library/ie/dn433241(v=vs.85).aspx
>>
>> That seems to defeat the "normal orientation" aspect of the spec and the
>> usefulness of '-primary' and '-secondary' suffixes "for the initial
>> state".
>
>There is a bug on file to make the explanation a bit clearer:
>https://www.w3.org/Bugs/Public/show_bug.cgi?id=24699
I don't think you are getting my initial point of confusion in the spec.
This would make it even more confusing than it already is.
>The relation between -primary and -secondary should be up to the UA.
You mean the *device* not the UA? Or else you are puzzling me.
The spec said/says: "The concepts of primary orientation and secondary
orientation depends on the device and the platform"; *not* the browser.
Or is there a private draft I can't see saying the contrary now?
>If Microsoft wants to give specific angles, why not.
OK now you are *completely* losing me. Why not? What the heck do you mean?
The current specification *has* a 90 degrees clockwise given angle which
Microsoft *followed*.
I have the feeling that neither Mozilla or Microsoft were able
to fully make sense of the spec as you express it here, which as I
specified, isn't fully understandable on its own terms.
Again, in 3.1: "In both if the device is in landscape-primary and is
rotated 90 degrees clockwise, that should be represented as
portrait-primary." You are giving an angle, while referring to 'In both'
of 2 previous opposite cases. That sentence is deprived of logic with:
[In both] !== [if the device is in landscape-primary] in the same sentence.
Microsoft's interpretation of that sentence is:
[In both if the device is in x-primary and is rotated 90 degrees
clockwise, that should be represented as x-primary.]
As such Microsoft would be on spec but that's not what the spec says.
While Mozilla seems to map it to fixed angles as per:
http://mxr.mozilla.org/mozilla-central/source/widget/gonk/OrientationObserv
er.cpp
static OrientationMapping sOrientationMappings[] = {
{nsIScreen::ROTATION_0_DEG, eScreenOrientation_PortraitPrimary},
{nsIScreen::ROTATION_180_DEG, eScreenOrientation_PortraitSecondary},
{nsIScreen::ROTATION_90_DEG, eScreenOrientation_LandscapePrimary},
{nsIScreen::ROTATION_270_DEG, eScreenOrientation_LandscapeSecondary},
};
which sigh, doesn't match with my initial js implemention based on
Microsoft's spec. That's a discrepancies already between the two
prefixed implementations.
I don't know how Tizen is interpreting the spec, but this need to be
clarified before UAs ship it a unprefixed with their own take on it.
Or this API is looking live a future living hell for developers.
-Bruno
Screen Orientation API Spec (from phrasing confusion)
As a follow from the cc of my post by Arthur from the main list: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0471.html I'd like to point out the following for the Screen Orientation API with my reading of previous fairly recent posts from the archives: Unless I am missing, something my current issue with screen.orientation is that it does not actually specify which is the "natural" orientation right away, UNLESS the device is rotated once. Is this really by design? Ref. again: http://msdn.microsoft.com/en-us/library/ie/dn433241(v=vs.85).aspx That seems to defeat the "normal orientation" aspect of the spec and the usefulness of '-primary' and '-secondary' suffixes "for the initial state". On Wed, Nov 6, 2013, at 11:17, Jonas Sicking wrote: > Last I looked the property was useless because window.orientation=0 > meant different things on different devices. I.e. on some devices it > meant "landscape mode" and others it meant "portrait mode". It's not completely useless because one can tell the initial orientation by other means. (either media queries or deduction from screen width/height) As per Mounir, 0 indicates the natural orientation, which screen.orientation lacks as best illustrated by M. Gifford: http://www.matthewgifford.com/blog/2011/12/22/a-misconception-about-window- orientation/ Based on the above, the implied official specs of window.orientation is quite consistent with legacy implementations. >So unless webcompat at some point requiring it, I don't see us adding it. I think it should be, because the screen orientation API lack the 'natural' orientation, at the moment anyway. I was actually trying to somehow polyfill the [0,90,-90,180] of window.orientation with screen.orientation. But I cannot account for the 0 (normal orientation) due to the initial orientation value having two definitions. :\ And honestly with screen.orientation, I currently have to write 12 lines of code to deduct whether the device was turned left of right, from the initial state, as opposed to the more straight forward window.orientation for that particular goal. >window.screen.orientation seems like a better way forward. The two have different meanings. From a legacy standpoint window.orientation implies a mobile device (i.e where the screen is attached to the device), and to that effect is only implemented on mobile browsers[1]. (And while there is 'DeviceOrientation' Events for mobile devices that's an overkill for simple web sites use. /aside) Whereas screen.orientation applies to all screens regardless of the device type. That worth a distinction and a specificity that could help us identify mobile devices vs desktop on the long term, if "IEMobile" and "Fennec" implemented window.orientation for mobile. On Wed, 06 Nov 2013 11:27:08,Mounir Lamouri wrote: >Indeed, if I remember correctly, window.orientation=0 is the "natural" >orientation and then, the value is the angle between the current >orientation and the natural one in the range ] -180 ; 180 ]. Mounir, note that there is no -180 angle, as far as I know. I think that -180 only applies to DeviceOrientation Events. --- And finally, one question which may or may not depend on implementation: (latter preferred) Is the screen.orientationchange event supposed to fire for every rotation step? Say if the device is rotated fast from upside to upsidedown. Should or* must* the device fire two events, or can it possibly fire only Once? Bruno [1] http://compatibility.shwups-cms.ch/de/home?&property=orientation
