TPAC 2016 Registration Now Open

[Philippe Le Hegaret]

As a reminder, the Web Platform Working Group will meet as follows:
[[
 19 September: Web Components. (TPAC 2016, Lisbon, Portugal)
 20 September: Service Workers. (TPAC 2016, Lisbon, Portugal)
 22 September: Editing and Selection. (TPAC 2016, Lisbon, Portugal)
 23 September: HTML, Directory upload, plenary session (overview of
   everything), Any Other Business.
   (TPAC 2016, Lisbon, Portugal)
]]
https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md


Registration for TPAC is now open:

   TPAC 2016
   19-23 September 2016
   Centro de Congressos de Lisboa
   Lisbon, Portugal
   https://www.w3.org/2016/09/TPAC/

We invite all TPAC participants to:

  1) Register (see below).
  2) Make your hotel reservation via the hotel booking link:
 http://www.delegatehotels.com/e/w3c2016

W3C has arranged discount room rates from 17 (check-in) until 24 
September 2016 (check-out) with three different hotels.
We strongly recommend to make hotel reservations before the Summer 
starts (June, early July) as September is a very busy period in Lisbon.


For booking tips and more information about hotels, see:

https://www.w3.org/2016/09/TPAC/Hotels-Transportation.html#accommodations

For more details about the TPAC 2016 venue, refer to:
   https://www.w3.org/2016/09/TPAC/Overview.html#venue

Please direct questions to w3t-tpregis...@w3.org.

Thank you,

Philippe

Re: [Web Components] Editor for Custom Elements

[Philippe Le Hegaret]

On 04/06/2016 03:34 PM, Domenic Denicola wrote:

From: Léonie Watson [mailto:t...@tink.uk]


Domenic Denicola briefly stepped into the role, but regretfully he has since
declined to work within the W3C community [2].


That is not at all an accurate description of what has happened. I've very much enjoyed 
working with the W3C community on the w3c/webcomponents issue tracker, and think the 
collaboration there has been a success. It was a very helpful "incubation 
phase" for custom elements.


I do believe that the W3C community enjoyed working with you as well. I 
certainly did at the last Web components f2f meeting.


But I hope you realize that coming in the W3C community, working with 
them for while, and then take things away to continue the work elsewhere 
is received as not working in good faith with the W3C community. This is 
not a judgment of whether it was the right technical decision to do or 
not but rather a pure social judgment. People in W3C working groups 
don't expect to be told to go somewhere else after they contributed for 
a while. Now, if you're interested in figuring out a way to solve this, 
I'm sure plenty of folks in the W3C community, myself included, would be 
interested in finding a way.


Philippe

Re: Art steps down - thank you for everything

[Philippe Le Hegaret]

Thank you Art.

You carried out this group and community over so many years.

Your first email to the AC was entitled "Just say NO?" as a response to 
a proposal from W3C. It will take a while for me to realize you won't be 
standing and come to the microphone to challenge us as you used to do 
for so many years.


Philippe

On 01/28/2016 10:45 AM, Chaals McCathie Nevile wrote:

Hi folks,

as you may have noticed, Art has resigned as a co-chair of the Web
Platform group. He began chairing the Web Application Formats group
about a decade ago, became the leading co-chair when it merged with Web
APIs to become the Web Apps working group, and was instrumental in
making the transition from Web Apps to the Web Platform Group. (He also
chaired various other W3C groups in that time).

I've been very privileged to work with Art on the webapps group for so
many years - as many of you know, without him it would have been a much
poorer group, and run much less smoothly. He did a great deal of work
for the group throughout his time as co-chair, efficiently, reliably,
and quietly.

Now we are three co-chairs, we will work between us to fill Art's shoes.
It won't be easy.

Thanks Art for everything you've done for the group for so long.

Good luck, and I hope to see you around.

Chaals

Notes from Custom Elements meeting

[Philippe Le Hegaret]

Available at
   https://www.w3.org/2016/01/25-webapps-minutes.html


Text version:

 Web Platform - Custom Elements

25 Jan 2016

   See also: [2]IRC log

  [2] http://www.w3.org/2016/01/25-webapps-irc

Attendees

   Present
  Domenic_Denicola, Takayoshi_Kochi, Léonie_Watson,
  Travis_Leithead, AnneVK, Arron_Eicholz, Chaals,
  Dimitri_Glazkov, Elliott_Sprehn, Hayato_Ito,
  Ted_OConnor, Jan_Miksovsky, Justin_Fagnani,
  Ryosuke_Niwa, Plh, Monica, Antti, Smaug, William_Chen

   Regrets

   Chair
  chaals

   Scribe
  Plh, Travis, dglazkov, rniwa, esprehn, chaals

Contents

 * [3]Topics
 1. [4]agenda bashing
 2. [5]lifecycle callback timing
 3. [6]Symbol Name vs String name
 4. [7]Symbol or String
 5. [8]is=
 6. [9]upgrade is top-down, right?
 7. [10]Shadow DOM Styling
 8. [11]Imports
 9. [12]registry
 * [13]Summary of Action Items
 * [14]Summary of Resolutions
 __

   [introductions]

agenda bashing

[15]Contentious bits: things for the agenda

 [15] 
https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits


   Travis: looking at contentious bits, we should do: review of
   constructors, simple name properties, attribute change callback
   ... [...]

   dglazkov: we should start with least contentious

lifecycle callback timing

   Travis: so is it documented yet when to fire a nano task?

   Anne: when IDL returns, but not documented yet

   dglazkov: there is a queue

   Anne: just before you return from the method call, there would
   be a nanotask

   Travis: we assume it's introduced when to invoke a method in
   WebIDL
   ... if a nano can queue more work that results in a
   microtask...

   Ryosuke: you have a stack of nanotask

   Travis: so sync but delayed after the operation...

