Re: I18N comments on Manifest for Web applications
On 3/24/15 3:07 PM, Arthur Barstow wrote: On 3/24/15 10:21 AM, Richard Ishida wrote: is it possible to send mail to www-internatio...@w3.org each time someone adds somethign to the github issue? (this is the list where we track and discuss issues). if so, i see no real difference between using github or bugzilla – our process is designed to cope with both bugzilla and email based comments (though it would normally be better to start with the right one rather than switch part way, so changing the SOD would indeed help). we should also ensure, however, that the titles of the issues and any associated notification mails always contain the i18n-issue-xxx string that will allow us and tracker to locate information for a given thread. FYI, I just added [i18n-issue-NNN] to the title of the five Github issues Ken created ([GH]) for the issues Addison submitted (and created the I18N-WG label for them). I don't know if the GH repo can be configured such that all activity for just these issues can be automagically Cc'ed to www-international but I know Dom has done so related work so I will follow up with him separately. FYI, Dom configured GH as requested: [[ I've updated github-notify-ml to support that feature [1], configured it for this particular repo and tested it [2]. Dom 1. https://github.com/dontcallmedom/github-notify-ml/compare/6ce58740823bf5ae3b239fa7ae411e0fc5a11ab3...20b523ab2cf12b8489e13f1241df2471ea650858 2. https://lists.w3.org/Archives/Public/www-international/2015JanMar/0186.html ]] Thanks Dom! -ArtB
Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
on 25/03/2015 03:52, Sigbjorn Finne wrote:
Hi,
if it helps, Blink now passes those two failing tests; Chrome
canary/nightly builds have the fixes included.
(Fixes for
http://www.w3c-test.org/webmessaging/without-ports/{008,009}.html
should appear overnight also.)
hth
--sigbjorn
Thank you for the great news, Sigbjorn!
The Canary (Ch43) data was into the ImplReport[1] so right now we have
at least 2 implementations that pass each test file. According to a
recent discussion about MessagePort/MessageChannel[2], Firefox will
serve as another implementation for these APIs soon.
Special thanks to Simon Pieters and Zhiqiang Zhang for their useful
comments while this test suite was being updated.
[1] http://w3c.github.io/test-results/webmessaging/all
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=952139
--
xiaoqian
[Bug 28332] Remove any border and padding from fullscreen iframes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28332 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/5103d2e42305f63bd6da65c100313a6d09ec3740 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28332] New: Remove any border and padding from fullscreen iframes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28332
Bug ID: 28332
Summary: Remove any border and padding from fullscreen iframes
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Fullscreen
Assignee: ann...@annevk.nl
Reporter: phil...@opera.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
The spec current has this:
iframe:fullscreen {
border:none;
}
Until recently, Blink had this:
iframe:-webkit-full-screen {
border: none !important;
padding: 0 !important;
}
Removing them found two sites assuming that any border/padding would be ignored
in fullscreen:
https://code.google.com/p/chromium/issues/detail?id=468292#c4
(https://play.google.com/store/movies?hl=en)
https://code.google.com/p/chromium/issues/detail?id=469133#c5
(http://html5-demos.appspot.com/static/fullscreen.html)
Because the border rule is not !important and there is no padding rule, any
site that has some border or padding on iframes must take care to remove them
in fullscreen.
No border and padding will likely be the right thing more often than not, so I
would like for the spec to align with Blink.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Screen Orientation] nit for the case when the screen width and height are equal
I have to admit that I am reading this spec thinking about rounded display[1] (aka. watch) and this probably requires brainstorms instead of this nitpicking, but whatever. The current spec seems to leave screen.orientation.lock(landscape) undefined for the case when the screen width and height are equal because the steps of update the orientation information make current orientation type always portrait-primary or portrait-secondary for such case: # 2. Otherwise, if the screen width is less than or equal to the # screen height, set the document's current orientation type to # portrait-primary or portrait-secondary. (update the orientation information step 2) I think we shoud drop or equal to here and, if necessary, say something like for the purpose of this specification, it is assumed that the physical device has unequal width and height. User agent MUST treat one physical side or another as if its greater., but this is awkward so I think just dropping or equal to is fine. Some more editorial comments: In step 1 of update the orientation information # 1. If the screen width is greater than the screen height, set the # document's current orientation type to landscape-primary or # landscape-secondary. I had trouble realizing that the screen width here is a variable and depends on how viewport is rendered (I had assumed it means device width, I guess). This probably needs a xref to screen in 4. Concepts. Or would it be fine if we just use 'screen.width' and 'screen.height' here? In step 3 of update the orientation information # 3. Set the document's current orientation angle to the clockwise # angle in degrees between the orientation of the viewport as it is # drawn and the natural orientation of the device (i.e., the top of # the physical screen). I am still having trouble visualizing what clockwise angle in degrees between the orientation of the viewport means and I wonder if it would be easier if this is rephrased using angle from. A picture here would be the best (perhaps adapted from a DeviceOrientation one?). In step 6 of lock the orientation # 6. Otherwise, depending on platform conventions, change how the # viewport is drawn in order to make it match another screen # orientation type. However, it has to be part of orientations. I think we should consider revert this change[2]. Having no MAY (or may) here reads like a must to me, and so it sounds kinda confusing even if there's depending on platform conventions. [1] http://dev.w3.org/csswg/css-round-display/ [2] https://github.com/w3c/screen-orientation/commit/824cfee4e9009fd8eb7746a9a70b135f2ce3e896 Cheers, Kenny -- Software Engineer, Shenzhen, BGI
