[Bug 27151] [imports]: Poor grammar in the 3.1 Import Dependent section

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27151

Morrita Hajime  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||morr...@google.com
 Resolution|--- |FIXED

--- Comment #1 from Morrita Hajime  ---
Thanks for suggsetion! It's much better.

https://github.com/w3c/webcomponents/commit/5b8fe600d590bcb629b9d70a9acad1e181d97edf

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Hajime Morrita]

And for HTML Improts:

# Since Last TPAC:
* Minor bug fixes
* Styleshet cascading order clarification

# Next 6 months:
* Script execution order clarification
* ES6 modules integration



On Fri, Oct 24, 2014 at 1:08 PM, Dimitri Glazkov 
wrote:

> Here's an update on Custom Elements Spec.
>
> Since the last TPAC:
> * Added informative ES6 section:
> http://w3c.github.io/webcomponents/spec/custom/#es6
> * Minor bug fixes
>
> Next 6 months:
> * P1: fix bugs, identified by Mozilla folks when implementing Custom
> Elements:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016
> * P1: integrate with new microtask processing:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25714
> * P2: other bug fixes as time permits.
>
> :DG<
>
>


-- 
morrita

Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Dimitri Glazkov]

Here's an update on Custom Elements Spec.

Since the last TPAC:
* Added informative ES6 section:
http://w3c.github.io/webcomponents/spec/custom/#es6
* Minor bug fixes

Next 6 months:
* P1: fix bugs, identified by Mozilla folks when implementing Custom
Elements:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016
* P1: integrate with new microtask processing:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25714
* P2: other bug fixes as time permits.

:DG<

[Bug 27162] New: Browser differences in graphical layout of fullscreen mode.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27162

Bug ID: 27162
   Summary: Browser differences in graphical layout of fullscreen
mode.
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P2
 Component: Fullscreen
  Assignee: ann...@annevk.nl
  Reporter: juj...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

The Fullscreen API has become ubiquitously supported in Firefox, Chrome, Opera,
IE11 and Safari. However developing cross-browser applications that use this
feature is extremely painful, because different browsers implement the spec
differently.

The Fullscreen API spec does not fully specify how graphical presentation
should occur (or if it does, I'm not enough of a spec wizard to read what the
correct behavior is), so it is difficult to report bugs to different browser
bug trackers to convince that they should change their behavior since
https://fullscreen.spec.whatwg.org doesn't have a strong documentation.

I've recently been implementing fullscreen mode support for use in the
Emscripten environment, and wrote up a test case for Fullscreen mode
management, which can be run live at
https://dl.dropboxusercontent.com/u/40949268/emcc/bugs/fullscreen_canvas.html

While writing that, I found several differences that one needs to account for,
here's a list of current ones:

1. Both Firefox and IE11 resize the CSS size of the element to cover the whole
screen. Chrome and Safari instead don't change the CSS size at all, but simply
position the element to the center of the screen unscaled.

2. As a result of that, FF and IE11 fire the JavaScript 'resize' events when
transitioning to and from fullscreen.

3. Firefox and IE11 do not preserve the aspect ratio of the content to be
displayed fullscreen, but Chrome and Safari do. The user has to pre-resize the
content to the desired size before requesting fullscreen if he wants to stretch
it to cover the full screen on Chrome and Safari as well. (using
element.style.width/height)