ACTION: chaals file issue on WebIDL to get the
   nanotask flow documented [recorded in
   [16]http://www.w3.org/2016/01/25-webapps-minutes.html#action01]

 [16] http://www.w3.org/2016/01/25-webapps-minutes.html#action01]

   [this is resolved]

   RESOLUTION: We're happy to do it like this

Symbol Name vs String name

   Travis: concern is: what if we move the logic of custom element
   and put it into mutation observers?
   ... so that you have one API for observing mutations
   ... attach/detach/reparenting should be addressed in mutation
   observers
   ... in addition to want nanotask timing

   Ryosuke: that would bring queing vs tasking
   ... one reason to design this way was that it was easy for
   mutation observer to step on each other
   ... if you modify something in a mutation observer, you have no
   idea of the ordering
   ... if we move the logic, we would reintroducing the problem

   Travis: I just want to move the API surface
   ... to make it general purpose
   ... I don't have to create a new API
   ... just have to take care of the constructor

   Ryosuke: make sense to me

   Travis: I'm saying we should not punt on it, but would like to
   transition

one of the reasons for MutionObservers was performance,
   which is a lot better than with more sync (nanotask-like)
   MutationEvents.

   Anne: how would we do that?

(microtasks give the better performance)

   [break to bring Domenic]

See
   [17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 Travis

 [17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250

   Ryosuke: some elements affect others only if they are in the
   document (base, style)

   Domenic: detached documents are so rare that yes, we can leave
   it as an edge case we don't solve

   dglazkov&Ryosuke: agreed

   dglazkov: I like the idea of a generic callback

   Ryosuke: so, if we add the attribute filter, it might be ugly
   to have two different was to follow attributes changing.

   domenic: making sure they match it's fine, but it's important
   to have both. eg being notify when creating custom elements

   travis: you can only observe your own attributes, so damage is
   limited

   ryosuke: we have a bunch of other sync events, not sure if it
   matters
   ... with a microtask ending, you would batch those if lots of
   elements
   ... range functions will operate on custom elements. nanotask
   will fire at the end of the range operation

   anne: but that might not involve any IDL
   ... at least, it's not written down

   RESOLUTION: generic callback need be written down, instead of
   detach/attach

[18]https://github.com/w3c/webcomponents/issues/362

 [18] https://github.com/w3c/webcomponents/issues/362

   Ryosuke: when navigating an iframe, you would fire those
   callbacks

   Anne: except that script execution is stalled

   Domenic: if had a parent browsing context change callback could
   do the trick

Ryosuke: We don't want the author scripts to run
   when you naviga

[admin] Web Platform WG is really the new WebApps

[Philippe Le Hegaret]

Hi All,

back in October, we started the Web Platform WG [1] and invited folks to 
join the new Group at the time [Register]. We did not formally closed 
down the Web Applications Working Group however.


This is an advance notice that we are going to close down the Web 
Applications Working Group on December 3.


Folks should ensure that they joined the Web Platform Working Group by 
then to avoid being disrupted if you're currently part of the Web 
Applications Working Group (if that's not the case, you can safely 
ignore this email).


If you have any questions, concerns, etc., please let us know.

Thank you,

Philippe

[1] https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0058.html
[Register] 

High Resolution Time 2: time origin and worker support

[Philippe Le Hegaret]

The latest version of High Resolution Time is ready for wide review.

One can find the latest draft at:
  http://www.w3.org/TR/hr-time-2/

High Resolution Time Level 2 replaces the first version of High 
Resolution Time [HR-TIME] and includes:


* Defines a precise definition of time origin for the purpose of all 
performance timeline related specifications;


* Provides the base definition for the Performance interface, including 
support for the Performance.now method in Web Workers [WORKERS];


* Introduces the method Performance.translateTime to compare times 
between different time origins;


* To mitigate cache attacks, the recommended minimum resolution of the 
Performance interface should be set to 5 microseconds.


The method Performance.translateTime is marked as "at risk" to the 
purpose of moving High Resolution Time 2 to W3C Recommendation due to 
its lack of implementation experience. It is expected to be deferred 
until the next release at the moment.


New issues are welcome at
 https://github.com/w3c/hr-time/issues

Thank you,

Philippe

Re: Normative references to Workers.

[Philippe Le Hegaret]

On 09/15/2015 03:26 PM, Daniel Veditz wrote:

On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. mailto:jackalm...@gmail.com>> wrote:

​there's nothing wrong with reffing WHATWG specs.  It will not delay
​ or hamper​

publication or Rec-track advancement, despite the
​ occasional misinformed​

complaint from someone not aware of the
​ ​
policies.


​When the complaint comes from the office of the Director we have to
assume it's going to hamper us whether or not they are misinformed.


To be clear here: the point made was that the Web Application Security 
group never asked for a review from the Web Applications working group 
prior to asking for transition to CR. As a consequence, the WebApps 
group did not get an opportunity to review the Upgrade Insecure 
Resources specification [1], including the reference related to Web Workers.
As a reminder, there is an expectation that the specification has 
received wide review prior to the publication of a Candidate Recommendation.


Philippe

[1] http://www.w3.org/TR/upgrade-insecure-requests/

Re: URL bugs and next steps

[Philippe Le Hegaret]

On 06/16/2015 10:33 AM, Anne van Kesteren wrote:

On Tue, Jun 16, 2015 at 4:25 PM, Philippe Le Hegaret  wrote:

Things haven't been moving at fixing the bugs in the URL specification. Sam
has circulated a list of issues but did not receive much feedback. I figured
the best way to understand to make progress would be to have a call so we
can figure out the path forward and how we're going to fix the specification
and the implementations.


I'm in the process of fixing bugs and adding tests, actually.


That's great but are we getting the implementations aligned?


If you can attend, this would be helpful to make progress.


There's quite a bit of outstanding feedback from various vendors that
can be addressed first, I think. Not sure what you expect to resolve
on this call?


My understanding is that implementations are still differing from the 
spec and we weren't getting them to move. Reasons for that are differing 
between the vendors.


My expectation for the call would be that we understand why that's the 
case and see if we can get a common understanding on how we can move 
forward to achieve interop. For example, the idea of having a f2f 
meeting was floated before and more recently. I'd like to know if there 
is indeed such interest before asking folks to cross continents or oceans.


Philippe

URL bugs and next steps

[Philippe Le Hegaret]

[resending with Anne and public-webapps. I was asked to add both and 
forgot. Apologizes for the omission]


Things haven't been moving at fixing the bugs in the URL specification. 
Sam has circulated a list of issues but did not receive much feedback. I 
figured the best way to understand to make progress would be to have a 
call so we can figure out the path forward and how we're going to fix 
the specification and the implementations.


I create a doodle at
  http://doodle.com/r6h68swhyq86k2r4

If you can attend, this would be helpful to make progress.

Thank you in advance,

Philippe

Observers added to Performance

[Philippe Le Hegaret]

Webperf landed earlier this week a proposal [1] to add observers of 
performance entries:


[[
The |PerformanceObserver| 
 
interface can be used to observe the Performance Timeline 
 
and be notified of new performance entries as they are recorded by the 
user agent. A registered performance observer consists of an observer (a 
|PerformanceObserver| 
 
object) and options (a |PerformanceObserverInit| 
 
dictionary).

]]

http://w3c.github.io/performance-timeline/#the-performance-observer-interface

We'd appreciate early review of the proposal and feedback is welcome in 
github and public-web-p...@w3.org 
.


Thank you in advance,

Philippe

[1] https://github.com/w3c/performance-timeline/pull/10

Re: Feedback needed for April 2015 face-to-face location by *January 27, 2015*

[Philippe Le Hegaret]

On Wed, 2015-01-21 at 02:03 +0300, cha...@yandex-team.ru wrote:
> 21.01.2015, 01:40, "Philippe Le Hegaret" :
> > All,
> >
> > We are fortunate enough to have two proposed locations for the HTML and
> > Web Applications face-to-face meeting in the week of April 13-17, 2015.
> > Your feedback will help us picking the location.
> >
> > 1. Redmond, WA, USA (Hosted by Microsoft):
> > 2. Zaragoza, Spain (Hosted by Yandex)
> 
> Actually it is hosted by the Ayuntamiento de Zaragoza (i.e. the city council, 
> who have been a member for about a decade, and do a lot of good stuff. I just 
> asked around for a host and passed on their very generous offer).
> 
> > Please provide your preferences at:
> >   https://www.w3.org/2002/09/wbs/42538/webapps-spring-2015/
> 
> I can't fill in the survey yet ;(

My mistake. You should be able to now.

Philippe

Feedback needed for April 2015 face-to-face location by *January 27, 2015*

[Philippe Le Hegaret]

All,

We are fortunate enough to have two proposed locations for the HTML and
Web Applications face-to-face meeting in the week of April 13-17, 2015.
Your feedback will help us picking the location.

1. Redmond, WA, USA (Hosted by Microsoft): 
2. Zaragoza, Spain (Hosted by Yandex)

Please provide your preferences at:
  https://www.w3.org/2002/09/wbs/42538/webapps-spring-2015/

by January 27, 2015.

We will then try to make sense out of the input and pick the location.

Thank you in advance,

Philippe

Re: CfC: publish WG Note of UI Events; deadline November 14

[Philippe Le Hegaret]

On Wed, 2014-12-10 at 10:22 -0500, Arthur Barstow wrote:
> Hi Travis, Gary, Philippe,
> 
> Since Anne's proposal hasn't been implemented, what exactly is the plan 
> for these two specs?
> 
> There is also a related proposal "DOM L3 Events Input Events Work to the 
> Editing Task Force" by Ben [Ben] and followup by Gary [Gary].
> 
> What do you recommend here, i.e., Who is going to do What and When?

I sent a few questions to the editors on this front but didn't receive
responses. I'd like some guidances here before publishing.

Philippe

Re: CfC: publish WG Note of UI Events; deadline November 14

[Philippe Le Hegaret]

On Wed, 2014-11-19 at 09:44 -0500, Arthur Barstow wrote:
> On 11/19/14 9:35 AM, Anne van Kesteren wrote:
> > On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow  
> > wrote:
> >> Although there appears to be agreement that work on the [uievents] spec
> >> should stop, the various replies raise sufficient questions that I consider
> >> this CfC (as written) as failed.
> >>
> >> Travis, Gary - would you please make a specific proposal for these two
> >> specs? In particular, what is the title and shortname for each document, 
> >> and
> >> which spec/shortname becomes the WG Note?
> >>
> >> After we have agreed on a way forward, I'll start a new CfC.
> >>
> >> (I believe the Principle of Least Surprise here means considering specs 
> >> that
> >> currently reference [uievents] or [DOM-Level-3-Events]. F.ex., I suppose a
> >> document titled "UI Events" with a shortname of DOM-Level-3-Events could be
> >> a bit confusing to some, although strictly speaking could be done.)
> > My proposal would be to update UI Events with the latest editor's
> > draft of DOM Level 3 Events (title renamed, of course) and have the
> > DOM Level 3 Events URL redirect to UI Events. That would communicate
> > clearly what happened.
> 
> Yves, Philippe - can Anne's proposal be done?

I'm not aware of any reason that would prevent us from doing so.

Philippe

Re: First Draft of W3C version of URL Spec

[Philippe Le Hegaret]

On Fri, 2014-08-29 at 21:04 +0200, Anne van Kesteren wrote:
> On Fri, Aug 29, 2014 at 8:11 AM, Julian Reschke  wrote:
> > "W3C-specific note: This specification documents current RFC 3986 and RFC
> > 3987 handling in contemporary Web browser implementations. As a consequence,
> > this specification is not compatible with those RFCs. It is published for
> > the purpose of providing a stable reference for the HTML5 specification and
> > reflecting current Web browser HTML5 implementations. The W3C Technical
> > Architecture Group expects to continue the work on the URL specification and
> > produce a future version that will attempt to re-align the URL specification
> > with an updated version of RFC 3986 while preserving interoperability."
> 
> That's a contradictory goal. Anyway, if W3C actually wanted to help
> here they would focus on getting implementations aligned with the
> specification before starting to fork and seed confusion. That's the
> biggest problem for the web at the moment when it comes to URLs.

I would qualify it as ambitious, rather than contradictory. :)
Re-aligning the URL specification with RFC3986.next will take time and a
lot of effort, especially with the intent of preserving
interoperability.

And yes, for the immediate short term, the focus is on aligning the Web
implementations with the specification as much as we can.

Philippe

FYI: Navigation Error Logging

[Philippe Le Hegaret]

This specification defines an interface to store and retrieve error data
related to the previous navigations of a document:
  http://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/

As usual, we welcome all feedback on public-web-p...@w3.org

Thank you,

Philippe

Re: Call for Exclusions: W3C DOM4

[Philippe Le Hegaret]

Coralie,

W3C DOM4 is only done in HTML, not WebApps. Is it possible to update the
CfE?

Philippe

On Tue, 2014-02-04 at 18:06 +0100, Coralie Mercier wrote:
> Dear Advisory Committee representative,
> 
> This is a W3C Patent Policy Call for Exclusions for the following
> Recommendation Track document:
> 
> - W3C DOM4
>(http://www.w3.org/TR/dom/),
>exclusion opportunity ending on  5 April 2014 23:59 UTC
> 
> 
> This specification was produced by the following groups:
>   - HTML Working Group
>   - Web Applications Working Group
> 
> If you do not wish to exclude patent claims during this exclusion
> opportunity, no further action is required. Member participants who think
> their organization may have patent claims to exclude should contact their
> Advisory Committee Representative.
> 
> Participants made a Royalty-Free licensing commitment upon joining this
> Working Group. With the publication of this document, per section 4.1 of
> the Patent Policy [1], Participants have an opportunity until  5 April 2014
> 23:59 UTC to exclude patent claims reading on this Last Call draft.  At
> Last Call, exclusions are limited to matter in the Last Call draft that was
> not present or apparent in this draft:
> http://www.w3.org/TR/2013/WD-dom-20131107/
> http://www.w3.org/TR/2010/WD-domcore-20101007/
> 
> 
> Excluded claims are not subject to the licensing requirements of the W3C
> Patent Policy for this document. For more information about exclusions,
> please see
>http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
> 
> To make exclusions, please use one of the following forms:
>   HTML Working Group: http://www.w3.org/2004/01/pp-impl/40318/exclude
>   Web Applications Working Group:  
> http://www.w3.org/2004/01/pp-impl/42538/exclude
> 
> Summary information for these groups related to the W3C Patent Policy is
> available at:
>   HTML Working Group: http://www.w3.org/2004/01/pp-impl/40318/status
>   Web Applications Working Group:  
> http://www.w3.org/2004/01/pp-impl/42538/status
> 
> If you have any questions or need further information, please contact,
> for the HTML Working Group:
>   * Michael[tm] Smith at m...@w3.org
> for the Web Applications Working Group:
>   * Yves Lafon at yla...@w3.org
> 
> For more information on the W3C Patent Policy and patent claim
> exclusions, see:
>http://www.w3.org/2003/12/22-pp-faq
> 
> Thank you,
> 
> For Tim Berners-Lee, W3C Director;
> Coralie Mercier, W3C Communications
> 
> [1] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with
> [2]  
> http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-resign
> 

Last Call for High Resolution Time Level 2

[Philippe Le Hegaret]

Dear Webapps folks,

The Web Performance Working Group published a new version of High
Resolution Time (performance.now()) to add support for Web Workers:
[[

interface WorkerPerformance {
  DOMHighResTimeStamp now();
};

partial interface WorkerGlobalScope {
  readonly attribute WorkerPerformance performance;
};

partial interface SharedWorker {
  readonly attribute DOMHighResTimeStamp workerStart;
};

]]

Draft is at
 http://www.w3.org/TR/hr-time-2/

Please, send your feedback to public-web-p...@w3.org, using
[HighResolutionTime2] at the start of the subject line by 8 January
2014.

Thank you in advance,

Philippe

Re: FYI: Resource Priorities and Beacon API

[Philippe Le Hegaret]

On Wed, 2013-10-30 at 13:23 -0400, Philippe Le Hegaret wrote:
> FYI,
> 
> the Web Performance Working Group just published Resource Priorities and
> Beacon yesterday and we're interested in feedback on the ideas and
> approaches. Resource priorities allows you to tweak the download
> priority of your resources, while Beacon enables synchronously transfer

I meant to say asynchronously here. Thanks to Willian Chan to spotting
my mistake.

> data from the user agent to a web server, under the responsibility of
> the user agent.
> 
>  http://www.w3.org/TR/2013/WD-resource-priorities-20131029/
>  http://www.w3.org/TR/2013/WD-beacon-20131029/
> 
> Feedback should go directly to public-web-p...@w3.org.
> 
> Thank you,
> 
> Philippe
> 

FYI: Resource Priorities and Beacon API

[Philippe Le Hegaret]

FYI,

the Web Performance Working Group just published Resource Priorities and
Beacon yesterday and we're interested in feedback on the ideas and
approaches. Resource priorities allows you to tweak the download
priority of your resources, while Beacon enables synchronously transfer
data from the user agent to a web server, under the responsibility of
the user agent.

 http://www.w3.org/TR/2013/WD-resource-priorities-20131029/
 http://www.w3.org/TR/2013/WD-beacon-20131029/

Feedback should go directly to public-web-p...@w3.org.

Thank you,

Philippe

Re: [admin] DOM4 is now a deliverable of the HTMLWG

[Philippe Le Hegaret]

On Thu, 2013-10-03 at 09:34 -0400, Arthur Barstow wrote:
> FYI, as Philippe announced a few days ago, the HTMLWG's new charter [1] 
> includes DOM4:
> 
> [[
> 
> 
> The new charter includes:
> 
>   * An Dual License experiment for some specifications:
> http://www.w3.org/2013/09/html-charter.html#documentlicense
>   * The addition of the DOM4 specification
> ]]
> 
> Re the rationale for moving this spec to HTMLWG, the following 
> (unfortunately, Member-only) information was provided to Members:
> 
> [[
> 
> 
> The Director made one additional change to this charter as a result of
> discussion: to move the DOM4 specification from the charter of the Web
> Applications Working Group to the HTML Working Group.  The decision is
> the result of several considerations:
> 
>   * The DOM4 specification has not been updated by the Web Applications
> Working Group since December 2012.
>   * The HTML5 specification has a strong dependency on DOM4, so to
> complete HTML5 on time, we need DOM4 to advance.
>   * At the June AC Meeting [2] we sought input on which specifications
> could usefully move to the HTML Working Group as part of
> this experiment. As a result of conversations, it became clear
> that DOM4 was the primary candidate.
>   * The Chairs of both the HTML Working Group and the Web Applications
> Working Group have indicated that they support this move.
> ]]
> 
> Philippe, Robin, Yves - please clarify if the dual license will apply to 
> the HTMLWG's DOM4 spec and the plan for the spec's Editor(s).

Regarding the Document license, the charter should be enough I hope. See
section 8 Document License of the HTML Charter:
[[
The DOM4 specification is also a candidate for the Dual License. 
]]
http://www.w3.org/2013/09/html-charter.html

Regarding the plan for spec editor, my current understanding is that the
HTML Chairs will send a call for editors in the HTML Working Group.

>  My 
> expectation is that www-dom will continue to be used for DOM4 so please 
> confirm that too.

This is also my expectation.

Philippe

Re: Web Storage's Normative References and PR / REC

[Philippe Le Hegaret]

On Fri, 2013-03-08 at 18:23 +, Ian Hickson wrote:
> On Thu, 7 Mar 2013, Philippe Le Hegaret wrote:
> > 
> > The goal is to demonstrate that the materials referenced are stable and 
> > any change to those references won't have an impact on the 
> > recommendations.
> 
> What do you mean by "stable"?

If a specification is using an external feature that has been around for
a while, without substantial changes to its name or definition and with
implementation, the likelihood that it will change is drastically lower.
As such, it is considered more stable than a feature with no
implementation or with a definition that changes every 6 months. So
anything that can help mitigate the risk with regards to change to other
specifications is helpful for the evaluation.

>  If we find something wrong with a REC, we 
> still need to change it, since otherwise browsers are going to implement 
> things that are wrong...

I agree, and we should look into adding tests as well.

Philippe

Re: Web Storage's Normative References and PR / REC

[Philippe Le Hegaret]

On Thu, 2013-03-07 at 12:04 -0500, Arthur Barstow wrote:
> > Hope this helps,
> 
> The above was helpful but I'm wondering about WebStorage's normative 
> reference to DOMCore WD. If we do the same type of evaluation and 
> testing for DOMCore that is needed for HTML5, will that be sufficient to 
> move the spec to REC?

We can certainly advocate for it. Since DOMCore is also in WebApps, that
should make the case easier,

Philippe

Re: Web Storage's Normative References and PR / REC

[Philippe Le Hegaret]

On Thu, 2013-03-07 at 07:28 -0500, Arthur Barstow wrote:
> Yves, Philippe,
> 
> WebApps agreed via [CfC] to publish a Proposed Recommendation of Web 
> Storage [CR] (implementation report is [ImplReport]). The CR has three 
> normative W3C references that are not yet Recommendations: DOMCore WD, 
> HTML5 CR and WebIDL CR. As such, we need you to clarify the implications 
> of these references re publishing a Web Storage PR and REC.
> 
> As I understand it, the Consortium's Process Document is actually silent 
> regarding maturity level of normative references. However, the Team 
> enforces - with some very specific exceptions - a reference policy via 
> "transition rules" ([TransRules]), in particular:
> 
> [[
> Note: In general, documents do not advance to Recommendation with 
> normative references to W3C specifications that are not yet Recommendations.
> ]]
> 
> I _think_ the various processes and policies permit the Web Storage PR 
> to be published with the normative references in their current status. 
> Is this true?

I believe that you are indeed correct.

> However, for the REC to be published, we can either wait until all of 
> the normative references are PRs themselves or we can ask the Director 
> for "exceptions". In case we want to pursue this later exception route, 
> would you please explain, what exactly the group would need to do for 
> each of these references?

The goal is to demonstrate that the materials referenced are stable and
any change to those references won't have an impact on the
recommendations.

For HTML5, by demonstrating that the concepts and features from HTML5
that are used are stable. One can do so by evaluating the referrences
and providing HTML5 tests for the features.

For WebIDL, the Web Applications Working Group advised the Director
that, by providing idlharness.js tests and demonstrating their support,
it would enough to demonstrate that the WebIDL syntax used in the
specifications was stable and well understood.

Hope this helps,

Philippe

[WebIDL] Interface object prototype and function object

[Philippe Le Hegaret]

In
 http://dev.w3.org/2006/webapi/WebIDL/

section 4.4.1 says: "The interface object for a given non-callback
interface is a function object."

section 4 says: "If an object is defined to be a function object, then
it has characteristics as follows: Its [[Prototype]] internal property
is the Function prototype object.[...]"

Does this mean that:
 typeof Document.prototype should return "function" ?

If not, I'm wondering what I'm missing...

Philippe

Re: Reminder: May face-to-face meetings for HTML and WebApps

[Philippe Le Hegaret]

On Wed, 2012-04-11 at 11:03 +1000, Silvia Pfeiffer wrote:
> Is there any possibility to attend remotely for specific topics?

Given the number of individuals in the room, the HTML Chairs at least
decided for not to have a polycom in the room. It didn't seem that the
room would be properly equipped anyway unfortunately,

Philippe

Reminder: May face-to-face meetings for HTML and WebApps

[Philippe Le Hegaret]

Dear All,

This is a friendly reminder for folks to register for the upcoming
face-to-face meetings in one month from today:
  * Web Application Working Group, May 1/2 (Tuesday/Wednesday)
  * HTML Working Group, May 3/4 (Thursday/Friday)
  * Web Application Security Working Group, May 2/3
(Wednesday/Thursday)

Use the form at [1] to register.

Philippe

[1] https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/

May face-to-face meetings for HTML and WebApps

[Philippe Le Hegaret]

Folks,

We found a host for a potential meeting in the first week of May.
Microsoft kindly agreed to give us space in the Silicon Valley.

So, here is a revised proposal:

- WebApps WG: May 1/2 (Tuesday/Wednesday)
- HTML WG: May 3/4 (Thursday/Friday)
- WebAppSec: May 2/3 (Wednesday/Thursday)

Is anybody aware of potential conflicts?

I asked the Chairs to ask for objections to those dates as well, so
speak up if you feel like it.

Note that this meeting would be in addition to the TPAC 2012 in November
(Lyon, France).

Thank you,

Philippe

Re: April face-to-face meetings for HTML and WebApps

[Philippe Le Hegaret]

Dear All,

At this time, the meeting will NOT happen on those dates since we didn't
find a host for the meetings.

I'm looking to see if we could do one in May/June (or July at most). As
soon as we manage to secure a host for it, I'll propose new dates.

Thank you to all who provided feedback,

Philippe

On Mon, 2012-02-06 at 17:58 -0500, Philippe Le Hegaret wrote:
> in order to facilitate the work of the WebApps and HTML Working Groups,
> I've been discussing with the Chairs the idea of having a face-to-face
> in the silicon valley in April. Due to various constraints (WWW2012 and
> Google I/O most notably), I ended up with the second week of April:
> 
> - WebApps WG: April 10/11 (Tuesday/Wednesday)
> - HTML WG: April 12/13 (Thursday/Friday)
> - WebAppSec: April 11/12 (Wednesday/Thursday)
> 
> Is anybody else aware of other potential conflicts?
> 
> The WebKit contributor meeting dates are not set yet but may overlap
> with webapps for one day (April 10)...
> 
> I asked the Chairs to ask for objections to those dates as well,
> 
> Note that this meeting would be in addition to the TPAC 2012 in November
> (Lyon, France).
> 
> Thank you,
> 
> Philippe

April face-to-face meetings for HTML and WebApps

[Philippe Le Hegaret]

Folks,

in order to facilitate the work of the WebApps and HTML Working Groups,
I've been discussing with the Chairs the idea of having a face-to-face
in the silicon valley in April. Due to various constraints (WWW2012 and
Google I/O most notably), I ended up with the second week of April:

- WebApps WG: April 10/11 (Tuesday/Wednesday)
- HTML WG: April 12/13 (Thursday/Friday)
- WebAppSec: April 11/12 (Wednesday/Thursday)

Is anybody else aware of other potential conflicts?

The WebKit contributor meeting dates are not set yet but may overlap
with webapps for one day (April 10)...

I asked the Chairs to ask for objections to those dates as well,

Note that this meeting would be in addition to the TPAC 2012 in November
(Lyon, France).

Thank you,

Philippe

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

[Philippe Le Hegaret]

On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
> Hi All,
> 
> The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 
> months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this 
> PAG has just started its unspecified length Fishing Expedition seeking 
> some unspecified level of funds to pay for some type of analysis that 
> will take some unknown amount of time to complete ...
> 
> Given this, and not wanting to block on the ECC PAG any longer, what are 
> the options to move widgets-digsig to REC ASAP?
> 
> Some options:
> 
> 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would 
> require a new 3-week LC but the CR could be zero-length, presumably no 
> re-testing would be required, and the only thing blocking PR->REC is the 
> length of the new CfE that would be needed.
> 
> 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so 
> XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue on 
> the REC track.
> 
> 3. Others?

An other one was for the Director to decide to move the document forward
anyway because W-DigSig doesn't depend on ECC.

Thomas, any suggestion?

Philippe

New tests for element traversal properties

[Philippe Le Hegaret]

I took a pass at rewriting the existing element traversal tests we have
at [1]:
 http://w3c-test.org/webapps/ElementTraversal/tests/submissions/W3C/

The new tests now relies on testharness.js, so they can easily be
integrated in the framework.

I also submitted those tests to DOM Core as well:
 http://w3c-test.org/webapps/DOMCore/tests/submissions/W3C/

As long as DOM Core does not modify the properties from what is defined
in Element Traversal, I'll keep them in sync. If they diverge, then I'll
only do bug fixes for the Element Traversal ones and will involve the
DOM Core tests instead.

Feedback is welcome of course.

The tests are not ready for approval yet because the new tests are going
beyond what the existing tests were doing:
- the new tests are trying to check if the properties are effectively
read only and there are questions around the assert_readonly function.
- the new tests are doing more on testing the dynamic aspects of the
properties, thus reporting more failures in existing implementations
(unless I got the tests wrong of course).

So, at least until the assert_readonly issue settles down, I don't plan
to ask for those tests to be approved.

In the meantime, I'm more than happy to get feedback and bug reports,

Philippe

[1] http://w3c-test.org/webapps/ElementTraversal/tests/approved/

Last Call: Performance Timeline, User Timing, and Resource Timing

[Philippe Le Hegaret]

This is a Last Call Working Draft transition announcement for the
following 3 documents:

Performance Timeline
 http://www.w3.org/TR/2011/WD-performance-timeline-20110901/
User Timing:
 http://www.w3.org/TR/2011/WD-user-timing-20110901/
Resource Timing:
 http://www.w3.org/TR/2011/WD-resource-timing-20110811/

Deadline of comments on the first two documents is September 22.
Resource Timing is September 15, but due to this late announcement,
please let us know if you're planning to send comments after the
deadline.

Please send comments to public-web-p...@w3.org (archived) with ,
[UserTiming], or [ResourceTiming] at the start of the subject line.

Thank you,

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Tue, 2011-08-16 at 23:59 +0200, Anne van Kesteren wrote:
> On Thu, 04 Aug 2011 17:47:53 +0200, Philippe Le Hegaret  wrote:
> > Several documents in the WebApps Working Group are linking to HTML, more
> > specifically to the WHATWG HTML specification. An example of those is
> > Progress Events. This is done for no reason than political as far as I
> > can tell.
> 
> They used to link to both, but that changed because I changed publishing  
> tools.
> 
> Now you want us to link solely to the W3C version I thought of a problem.  
> The dependency chain for WHATWG HTML becomes WHATWG HTML -> XMLHttpRequest  
> -> W3C HTML. That makes little sense I think.
> 
> Can we change it back to linking to both the W3C and WHATWG version?

But, the WHATWG HTML links to the editor's drafts and does not link to
the TR one. While documents on the REC-track should link to other
documents on the REC tracks, this doesn't apply to editor's draft, which
have no special status anyway. So, you can link to both versions in the
editor's draft if you prefer.

Philippe

WebGL/Khronos liaison (Was: Reference to the HTML specification)

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 14:52 -0400, Arun Ranganathan wrote:
> I'm aware of public-script-coord, and think WG-to-WG coordination is 
> definitely more efficient for technical matters.  I assumed (perhaps 
> incorrectly) existing relations between working groups across 
> organizations (e.g. W3C/IETF) was by virtue of cross-organization 
> coordination by W3C Team, but if you're happy with the status quo and 
> think nothing needs to be done, I'm certainly happy :)

Unless you believe something is broken, I'm inclined to keep the status
quo,

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 13:41 -0400, Arun Ranganathan wrote:
> On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:
> > On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
> >>> Again, what are the reasons to link to the WHATWG HTML version?
> >> If there is something you need that is not in the W3C spec, then it seems 
> >> like a valid reason (e.g., PeerConnection API or some helpful concept).
> > Agreed, but no one has come up with such need so far.
> 
> I refer to the HTML WG's work as normative, but in the File API's 
> Editor's Draft [0], I'd also like to link to the WHATWG document as an 
> informative reference for the Stream API [1]  and LocalMediaStream [2].  
> This is a pragmatic, and not a political, cross-referencing.

I have no issue with that. I would simply note that work is now ongoing
in the WebRTC group so you might want to monitor what they're doing.

> Stream API reuses blob: URIs; LocalMediaStream defines globally unique 
> identifiers in a way that I find useful for the opaqueString 
> production.  I'm tidying up normative and informative links, and in 
> general, I think the time is ripe for a good discussion of affiliated 
> specifications.  Another area for coordination that I'd encourage is 
> between W3C and Khronos, if it isn't happening already.  For instance, 
> File API makes use of ArrayBuffer [3] *normatively* which is defined at 
> Khronos [3] and which is implemented in some user agents.  Is there a 
> formal liaison?  This will benefit WebGL as well.

We don't have a formal liaison with Khronos at the moment. In fact, we
don't do formal liaison in general, we prefer to have technical liaisons
instead (ie directly from Working Group to Working Group). Why would we
need to have a formal liaison in order to reference a specification? Are
you aware of public-script-co...@w3.org [1] ?

Philippe

[1] http://lists.w3.org/Archives/Public/public-script-coord/

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
> > Again, what are the reasons to link to the WHATWG HTML version?
> 
> If there is something you need that is not in the W3C spec, then it seems 
> like a valid reason (e.g., PeerConnection API or some helpful concept).  

Agreed, but no one has come up with such need so far.

> > What
> > does it mean for the work of the HTML Working Group?
> 
> Egos aside, it should not mean anything… one has green headings, the other 
> has blue ones.

In the ideal world, it should not, but the fact that we're having this
exact discussion indicates there is meaning behind. For example, Ian
pointed out earlier that "The W3C one has a growing list of intentional
errors.".

> > There are features
> > in the WHATWG version that got rejected in the HTML Working Group. See
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> > 
> > This list keeps growing.
> > 
> > I don't think it's appropriate for one Working Group to ditch the work
> > of an other.
> 
> Both the W3C and WHATWG have an equal and legitimate authoritative claim over 
> the content of the HTML specification (with real authoritative legitimacy 
> being determined by which version actually gets implemented and by who).  
>
> It should be left to the editor's (or working group) discretion as to which 
> spec they cite regardless of the reason.  

And one of the role of the W3C staff is to ensure proper coordination
between the various Working Groups at the W3C. I'm pointing out we are
being inconsistent,

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 14:32 +, Ian Hickson wrote:
> On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
> >
> > Again, what are the reasons to link to the WHATWG HTML version? What 
> > does it mean for the work of the HTML Working Group? There are features 
> > in the WHATWG version that got rejected in the HTML Working Group. See
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> > 
> > This list keeps growing.
> 
> This is exactly _why_ we should reference the WHATWG copy rather than the 
> W3C one. The W3C one has a growing list of intentional errors.

They're not errors, they're decision by the Working Group. The fact that
the editor of the W3C HTML5 specification considers the differences as
errors is highly disturbing as well.

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 15:51 +0200, Anne van Kesteren wrote:
> On Fri, 05 Aug 2011 14:50:35 +0200, Philippe Le Hegaret  wrote:
> > What does it mean for the work of the HTML Working Group?
> 
> It means we are consistent with their work:
> 
>http://www.w3.org/TR/2011/WD-html5-diff-20110525/#references

I don't see that in any of the HTML last call documents,  like
   http://www.w3.org/TR/2dcontext/#references
or 

So, I would say that the HTML5 diff is also inconsistent,

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:
> On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:
> > Several documents in the WebApps Working Group are linking to HTML, more
> > specifically to the WHATWG HTML specification. An example of those is
> > Progress Events. This is done for no reason than political as far as I
> > can tell. This undermines and is disrespectful the work of the HTML
> > Working Group. Unless the WebApps comes up with a set of good reasons of
> > why this is done and convince the HTML Working Group, those references
> > must be changed in order to publish the documents properly and respect
> > the work of the HTML Working Group,
> 
> Philippe,
> 
> Re the specific case of the Progress Events spec - when it was last 
> published it included non-normative references to both version of HTML:
> 
>http://www.w3.org/TR/progress-events/#references
> 
> May we do that again? (I interpret that to mean the W3C has a fixed 
> version of HTML and the WHATWG has a tip-of-the-tree version of HTML and 
> as such, I don't think it  'disses the HTMLWG nor the W3C.)

Again, what are the reasons to link to the WHATWG HTML version? What
does it mean for the work of the HTML Working Group? There are features
in the WHATWG version that got rejected in the HTML Working Group. See

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?

This list keeps growing.

I don't think it's appropriate for one Working Group to ditch the work
of an other.

Philippe

Reference to the HTML specification

[Philippe Le Hegaret]

Several documents in the WebApps Working Group are linking to HTML, more
specifically to the WHATWG HTML specification. An example of those is
Progress Events. This is done for no reason than political as far as I
can tell. This undermines and is disrespectful the work of the HTML
Working Group. Unless the WebApps comes up with a set of good reasons of
why this is done and convince the HTML Working Group, those references
must be changed in order to publish the documents properly and respect
the work of the HTML Working Group,

Regards,

Philippe

Call for Prior Art Related to US Patent 7,743,336 and US Patent Application 20070101146

[Philippe Le Hegaret]

This is a public call for prior art. The W3C seeks information about
access control systems available before October 2005 and content
distribution systems before April 2006 that offer a viable solution that
may apply to the use of access requests policy in Widgets.

On 13 November 2009,  pursuant to its rights under W3C's Patent Policy,
Apple, Inc. disclosed US Published Patent Application No. 11/432,295 and
US Published Patent Application 11/409,276 and claimed that it applies
to the Web Application WG's Widget Access Request Policy specification.
Apple excluded all claims from the W3C Royalty-Free License commitment
of the W3C Patent Policy given by Participants of the Web Applications
Working Group.

In accordance with the exception procedures of the Patent Policy, W3C
launched a Patent Advisory Group (PAG) to determine possible solutions.
The PAG has advised W3C to issue this call for prior art. 

People who wish to provide feedback should refer to the call for prior
art for more information:
  http://www.w3.org/2010/12/cfpa

Please, don't hesitate to forward this message to other public fora,

Regards,

Philippe

Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior

[Philippe Le Hegaret]

On Thu, 2011-06-16 at 11:59 -0700, James Robinson wrote:
> That text requires the storage mutex, which has not and will not be
> implemented by any vendors, let alone 2 interoperable implementations,
> so it seems rather doomed.

Where does it do that? My only intent was to fix 12111 and nothing
else...

Philippe

Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior

[Philippe Le Hegaret]

Art wrote:
> All - given that addressing 12111 is a low priority for Ian, one way
> forward is for someone else to create a concrete proposal.

Here is a concrete proposal:
 http://www.w3.org/2011/06/Web%20Storage.html

Philippe

Re: Testing Requirements

[Philippe Le Hegaret]

On Thu, 2011-06-02 at 20:15 +0200, Marcos Caceres wrote:
> On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret  wrote:
> > On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote:
> >> Hi Philippe,
> >> Just wondering if we have different port support yet on test-w3c.org?
> >> Would be nice to at least have 81, 82 or something (any none-standard
> >> ports would be fine for me). I need ports to finish off the Widget
> >> Access Request Test Suite.
> >
> > Nope, I don't believe we have that but that should relatively easy to
> > add. How many extra do you need?
> 
> Just a few (2 or 3). I think Anne will also appreciate this for the
> XHR test suite.

You now have:
 http://www.w3c-test.org:81/
 http://www.w3c-test.org:82/
 http://www.w3c-test.org:83/

Philippe

Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior

[Philippe Le Hegaret]

On Thu, 2011-06-02 at 19:00 +, Ian Hickson wrote:
> On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
> > On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote:
> > > > I don't believe that this new feature will get implemented. It's going 
> > > > to break too many pages on the Web,
> > > 
> > > That's the kind of thing implementation feedback will determine.
> > 
> > You've got that feedback already. See
> >  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c3
> 
> That isn't implementor feedback, and it says nothing about the volume of 
> breakage. If Aryeh is the only person affected, then I'm sure he'd agree 
> with me that that means we can change this without worry.

For what I'm concerned, I'm more interested in a spec this year that
describe what has been working for the past 2 years than a spec that
describe what might work in 2 years from now. I wonder if it's possible
to work on such spec within the group, I'm willing to help.

Philippe

Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior

[Philippe Le Hegaret]

On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote:
> > I don't believe that this new feature will get implemented. It's going 
> > to break too many pages on the Web,
> 
> That's the kind of thing implementation feedback will determine.

You've got that feedback already. See
 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c3

Philippe

Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior

[Philippe Le Hegaret]

On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
> On Thu, 2 Jun 2011, Arthur Barstow wrote:
> >
> > Hixie, All - PLH proposed a fix for this bug in comment #5 (use 
> > DOMString instead of any in {get,set}Item).
> > 
> > AFAIU, PLH's proposal matches what has been widely implemented. As such, 
> > it seems like the spec should be updated accordingly.
> 
> This isn't a bug, it's a new feature that just hasn't been implemented 
> yet.

I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,

Philippe

Re: Testing Requirements

[Philippe Le Hegaret]

On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote:
> Hi Philippe,
> Just wondering if we have different port support yet on test-w3c.org?
> Would be nice to at least have 81, 82 or something (any none-standard
> ports would be fine for me). I need ports to finish off the Widget
> Access Request Test Suite.

Nope, I don't believe we have that but that should relatively easy to
add. How many extra do you need?

Philippe

Re: Testing Requirements

[Philippe Le Hegaret]

Doh! I didn't see the message from Mike before answering this one. So,
whatever the message from Mike is good. Apologizes for the extra noise.

Philippe

On Fri, 2011-02-18 at 15:32 -0500, Philippe Le Hegaret wrote:
> On Thu, 2011-02-17 at 11:04 +0100, James Graham wrote:
> > On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote:
> > 
> > > (I see that Art documented most of this in
> > > http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought
> > > this ought to be confirmed on the list)
> > 
> > Is there some way to make put this documentation in some common location 
> > rather than having essentially the same facts documented once for HTML, 
> > once for WebApps, etc.?
> 
> You can use the general wiki for that. I suggest:
>  http://www.w3.org/wiki/Testing/Requirements 
> 
> It's accessible to anyone who has a W3C account.
> 
> Btw, Mike reminded recently that we also have a general list for
> discussion on the testing infrastructure requirements:
>  http://lists.w3.org/Archives/Public/public-test-infra/
> 
> Philippe
> 
> 
> 
> 
> 
> 

Re: Testing Requirements

[Philippe Le Hegaret]

On Thu, 2011-02-17 at 11:04 +0100, James Graham wrote:
> On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote:
> 
> > (I see that Art documented most of this in
> > http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought
> > this ought to be confirmed on the list)
> 
> Is there some way to make put this documentation in some common location 
> rather than having essentially the same facts documented once for HTML, 
> once for WebApps, etc.?

You can use the general wiki for that. I suggest:
 http://www.w3.org/wiki/Testing/Requirements 

It's accessible to anyone who has a W3C account.

Btw, Mike reminded recently that we also have a general list for
discussion on the testing infrastructure requirements:
 http://lists.w3.org/Archives/Public/public-test-infra/

Philippe

Re: Testing Requirements

[Philippe Le Hegaret]

On Tue, 2011-02-15 at 13:19 +0100, Marcos Caceres wrote:
> Hi Dom, or W3C Staff,
> 
> Can we please get a full rundown of the systems available on test
> server. Can we also have all the details about getting access to the
> server, etc.

Here is a description of what we now have:

For the testing server w3c-test.org:
- available at http://www.w3c-test.org/, http://www1.w3c-test.org/,
http://www2.w3c-test.org/, and https://www.w3c-test.org/. Each address
runs on the same underlying copy. test.w3.org will become a redirect to
w3c-test.org soon.
- can run PHP scripts. If you need an script language support, you can
always ask but I don't think we'll make it a priority.
 Note that the replication of php scripts isn't automatic but goes
through a short internal review process. Several individuals within the
staff can do the approval, including Dominique and myself.
- cannot be directly accessed to. Files are pulled from the mercurial
repositories (dvcs.w3.org).

Besides the redirect, I' m not aware of any pending improvement requests
for w3c-test.org.

For the mercurial server dvcs.w3.org:
- Available at https://dvcs.w3.org/hg/
- To create a new repository, see
 http://lists.w3.org/Archives/Member/w3c-tools/2010AprJun/0011.html
- To access the repository, see the same message above.
- Indicate that the content of the repository needs to be replicated to
w3c-test.org in your request message.

We're missing two features on dvcs:
- prevent duplicated heads
- proper identity attribution
I don't have an ETA on those at the moment.


For large media files, like videos, I recommend using media.w3.org. I
did set up a few video files as examples at
 http://media.w3.org/2011/01/video/
 http://media.w3.org/2011/01/audio/
 http://media.w3.org/2010/05/video/
 http://media.w3.org/2010/05/video/
 http://media.w3.org/2010/05/sound/
 http://media.w3.org/2010/05/bunny/
 http://media.w3.org/2010/05/sintel/

Not all of them are available in multiple formats. Help is always
welcome for the conversion.

Philippe

An HTML5 logo

[Philippe Le Hegaret]

Dear Web Application Working Group,

Today W3C introduced an HTML5 logo for public consideration: 
http://www.w3.org/News/2011#entry-8992

The W3C Communications Team is excited about the HTML5 logo, developed
with community support, and hopes it will help you promote your work.
The logo is intended to be a general purpose visual identity for HTML5
and other web application technologies. It doesn't imply conformance;
just "this is about open web application technologies."

This is not yet the official W3C Communications Team logo for HTML5. We
look forward to broad community adoption in order to make it so.

For more information about the logo, see the logo home page [1] and faq
[2].

Thank you,

Philippe Le Hégaret, Interaction Domain Lead

[1] http://www.w3.org/html/logo/
[2] http://www.w3.org/html/logo/faq

Last Call for Navigation Timing API

[Philippe Le Hegaret]

This is a Last Call transition announcement for Navigation Timing:
   http://www.w3.org/TR/2011/WD-navigation-timing-20110111/

Please send comments to public-web-p...@w3.org with [NavigationTiming]
at the start of the subject line by 8 February 2011.

Note: Feedback would be especially appreciated regarding the use of
window.performance attribute and the potential to conflict with existing
Web pages. See also the thread at [1].

We would especially appreciate feedback from the Web Application Working
Group, due to the use of WebIDL in the document.

Thank you,

Philippe
[1] http://lists.w3.org/Archives/Public/public-web-perf/2010Dec/0027.html

Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4

[Philippe Le Hegaret]

On Fri, 2009-08-28 at 17:46 +0200, Robin Berjon wrote:
>  the editors' list reads like a war monument...

Actually, names have been added between the December 2007 and this
version and I don't know why (more people to blame? :). Arnaud and Bob
didn't edit the events specification [1] in the past.

Philippe

[1] http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/

Re: Copyright license for ElementTraversal Java interface

[Philippe Le Hegaret]

I was asked to help understanding what the DOM Working Group did on the
topic of bindings license.

The DOM Working Group made a decision to have the bindings for
ECMAScript, Java, and IDL normative. Thus, we included those in the DOM
specifications itself, as appendices. This was what happened for DOM
Level 1. However, in doing so, this effectively added the bindings under
the W3C Document License, which prevents you to make any kind of changes
at all. This issue was raised by the Debian community at that time,
prior to the publication of DOM Level 2 [1, 2]. The DOM Working Group
discussed it and reemphasized that fact that one cannot make changes in
the interfaces created by the WG, this would go against
interoperability. Even changing the order of arguments in functions
would harm interop in fact. In order to find a compromised solution, we
gave the ability to folks to change the bindings but, for the bindings
who supports package names, they have to be moved out of the "org.w3c"
package. In other words, it's fine to make changes to the bindings but
you need to:
1- document your changes
2- and don't claim your interfaces were done by W3C.

This resolved the issue for the debian community at that time and the
DOM Java interfaces have been distributed by Debian since then. This is
why the DOM Level 2 and 3 specifications have included the software
licenses with a modified statement ever since.

Regards,

Philippe

[1] http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0147.html
[2] http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0153.html