Janina Sajka | 31 Mar 18:40 2015

IndieUI Teleconference Agenda; 1 April at 21:00Z

Cross-posting as is usual ...

IMPORTANT: Much of Europe (along with other locales) have now joined
North America on Summer Time. Please carefully confirm the time of this
teleconference in your locale using the references below.

What:	IndieUI Task Force Teleconference
When:	Wednesday 11 March
	 2:00 PM        San Francisco -- U.S. Pacific  Time	(PDT: UTC -7)
	 4:00 PM        Austin -- U.S. Central  Time		(CDT: UTC -5)
	 5:00 PM        Boston -- U.S. Eastern  Time		(EDT: UTC -4)
	10:00 PM        London -- British  Time	(BST: UTC +1)
	11:00 PM        Paris -- Central European Time		(CET: UTC +2)
	 5:00 AM        Beijing -- China Standard Time	(Thursday, 19 March CST: UTC +8)
	 6:00 AM        Tokyo -- Japan Standard Time	(Thursday, 19 March JST: UTC +9)
Where:	W3C Teleconference--See Below

* Time of day conversions

Please verify the correct time of this meeting in your time zone using
the Fixed Time Clock at:


** Preliminary Agenda for IndieUI Task Force Teleconference 1 April 2015

Meeting: IndieUI Task Force Teleconference
Chair:	Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+	Future of the IndieUI WG & TF: WBS Followup -- Janina
(Continue reading)

bugzilla | 30 Mar 15:12 2015

[Bug 28373] New: FilePropertyBag can inherit from BlobPropertyBag


            Bug ID: 28373
           Summary: FilePropertyBag can inherit from BlobPropertyBag
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
          Assignee: arun@...
          Reporter: simonp@...
        QA Contact: public-webapps-bugzilla@...
                CC: public-webapps@...