However it's difficult to know what the correct procedure for this resizing
should be, because there's no way to properly get the size of the screen before
one has transitioned to fullscreen mode. The nonstandard screen.width and
screen.height seem to be the closest, but unfortunately those are fundamentally
broken when run on a device where window.devicePixelRatio is a fractional
number (see https://bugzilla.mozilla.org/show_bug.cgi?id=1024493 ), and there
does not exist an alternative way, except to do a test where one hides all DOM
contents, then creates a  and then calls
.getBoundingClientRect() on that. However that is an extremely intrusive way,
and one cannot even cache the results of that because of multimonitor setups,
so a better solution is needed.

4. Because one needs to resize the CSS size manually to exact fullscreen size
for unified cross-browser behavior, then the only way to implement aspect ratio
control is to use padding, margin or borders to add letterboxes to the sides.
Here the specification does not explicitly say how those should be treated, and
the current browsers also behave differently:

   - Both Firefox or Chrome ignore the margin properties on the element, and
display the element in fullscreen without the margin. IE11 instead does display
the margin as a part of the fullscreen.
   - If padding is present, IE11 computes the displayed size differently
compared to Firefox and Chrome. FF and Chrome compute padding as a part of the
CSS size, so if the CSS size is 1920x1080px, and padding-left and right is set
to 460px, and padding-top and bottom are set to 40px, then both FF and Chrome
will show a rectangle of 1000px x 1000px of actual content. IE11 instead sums
these up and then stretches the results, so it will show a (1920+2*460) x (1080
+ 2*80) px element stretched to fit inside the fullscreen window. This makes it
impossible to use padding to implement cross-browser aspect ratio control.
   - If a border is present, Firefox and Chrome disagree on how the content
should be rendered.

Because of all these differences, currently the best scheme is to detect the
browser user agent, and if using IE11, use margin to specify aspect ratio, and
on all other browsers, use padding.

5. Given padding/margin in the element that is put to fullscreen, Firefox will
always display the letterbox area in black color. Chrome will instead use the
backgroundColor property of the element (default = white). IE11 instead will
use the backgroundColor property of the document body element (default =
white).

6. Browsers don't agree on what should happen if the content is resized _after_
it has already been transitioned to fullscreen mode. For example Chrome ignores
adjustments to element padding if it's done in the 

Re: Push API change for permissions UX

[Martin Thomson]

On 24 October 2014 09:09, John Mellor  wrote:
> For background sync[1], such a throttling approach would be ideal, as there
> is no expectation of timeliness. But push is different: users can come to
> depend on timely delivery of push notifications, and sufficiently
> heavy-handed throttling would introduce unreliability/inconsistency -
> especially if the goal is to mitigate geoip tracking, since only a handful
> of push messages might be enough to locate e.g. your home and work.

Isn't that a perfect disincentive?  Apps learn that abusing push leads
to a terrible user experience.  And we can mitigate that by using the
prioritization mechanisms that push provides, allowing apps to
identify less important messages that can be dropped first.  The rules
need not be complex, for example: one high priority message per user
interaction or per hour (whichever is shorter), 3 medium priority
messages in the same time, and 5 low priority messages; more may be
permitted but not guaranteed.

I don't share your concern with respect to geoip tracking; or at least
I don't give it the same amount of weight you seem to.  If you permit
an application to run in the background, then this is one of the many
things the app will be able to do.  The same sort of tracking is
enabled by having tabs left open.

> app to just always show a notification of its choice (which will at least be 
> slightly useful)

I can think of nothing worse than something that forces the creation
of a notification.  Notifications consume user attention, of which
there is (qualitatively) far less of than battery Joules or network
bytes.

Re: Push API and Service Workers

[Arthur Barstow]

On 10/24/14 11:36 AM, Shijun Sun wrote:

On October 24, 2014 4:30 AM, Arthur Barstow wrote:

On 10/22/14 1:21 AM, Shijun Sun wrote:

I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
scenarios using push messages.  The goal is to make sure we understand the 
steps and options in the whole E2E story.

Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:

Thanks Arthur!

Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be 
more productive for folks having hands-on experience with Service Workers to 
participate.


Good point. Since Jungkee is attending the meeting (and I'll chase after 
Alex to see if he can join), I created a 13:00-14:00 Push API and 
Service Workers block on Monday and added links to the 2 issues below.




-Art


Best, Shijun

[1] https://github.com/w3c/push-api/issues/84
[2] https://github.com/w3c/push-api/issues/85

Re: Push API change for permissions UX

[John Mellor]

On 23 October 2014 23:29, Martin Thomson  wrote:

> It means that important features that provide
> these measures (do not disturb, more contextual event filtering) are
> not available to applications by default.
>

System-wide do-not-disturb would still work (for example in Android Lollipop
 any
non-whitelisted notifications shown by apps during do-not-disturb mode are
silent and hidden away behind a single unobtrusive "X notifications hidden"
notification).

I agree that app specific contextual event filtering can sometimes provide
a better user experience, and would indeed require full push permission;
these apps should just go ahead and request full push permission (though if
the user grants push notifications [Notification.requestPermission] then
denies silent background execution [pushRegistrationManager.register
without userVisibleOnly], the app might still benefit by being able to fall
back on unfiltered push notifications [pushRegistrationManager.register
with userVisibleOnly].

I'd like to find better ways of dealing with this problem.  This
> approach seems like more of a cop-out to me.  I'm seriously
> jet-lagged, so only two ideas spring to mind, I'm sure you can find
> some more if you set your mind to it: Usage budgets might be applied
> to various resources, after which a SW is activated less often.


For background sync[1], such a throttling approach would be ideal, as there
is no expectation of timeliness. But push is different: users can come to
depend on timely delivery of push notifications, and sufficiently
heavy-handed throttling would introduce unreliability/inconsistency -
especially if the goal is to mitigate geoip tracking, since only a handful
of push messages might be enough to locate e.g. your home and work.

Or good accounting and reporting (see various activity monitors on
> different operating systems that account for all sorts of resource
> usage,


Yes, we want clear usage tracking UI as well. But realistically, only power
users monitor such things; on Android and iOS, that still provides a useful
feedback mechanism via app store reviews, but users don't normally visit
websites via an app store. And again, this doesn't really mitigate geoip
tracking.


> or you could generate simple notifications like: "this app is
> burning your battery/network, turn it off?")
>

We considered that as well, but to mitigate geoip tracking, we'd have to
show this warning for every few pushes that don't show user-visible UI, and
at that point, it's better for the app to just always show a notification
of its choice (which will at least be slightly useful) than for the UA to
keep showing an annoying warning.

Thanks,
John

[1]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md

RE: Push API and Service Workers

[Shijun Sun]

On October 24, 2014 4:30 AM, Arthur Barstow wrote: 
>
> On 10/22/14 1:21 AM, Shijun Sun wrote:
>> I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
>> scenarios using push messages.  The goal is to make sure we understand the 
>> steps and options in the whole E2E story.  
>
> Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:

Thanks Arthur!  

Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be 
more productive for folks having hands-on experience with Service Workers to 
participate. 

Best, Shijun

[1] https://github.com/w3c/push-api/issues/84
[2] https://github.com/w3c/push-api/issues/85 

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

[Arthur Barstow]

[ Apologies for top posting ]

I just added a 11:30-12:00 time slot on Monday October 27 for XHR:



I believe Jungkee will be at the meeting so, Hallvord and Julian please 
join via the phone bridge and/or IRC if you can:




-Thanks, AB

On 10/19/14 11:14 AM, Hallvord R. M. Steen wrote:

However, the WHATWG version is now quite heavily refactored to be XHR+Fetch.
It's no longer clear to me whether pushing forward to ship XHR2 "stand-alone"
is the right thing to do..

(For those not familiar with
WebApps' XHR TR publication history, the latest snapshots are: Level1
; Level 2
 (which now says
the Level 1 

Re: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Takeshi Yoshino]

On Fri, Oct 24, 2014 at 8:24 PM, Arthur Barstow 
wrote:

> On 10/23/14 1:26 PM, Domenic Denicola wrote:
>
>> From: Arthur Barstow [mailto:art.bars...@gmail.com]
>>
>>  I think recent threads about Streams provided some useful information
>>> about the status and plans for Streams. I also think it could be useful if
>>> some set of you were available to answer questions raised at the meeting.
>>> Can any of you commit some time to be available? If so, please let me know
>>> some time slots you are available. My preference is Monday morning, if
>>> possible.
>>>
>> I'd be happy to call in at that time or another. Just let me know so I
>> can put it in my calendar.
>>
>
> OK, I just added Streams to the 11:00-11:30 slot on Monday Oct 27:
>
>  Agenda_Monday_October_27>
>
> IRC and Zakim phone bridge info is:
>
> 
>
> Takeshi, Feras - please do join the call.
>
> If members of the p-html-media group want to join, that should be fine.
>

Thanks.

Me too over telephone and IRC.

Takeshi

Re: Push API and Service Workers

[Arthur Barstow]

On 10/22/14 1:21 AM, Shijun Sun wrote:

On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote:

If we want to take advantage of this opportunity, perhaps you
should first flesh out specific issue(s) to discuss, and then try to agree on a 
time
+ day slot in advance of the meeting.

Thanks Arthur for the suggestion.

I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
scenarios using push messages.  The goal is to make sure we understand the 
steps and options in the whole E2E story.  If this is a right topic and there 
is enough interest in the group, I can set up a Doodle to help us pick the 
timeslot.


Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:



If people want to attend remotely, see:



-Thanks, AB

Re: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Arthur Barstow]

On 10/23/14 1:26 PM, Domenic Denicola wrote:

From: Arthur Barstow [mailto:art.bars...@gmail.com]


I think recent threads about Streams provided some useful information about the 
status and plans for Streams. I also think it could be useful if some set of 
you were available to answer questions raised at the meeting. Can any of you 
commit some time to be available? If so, please let me know some time slots you 
are available. My preference is Monday morning, if possible.

I'd be happy to call in at that time or another. Just let me know so I can put 
it in my calendar.


OK, I just added Streams to the 11:00-11:30 slot on Monday Oct 27:



IRC and Zakim phone bridge info is:



Takeshi, Feras - please do join the call.

If members of the p-html-media group want to join, that should be fine.

-Thanks, AB

[clipops] Oct 2014 status report and plans

[Hallvord R. M. Steen]

Status of the Clipboard API spec: There are some open bugs. The test suite is 
on its way into web-platform-test but there's no progress on the review AFAIK.

Apart from those bugs I think the spec is quite solid. Here are the bugs:
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Clipboard%20API%20and%20events&resolution=---

I'll comment on each to give a status update, please comment in the relevant 
bugs if you have input or ideas:

21700   spec "strip possibly dangerous content before inserting rich text paste 
markup"
I was hoping there is an algorithm to sanitize HTML somewhere else that we can 
just reference. A full algorithm doesn't really belong in this spec. I haven't 
so far found the right thing to refer to.

21699   [spec.next] figure out how to make clipboard data type support 
discoverable
This requires coming up with a new API method and resolving fingerprinting 
concerns. It would be nice to have but I haven't figured it out yet, and IMO we 
can ship the current spec first and do this in a future version..

23538   Sort out markup from local source (i.e. word processor) referencing 
images on disk
This needs some feedback from developers who have worked on clipboard 
integration on various platforms. The main question: is it generally possible 
on [platform] to tell whether a string of HTML was placed on the clipboard by a 
local application? Some HTML on the clipboard might come from 

* a web page, opened in some random web browser, content copied by the user or 
written to clipboard by JS
* a word processor or other software running locally

Is there any hope of being able to distinguish those scenarios across 
platforms? If not we need to wontfix this and change the spec accordingly.


27010   allow beforepaste event listeners to inspect type of clipboard contents 
(?)
This is a relatively easy fix, but it may have some privacy implications that 
we haven't figured out yet.

21698   figure out if we can add MathML to "Mandatory data types" list
This one probably just needs a bit more discussion and votes for/against? I'm 
not sure what this requires from implementors or what native types (if any) 
match MathML.

23536   figure out if "mixed clipboard content" is testable, write tests if it 
is
Still don't know how or if this really works on various platforms.

23537   [spec.next] expose origin of HTML markup when possible?
IE adds some meta data to the HTML when writing it to the clipboard. We should 
perhaps spec IE's format, or maybe mandate that implementations writing HTML to 
the clipboard should also add a text/uri-list entry giving the original 
location of the HTML content? Then we might add an event.sourceURL property. 
This is also a features-vs-privacy thing, I'm not absolutely certain I want to 
inform any page I paste into what page I copied something from. But some pages 
or apps could probably make good use of this information.

I'd like to get 21700, 23538, 27010 and 21698 addressed before a new WD. Input 
from implementors and web developers is always welcome, of course.
-Hallvord

[admin] Positive Work Environment Framework now in effect

[Yves Lafon]

-- Forwarded message --
Date: Thu, 23 Oct 2014 19:56:30 +0200
From: Coralie Mercier 
To: w3c-ac-fo...@w3.org
Cc: cha...@w3.org
Subject: Positive Work Environment Framework now in effect
Resent-Date: Thu, 23 Oct 2014 17:56:45 +
Resent-From: cha...@w3.org


Dear Advisory Committee Representative,
Chairs,

The Positive Work Environment Task Force [1] is pleased to announce, with 
approval by W3C management and support from the Advisory Board, that the 
following guidelines are now in effect and govern our work environment:


 Code of Ethics and Professional Conduct:
 http://www.w3.org/Consortium/cepc/

 Procedures to assist all parties in case of issues:
 http://www.w3.org/Consortium/pwe/#Procedures


W3C is a growing and global community where participants choose to work 
together, and in that process experience differences in language, location, 
nationality, and experience.


Our Code of Ethics and Professional Conduct defines principles for respectful 
treatment within the W3C community, and it promotes high standards of 
professional practice. It also provides a benchmark for self evaluation and 
acts as a vehicle for better identity of the organization which celebrates its 
20th anniversary this month.


This code, complemented by a set of Procedures, applies to any member of the 
W3C community ? staff, members, invited experts, participants in W3C meetings, 
W3C teleconferences, W3C mailing lists, W3C conference or W3C functions, etc.



Comments should be sent to  which will be publicly archived 
[2]. The Member task force [1] remains chartered to handle the next revisions 
of the documents. If you are interested in joining it, please contact Coralie 
Mercier  or Daniel Dardailler , co-chairs of the 
task force.



Coralie Mercier, W3C Communications

[1] https://www.w3.org/2011/07/Positive-Work-Environment-TF.html
[2] http://lists.w3.org/Archives/Public/public-pwe/


[Bcc: public-...@w3.org, member-pw...@w3.org]


--
Coralie Mercier  -  W3C Communications Team  -  http://www.w3.org
mailto:cora...@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/