FilePropertyBag can inherit from BlobPropertyBag (and remove type from

Minor IDL tweak that should have no effect on observable behavior I think.


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

Gulfaraz Yasin | 26 Mar 13:30 2015

Obsolete Document


It has come to my notice that the following document

is obsolete.

I was directed to it's page from one of StackOverflow's answers and after following up a bit I've been informed that the above document is obsolete.

It would be very helpful if there was a notice on the page that informed it's visitors of the same.

Gulfaraz Yasin
Wayne Carr | 29 Mar 01:17 2015

charter template for Community Group used by a large Working Group

Sending this in case it's something WebApps may be interested in. It's a 
Community Group Charter template [1] designed to create a Community 
Group that is used by a large Working Group like WebApps or CSS or DAP 
to do things like investigate areas that aren't ready for 
standardization.  It would be like an incubator group for the Working 

That can already be done in separate Community Groups unrelated to the 
Working Group (and that would continue).  The only difference is that 
for this Community Group, the affiliated Working Group controls the 
Charter (and can ensure it has provisions that guarantee fairness) and 
the WG can direct what specs can be worked on in their affiliated 
Community Group.

Someone who wants a spec to get into WebApps could approach the WG, and 
if the WG was interested, but not sure, it could ask them to do it in 
the affiliated CG.  WG members who wanted to work on more exploratory 
work without having to license all the exploratory work could join the 
affiliated Community Group and opt-in to work on particular specs. (so 
it's one affiliated Community Group, potentially with dozens of 
incubator specs and participants explicitly opt-in to specs their 
employer's want them to work on).

An affiliated CG like this could be a good place to start work on a 
risky spec that may not succeed.  In a Community Group, patent licensing 
for one's own contributions happens right away (not when its finished) 
and the copyright license allows anyone to pick it up and work on it 
elsewhere, so if it fails, but some are interested, they can continue to 
work on it.  It's more difficult to continue work elsewhere (like in a 
Community Group) when a WG spec fails.

Just passing this on in case it is of interest.  I also posted a couple 
of other templates for other types of Community Groups to the same list, 
both not directly affiliated with a WG.  One is for potentially large 
number of specs or where the scope and deliverables are not clear and 
another one for a more focused Community Group that knows what specs it 
wants to produce (the current template on the CG site changed to use 
GitHub).  For all of these, a goal is to have it be easier to get 
permission to join the Community Group because the scope is either clear 
or else obligations are per spec when you opt-in.

[1] https://lists.w3.org/Archives/Public/public-council/2015Mar/0012.html

bugzilla | 27 Mar 07:07 2015

[Bug 28353] New: [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. <ol>/<li>


            Bug ID: 28353
           Summary: [Shadow]: Use a parent/child relationship in the
                    composed tree for some elements, i.e. <ol>/<li>
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: hayato@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...
            Blocks: 14978

For example, suppose the following case:

<div id="shadow-host">


Unfortunately, this should not be rendered as intended, if we interpret the
spec [1] strictly.

[1]: https://html.spec.whatwg.org/multipage/forms.html#the-summary-element

The spec says:

> Contexts in which this element, <summary>, can be used:
>   As the first child of a details element.

The same discussion might be also applied to the following elements, including,
but not limited to:

- <tr>/<td>
- <ol>/<li>

I've not investigated carefully yet. We have to investigate further.

In Blink, AFAIR, we've spent some efforts to support these elements so that
they are rendered correctly as intended even though they form a parent/child
relationship in the composed tree, rather than in a node tree. However, I'm
afraid that no one has a clear idea what behavior is correct.

If we are to support these cases, the spec must specify that somehow.


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

Travis Leithead | 26 Mar 21:26 2015

RE: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

Microsoft supports publishing this. Thanks to all involved!

Subject: 	CfC: publish Proposed Recommendation of Web Messaging; 
deadline March 28
Date: 	Sat, 21 Mar 2015 08:51:45 -0400
From: 	Arthur Barstow <art.barstow <at> gmail.com>
To: 	public-webapps <public-webapps <at> w3.org>

As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [<2]. The two tests, including a short 
analysis of the failure, are:

1. <http://www.w3c-test.org/webmessaging/with-ports/026.html>; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.

2. <http://www.w3c-test.org/webmessaging/without-ports/025.html>; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.

Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.

As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.

If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.

-Thanks, ArtB

[All] <http://w3c.github.io/test-results/webmessaging/all.html>
[<2] <http://w3c.github.io/test-results/webmessaging/less-than-2.html>
[PR] <http://www.w3.org/TR/2015/PR-webmessaging-20150407/>
[CR] <http://www.w3.org/TR/2012/CR-webmessaging-20120501/>
[PC] <http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports>
[Diff] <https://www.diffchecker.com/qswiibb5>

Travis Leithead | 26 Mar 18:53 2015

[Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

Hi folks,


Today’s ShadowDOM model is designed around only adding shadow roots to element in the ‘light side’. I assume this is intentional, but was hoping someone could describe why this design was chosen? Or said another way, if there was an imperative API to _remove_ a shadow DOM, would that symmetry be bad?


In full transparency, I’m thinking about potential solutions for a simplified shadow dom, and it occurs to me that it can’t get much simpler than the following:

·        Elements only [ever] have one “shadow side” which is essentially a secondary child node list. Whenever anything’s in this list the Element renders that content instead of its “light” children. (Or maybe there’s a switch to tell the element which side to render: light or dark?)

·        Elements expose this “shadow node list” via APIs that are very similar to existing node list management, e.g., appendShadowChild(), insertShadowBefore(), removeShadowChild(), replaceShadowChild(), shadowChildren[], shadowChildNodes[].

·        No special Event swizzling, no security boundary, no alternate script engine, no intermediate shadow root object,  etc. This minimalist approach only provides node ‘hiding’ and potentially an alternate rendering path.

·        Another feature could then provide the stronger “component” boundary, specifically the javascript global scope isolation. This delineation may more closely match the division we are seeing between the “React-like” scenarios and more robust component-kitchen-style custom element deployments.



Arthur Barstow | 26 Mar 15:51 2015

[websockets] Test results available

Earlier today I ran the Web Sockets tests on Chrome 41, Chrome/Canary 
43, FF Nightly 39, IE 11, and Opera 12 and pushed the results to the 
test-results repo:

* All results <http://w3c.github.io/test-results/websockets/all.html>

* <2 passes <http://w3c.github.io/test-results/websockets/less-than-2.html>

Overall these results are pretty good: 97% of the 495 tests have two or 
more passes.

If anyone is willing to help with the failure analysis, that would be 
very much appreciated.

Odin, Simon - for the purposes of evaluating these results and the 
Candidate Recommendation (exit criteria), should the Opera data be included?

-Thanks, ArtB


[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/


Software Engineer, Shenzhen, BGI

bugzilla | 25 Mar 12:35 2015

[Bug 28332] New: Remove any border and padding from fullscreen iframes


            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: annevk@...
          Reporter: philipj@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

The spec current has this:

iframe:fullscreen {

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:

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.

bugzilla | 23 Mar 17:12 2015

[Bug 27552] Make execCommand("InsertImage", false, "") insert an img element with no src attribute


Simon Pieters <simonp@...> changed:

           What    |Removed                     |Added
                 CC|                            |simonp@...
         Resolution|WORKSFORME                  |LATER

--- Comment #5 from Simon Pieters <simonp@...> ---
(LATER seems like a better fit)


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