date:20130415

Thanks for the extra long explanation. That was a good confirmation of
what I thought the issues were.

On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote:
 Since Futures normally call their callbacks asynchronously, we can't
 set the open-flag to true right before the call, and set it back right
 after the call. This means that we have a harder time to solve problem
 3 described above.

Okay I see. The waiting for the lock is special. It seems though with
a special subclass of futures you could have the resolving of the
future and notifying be separate, but since everything is guaranteed
asynchronous already you might as well use the synchronous flag I
suppose. (Is there a name for that which does not imply badness?)


 So I guess the current solution is fine as longs as either
 * No JS libraries will want to implement APIs that uses locks, or
 * Such libraries are ok with not using the built-in Future API and
 instead re-implementing the Future API themselves.

The problem with exposing this directly is that you can also do bad stuff.


 I wouldn't be surprised if we'll run into similar situations in the
 future. I.e. other situations where we can't simply pass more context
 through the Future result and instead have to rely on surrounding
 world state. But I'm fine with crossing that bridge once we get there,
 if we get there. And we always have the escape hatch of letting pages
 implement the Future API themselves.

Cool.


--
http://annevankesteren.nl/

Re: [webcomponents]: Of weird script elements and Benadryl


On 4/14/13 1:49 PM, Scott Miles wrote:

Erik Arvidsson came up with a strategy for overcoming this in Blink, but
to my recollection Boris Zbarsky said this was a non-starter in Gecko.


Just to be clear, the proposal there was to take an already existing 
function object and call some UA-provided method that under the hood 
changes its [[Construct]] internal symbol.


Which is a non-starter for us in the short term simply because Gecko 
currently has no concept of different [[Construct]] for different 
_function_ objects (as opposed to other objects).


-Boris

Re: [webcomponents]: Of weird script elements and Benadryl


On 4/14/13 3:07 PM, Allen Wirfs-Brock wrote:

 2, 3, 4

I believe have been suggested in one form or another, but as I
mentioned, were determined to be non-starters for Gecko. I don't think
we've heard anything from IE team.


Well #4 has been accepted for ES6 by all TC39 participants including
Mozilla and Microsoft and is going to happen.  The basic scheme was
actually suggested a member of the SpiderMonkey team so I'm sure we'll
get it worked out for Gecko.


Note that in #4 we know statically, when we're creating the object for 
the constructor, that it's going to need to create special objects, so 
we can go ahead and create something that has the right [[Construct]] to 
start with.


And again note that this is all a question of timeframes.  I doubt ES6 
class support in SpiderMonkey will happen in the next several months, 
which was the timeframe people were talking about for web components.


-Boris

Re: [webcomponents]: Of weird script elements and Benadryl


On 4/14/13 5:35 PM, Rick Waldron wrote:

I have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable.


I'd like to understand what's meant here.  I have a good understanding 
of how these constructors work in Gecko+SpiderMonkey, but I'm not sure 
what the lacking bit is, other than the fact that they have to create JS 
objects that have special state associated with them, so can't work with 
an object created by the [[Construct]] of a typical function.


Is that what you're referring to, or something else?

-Boris

Re: [webcomponents]: Of weird script elements and Benadryl

On Mon, Apr 15, 2013 at 1:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 4/14/13 4:57 PM, Rick Waldron wrote:
 Of course, but we'd also eat scraps from the trash if that was the only
 edible food left on earth. document.createElement() is and has always
 been the wrong way—the numbers shown in those graphs are grossly
 skewed by a complete lack of any real alternative.

 Amen.  I strongly support making all *Element constructors actually work.
 The hard part is dealing with the cases when lots of elements share the same
 interface...

I think we should go for one interface per element here. abstract
classes not being constructable seems fine. Node/CharacterData are
similar to that. This would mean HTMLH1Element, ..., of which
compatibility impact has not been measured.

The other problem we need to solve is that document.createElement(x)
currently gives different results from new x's interface. E.g. new
Audio() sets an attribute, document.createElement(audio) does not. I
think we should settle for document.createElement(audio) also
creating an attribute here.

And the last problem (I think) is determining the document object. I
think we should follow http://dom.spec.whatwg.org/#dom-document new
Document() and friends for that.


--
http://annevankesteren.nl/

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Rick Waldron

On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good understanding of
 how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
 the lacking bit is, other than the fact that they have to create JS objects
 that have special state associated with them, so can't work with an object
 created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


Sorry, I should've been more specific. What I meant was that:

new HTMLButtonElement();

Doesn't construct an HTMLButtonElement, it throws with an illegal
constructor in Chrome and HTMLButtonElement is not a constructor in
Firefox (I'm sure this is the same across other browsers)

Which of course means that this is not possible even today:

function Smile() {
  HTMLButtonElement.call(this);
  this.textContent = :);
}

Smile.prototype = Object.create(HTMLButtonElement.prototype);


Since this doesn't work, the prototype method named readyCallback was
invented as a bolt-on stand-in for the actual [[Construct]]

Hopefully that clarifies?

Rick


PS. A bit of trivial... A long time ago some users requested that
jQuery facilitate a custom constructor; to make this work, John put the
actual constructor code in a prototype method called init and set that
method's prototype to jQuery's own prototype. The thing called
readyCallback is similar. For those that are interested, I created a gist
with a minimal illustration here: https://gist.github.com/rwldrn/5388544







 -Boris

RE: MathML and Clipboard API and events

2013-04-15 Thread Paul Topping

Hi Halvord,

Yes, your rewording sounds like a good direction to me. I still worry that 
placing plain text on the clipboard along with MathML will result in a lot of 
apps failing to paste the MathML but doing so would probably be considered a 
bug in such an app.

Thanks for filing the bugs. I suspect that the MathML community would be eager 
to help define what needs to get stripped out of MathML to maintain security. 
However, speaking for myself, I do not know what kinds of things are considered 
dangerous. For example, MathML has markup that lets a math expression act as a 
hyperlink. Do we need to strip that out completely or is that dependent on the 
url? If there are guidelines on what is considered dangerous, then we could 
figure out exactly which MathML constructs need to be pruned. Or is there some 
other procedure for getting this done?

Paul

 -Original Message-
 From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
 Sent: Monday, April 15, 2013 1:50 AM
 To: public-webapps@w3.org; Paul Topping
 Subject: Re: MathML and Clipboard API and events
 
 Hi Paul, thanks for your comments.
 
  Mathematical information
 
  This section says MathML often needs to be transformed to be
  copied as plain text, for example to make sure to the power of
  is shown with the caret ^ sign in a formula plain-text input.
  Such a transformation should not be part of a normal copy operation
  since that would transfer MathML. My concern is that readers get the
  idea that x 2 should always or often be transformed to x^2.
 
 
 What about saying something like
 
 
 Some applications may want to place plain text alternatives along with
 MathML formulas on he clipboard, for example to make sure .. ?
 
 
   10.  Mandatory data types
 
  I am surprised not to see a MathML type in this list
 
 
 Well, since you mention it.. I've filed a bug (
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to
 your question. If you have comments or information please add (either by
 replying here or in the bug). Would be great if you could help me understand
 whether allowing an application to write MathML to the clipboard could
 expose an app to attacks if the MathML markup is pasted without further
 processing - see also
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700
 
 
 --
 Hallvord R. M. Steen
 Core tester, Opera Software

Re: [webcomponents]: Of weird script elements and Benadryl


On 4/15/13 10:45 AM, Rick Waldron wrote:

Sorry, I should've been more specific. What I meant was that:

new HTMLButtonElement();

Doesn't construct an HTMLButtonElement, it throws with an illegal
constructor in Chrome and HTMLButtonElement is not a constructor in
Firefox (I'm sure this is the same across other browsers)


Oh, I see.  That's not anything inherent, for what it's worth; making 
this particular case work would be 10 lines of code.  Less on a 
per-element basis if we want to do this for most elements.



function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
}

Smile.prototype = Object.create(HTMLButtonElement.prototype);


Ah, so... This would not work even if new HTMLButtonElement worked, 
right?  In particular, if HTMLButtonElement were actually something that 
could construct things in Gecko, it would still ignore its argument when 
called and always creates a new object.  You can see the behavior with 
something like XMLHttpRequest if you want.



Hopefully that clarifies?


Somewhat.  Trying to understand what things we really need to support 
here and in what ways, long-term...


-Boris

Re: [webcomponents]: Of weird script elements and Benadryl

Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.

This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

Scott


On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good understanding of
 how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
 the lacking bit is, other than the fact that they have to create JS objects
 that have special state associated with them, so can't work with an object
 created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)

 Which of course means that this is not possible even today:

 function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
 }

 Smile.prototype = Object.create(HTMLButtonElement.prototype);


 Since this doesn't work, the prototype method named readyCallback was
 invented as a bolt-on stand-in for the actual [[Construct]]

 Hopefully that clarifies?

 Rick


 PS. A bit of trivial... A long time ago some users requested that
 jQuery facilitate a custom constructor; to make this work, John put the
 actual constructor code in a prototype method called init and set that
 method's prototype to jQuery's own prototype. The thing called
 readyCallback is similar. For those that are interested, I created a gist
 with a minimal illustration here: https://gist.github.com/rwldrn/5388544







 -Boris

Re: [webcomponents]: Of weird script elements and Benadryl

Why do the constructors of component instances run during component loading?

Why not use standard events rather than callbacks?

Thanks,
jjb
On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

 Again, 'readyCallback' exists because it's a Bad Idea to run user code
 during parsing (tree construction). Ready-time is not the same as
 construct-time.

 This is the Pinocchio problem:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

 Scott


 On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good understanding
 of how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
 the lacking bit is, other than the fact that they have to create JS objects
 that have special state associated with them, so can't work with an object
 created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)

 Which of course means that this is not possible even today:

 function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
 }

 Smile.prototype = Object.create(HTMLButtonElement.prototype);


 Since this doesn't work, the prototype method named readyCallback was
 invented as a bolt-on stand-in for the actual [[Construct]]

 Hopefully that clarifies?

 Rick


 PS. A bit of trivial... A long time ago some users requested that
 jQuery facilitate a custom constructor; to make this work, John put the
 actual constructor code in a prototype method called init and set that
 method's prototype to jQuery's own prototype. The thing called
 readyCallback is similar. For those that are interested, I created a gist
 with a minimal illustration here: https://gist.github.com/rwldrn/5388544







 -Boris

Re: [webcomponents]: Of weird script elements and Benadryl

 Why do the constructors of component instances run during component
loading?

I'm not sure what you are referring to. What does 'component loading' mean?

 Why not use standard events rather than callbacks?

This was discussed quite a bit, here is my off-the-cuff response. I may
have to do archaeology to get a better one.

Custom elements can inherit from custom elements. The callbacks are
convenient because (1) there is no question of 'who registers a listener'
(2) I can simply call my 'super' callback (or not) to get inherited
behavior.

IIRC, it is also advantageous for performance and for having control over
the timing these calls.

Scott


On Mon, Apr 15, 2013 at 9:37 AM, John J Barton
johnjbar...@johnjbarton.comwrote:

 Why do the constructors of component instances run during component
 loading?

 Why not use standard events rather than callbacks?

 Thanks,
 jjb
 On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

 Again, 'readyCallback' exists because it's a Bad Idea to run user code
 during parsing (tree construction). Ready-time is not the same as
 construct-time.

 This is the Pinocchio problem:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

 Scott


 On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good understanding
 of how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
 the lacking bit is, other than the fact that they have to create JS objects
 that have special state associated with them, so can't work with an object
 created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)

 Which of course means that this is not possible even today:

 function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
 }

 Smile.prototype = Object.create(HTMLButtonElement.prototype);


 Since this doesn't work, the prototype method named readyCallback was
 invented as a bolt-on stand-in for the actual [[Construct]]

 Hopefully that clarifies?

 Rick


 PS. A bit of trivial... A long time ago some users requested that
 jQuery facilitate a custom constructor; to make this work, John put the
 actual constructor code in a prototype method called init and set that
 method's prototype to jQuery's own prototype. The thing called
 readyCallback is similar. For those that are interested, I created a gist
 with a minimal illustration here: https://gist.github.com/rwldrn/5388544







 -Boris

Re: [webcomponents]: Of weird script elements and Benadryl

 The callbacks are convenient because (1) there is no question of 'who
registers a listener' (2) I can simply call my 'super' callback (or not) to
get inherited behavior.

One minute later, these seem like bad reasons. I shouldn't have shot from
the hip, let me do some research.


On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:

  Why do the constructors of component instances run during component
 loading?

 I'm not sure what you are referring to. What does 'component loading' mean?

  Why not use standard events rather than callbacks?

 This was discussed quite a bit, here is my off-the-cuff response. I may
 have to do archaeology to get a better one.

 Custom elements can inherit from custom elements. The callbacks are
 convenient because (1) there is no question of 'who registers a listener'
 (2) I can simply call my 'super' callback (or not) to get inherited
 behavior.

 IIRC, it is also advantageous for performance and for having control over
 the timing these calls.

 Scott


 On Mon, Apr 15, 2013 at 9:37 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 Why do the constructors of component instances run during component
 loading?

 Why not use standard events rather than callbacks?

 Thanks,
 jjb
 On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

 Again, 'readyCallback' exists because it's a Bad Idea to run user code
 during parsing (tree construction). Ready-time is not the same as
 construct-time.

 This is the Pinocchio problem:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

 Scott


 On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.eduwrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good understanding
 of how these constructors work in Gecko+SpiderMonkey, but I'm not sure 
 what
 the lacking bit is, other than the fact that they have to create JS 
 objects
 that have special state associated with them, so can't work with an object
 created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)

 Which of course means that this is not possible even today:

 function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
 }

 Smile.prototype = Object.create(HTMLButtonElement.prototype);


 Since this doesn't work, the prototype method named readyCallback was
 invented as a bolt-on stand-in for the actual [[Construct]]

 Hopefully that clarifies?

 Rick


 PS. A bit of trivial... A long time ago some users requested that
 jQuery facilitate a custom constructor; to make this work, John put the
 actual constructor code in a prototype method called init and set that
 method's prototype to jQuery's own prototype. The thing called
 readyCallback is similar. For those that are interested, I created a gist
 with a minimal illustration here:
 https://gist.github.com/rwldrn/5388544







 -Boris

Re: [webcomponents]: Of weird script elements and Benadryl

Sorry for the extra posts. I promise to slow down.

 Why not use standard events rather than callbacks?

I believe a better answer is that it was decided these callbacks had to
work synchronously relative to imperative construction.

So, I can do

  var xfoo = document.createElement('x-foo');
  xfoo.doImportantThing();


On Mon, Apr 15, 2013 at 9:46 AM, Scott Miles sjmi...@google.com wrote:

  The callbacks are convenient because (1) there is no question of 'who
 registers a listener' (2) I can simply call my 'super' callback (or not) to
 get inherited behavior.

 One minute later, these seem like bad reasons. I shouldn't have shot from
 the hip, let me do some research.


 On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:

  Why do the constructors of component instances run during component
 loading?

 I'm not sure what you are referring to. What does 'component loading'
 mean?

  Why not use standard events rather than callbacks?

 This was discussed quite a bit, here is my off-the-cuff response. I may
 have to do archaeology to get a better one.

 Custom elements can inherit from custom elements. The callbacks are
 convenient because (1) there is no question of 'who registers a listener'
 (2) I can simply call my 'super' callback (or not) to get inherited
 behavior.

 IIRC, it is also advantageous for performance and for having control over
 the timing these calls.

 Scott


 On Mon, Apr 15, 2013 at 9:37 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 Why do the constructors of component instances run during component
 loading?

 Why not use standard events rather than callbacks?

 Thanks,
 jjb
 On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

 Again, 'readyCallback' exists because it's a Bad Idea to run user code
 during parsing (tree construction). Ready-time is not the same as
 construct-time.

 This is the Pinocchio problem:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

 Scott


 On Mon, Apr 15, 2013 at 7:45 AM, Rick Waldron 
 waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.eduwrote:

 On 4/14/13 5:35 PM, Rick Waldron wrote:

 I have a better understanding of problem caused by these generated
 HTML*Element constructors: they aren't constructable.


 I'd like to understand what's meant here.  I have a good
 understanding of how these constructors work in Gecko+SpiderMonkey, but 
 I'm
 not sure what the lacking bit is, other than the fact that they have to
 create JS objects that have special state associated with them, so can't
 work with an object created by the [[Construct]] of a typical function.

 Is that what you're referring to, or something else?


 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)

 Which of course means that this is not possible even today:

 function Smile() {
   HTMLButtonElement.call(this);
   this.textContent = :);
 }

 Smile.prototype = Object.create(HTMLButtonElement.prototype);


 Since this doesn't work, the prototype method named readyCallback
 was invented as a bolt-on stand-in for the actual [[Construct]]

 Hopefully that clarifies?

 Rick


 PS. A bit of trivial... A long time ago some users requested that
 jQuery facilitate a custom constructor; to make this work, John put the
 actual constructor code in a prototype method called init and set that
 method's prototype to jQuery's own prototype. The thing called
 readyCallback is similar. For those that are interested, I created a 
 gist
 with a minimal illustration here:
 https://gist.github.com/rwldrn/5388544







 -Boris

Re: [webcomponents]: Of weird script elements and Benadryl

On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:

  Why do the constructors of component instances run during component
 loading?

 I'm not sure what you are referring to. What does 'component loading' mean?

  Why not use standard events rather than callbacks?


 I'll some of the doc you link below and re-ask.

 On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

 Again, 'readyCallback' exists because it's a Bad Idea to run user code
 during parsing (tree construction). Ready-time is not the same as
 construct-time.

 This is the Pinocchio problem:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html


---

Here's why:

i) when we load component document, it blocks scripts just like a
stylesheet 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts)

ii) this is okay, since our constructors are generated (no user code)
and most of the tree could be constructed while the component is
loaded.

iii) However, if we make constructors run at the time of tree
construction, the tree construction gets blocked much sooner, which
effectively makes component loading synchronous. Which is bad.



Why do the constructors of component *instances* which don't need to
run until instances are created, need to block the load of component
documents?

Seems to me that you could dictate that script in components load
async WRT components but block instance construction.

jjb

Re: [webcomponents]: Of weird script elements and Benadryl

Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.

The main document can have a bunch of markup for custom elements. If the
user has made element definitions a-priori to parsing that markup
(including inside link rel='import'), he expects those nodes to be 'born'
correctly.

Sidebar: running user's instance code while the parser is constructing the
tree is Bad(tm) so we already have deferred init code until immediately
after the parsing step. This is why I keep saying 'ready-time' is different
from 'construct-time'.

Today, I don't see how we can construct a custom element with the right
prototype at parse-time without blocking on imported scripts (which is
another side-effect of using script execution for defining prototype, btw.)

If we don't block, the parser has to construct some kind of place holder
for each custom instance, and then we upgrade them in a second pass.

On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.comwrote:

On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:

Why do the constructors of component instances run during component
loading?

I'm not sure what you are referring to. What does 'component loading'
mean?

Why not use standard events rather than callbacks?

I'll some of the doc you link below and re-ask.

On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.

This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

---

Here's why:

i) when we load component document, it blocks scripts just like a
stylesheet
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts)

ii) this is okay, since our constructors are generated (no user code)
and most of the tree could be constructed while the component is
loaded.

iii) However, if we make constructors run at the time of tree
construction, the tree construction gets blocked much sooner, which
effectively makes component loading synchronous. Which is bad.

Why do the constructors of component *instances* which don't need to run
until instances are created, need to block the load of component documents?

Seems to me that you could dictate that script in components load async WRT
components but block instance construction.

jjb

Re: [webcomponents]: Of weird script elements and Benadryl

On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.com wrote:

Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.

Yes we sure hope so!

Sure.

? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?

You must block creating instances of components until component documents
are parsed and initialized. Because of limitations in HTML DOM
construction, you may have to block HTML parsing until instances of
components are created. Thus I imagine that creating instances may block
HTML parsing until component documents are parsed and initialized or the
HTML parsing must have two passes as your Pinocchio link outlines.

But my original question concerns blocking component documents on their own
script tag compilation. Maybe I misunderstood.

jjb

On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.com wrote:

On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:

Why do the constructors of component instances run during component
loading?

I'm not sure what you are referring to. What does 'component loading'
mean?

Why not use standard events rather than callbacks?

I'll some of the doc you link below and re-ask.

On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.

This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

---

Here's why:

i) when we load component document, it blocks scripts just like a
stylesheet
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts)

ii) this is okay, since our constructors are generated (no user code)
and most of the tree could be constructed while the component is
loaded.

iii) However, if we make constructors run at the time of tree
construction, the tree construction gets blocked much sooner, which
effectively makes component loading synchronous. Which is bad.

Why do the constructors of component *instances* which don't need to run
until instances are created, need to block the load of component documents?

Seems to me that you could dictate that script in components load async
WRT components but block instance construction.

jjb

Re: Futures and transactions

2013-04-15 Thread Jonas Sicking

On Mon, Apr 15, 2013 at 12:50 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote:
 So I guess the current solution is fine as longs as either
 * No JS libraries will want to implement APIs that uses locks, or
 * Such libraries are ok with not using the built-in Future API and
 instead re-implementing the Future API themselves.

 The problem with exposing this directly is that you can also do bad stuff.

Nothing worst than you could do by implementing the Future API in JS yourself.

As far as I can tell the only problem is that by exposing sync
resolving, pages can do it more easily and so might be more tempted to
do it.

/ Jonas

[Bug 21649] Duplicate requirement

2013-04-15 Thread bugzilla

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

Joshua Bell jsb...@chromium.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jsb...@chromium.org
 Resolution|--- |FIXED

--- Comment #1 from Joshua Bell jsb...@chromium.org ---
Fixed in https://dvcs.w3.org/hg/IndexedDB/rev/5b0ddb9a258b

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

Re: [webcomponents]: Of weird script elements and Benadryl

On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.com wrote:

Thank you for your patience. :)

ditto.

? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?

My 'x-foo' has an 'init' method that I wrote that has to execute before
the instance is fully 'constructed'. Parser encounters an x-foo/x-foo
and constructs it. My understanding is that calling 'init' from the parser
at that point is a non-starter.

I think the Pinocchio link makes the case that you have only three choices:
1) call 'init' when component instance tag is encountered, blocking
parsing,
2) call 'init' later, causing reflows and losing the value of not
blocking parsing,
3) don't allow 'init' at all, limiting components.

So non-starter is just a vote against one of three Bad choices as far as
I can tell. In other words, these are all non-starters ;-).

But my original question concerns blocking component documents on their
own script tag compilation. Maybe I misunderstood.

I don't think imports (nee component documents) have any different
semantics from the main document in this regard. The import document may
have an x-foo instance in it's markup, and element tags or link
rel=import just like the main document.

Indeed, however the relative order of the component's script tag processing
and the component's tag element is all I was talking about.

On Mon, Apr 15, 2013 at 11:23 AM, John J Barton
johnjbar...@johnjbarton.com wrote:

On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.com wrote:

Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.

Yes we sure hope so!

Sure.

Sidebar: running user's instance code while the parser is constructing
the tree is Bad(tm) so we already have deferred init code until immediately
after the parsing step. This is why I keep saying 'ready-time' is different
from 'construct-time'.

? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?

But my original question concerns blocking component documents on their
own script tag compilation. Maybe I misunderstood.

jjb

On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.com wrote:

On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.comwrote:

Why do the constructors of component instances run during component
loading?

I'm not sure what you are referring to. What does 'component loading'
mean?

Why not use standard events rather than callbacks?

I'll some of the doc you link below and re-ask.

On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

Again, 'readyCallback' exists because it's a Bad Idea to run user
code during parsing (tree construction). Ready-time is not the same as
construct-time.

This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

---

Here's why:

i) when we load component document, it blocks scripts just like a
stylesheet
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts)

ii) this is okay, since our constructors are generated (no user code)
and most of the tree could be constructed while the component is
loaded.

iii) However, if we make constructors run at the time of tree
construction, the tree construction gets blocked much sooner, which
effectively makes component loading synchronous. Which is bad.

Why do the constructors of component *instances* which don't need to run
until instances are created, need to block the load of component documents?

Seems to me that you could dictate that script in components load async
WRT components but block instance construction.

jjb

File API: auto-revoking blob URLs

So blob URLs are auto-revoked by default after the current script
stops running. However, every fetch operation in existence (apart from
synchronous XMLHttpRequest) does so asynchronous.

So

img.src = blobURL

might very well start fetching at the point blobURL is already cleaned up.

We need a different solution here. I'm not really sure what the
solution is, but autoRevoke as-is does not work.


--
http://annevankesteren.nl/

[admin] Editors and Test Facilitators: please update your PubStatus data before April 25

2013-04-15 Thread Arthur Barstow


Editors, Test Facilitators,

During next week's f2f meeting [Agenda], we will once again go through 
[PubStatus] (aka the group's `dashboard`) to verify the data and to help 
us all (not just WG members) understand the status, plans, issues, etc. 
regarding all of our Specs and Test Suites.


If you are an Editor or Test Facilitator - *especially* those that will 
not attend the meeting in person or via the phone bridge - please review 
all of your PubStatus data and update it accordingly or report updates 
and/or status here.


For specs, I think it is particularly useful for the Plans column to 
indicate the Editor's plan for the next publication, the type of 
publication (e.g. WD, LC, etc.) and any major issues that are blocking 
the spec's progress. (A few specs are coming up on one year since the 
FPWD was published so you can probably expect me or Chaals to be chasing 
after you ;-).)


For test suites, the percentage complete is important and the Plans 
column can be used to indicate any major blocking issues, CR interop 
status, etc.


-Thanks, ArtB

[Agenda] http://www.w3.org/wiki/Webapps/April2013Meeting
[PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Rick Waldron

On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/15/13 10:45 AM, Rick Waldron wrote:

 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)


 Oh, I see.  That's not anything inherent, for what it's worth; making this
 particular case work would be 10 lines of code.  Less on a per-element
 basis if we want to do this for most elements.


  function Smile() {
HTMLButtonElement.call(this);
this.textContent = :);
 }

 Smile.prototype = Object.create(**HTMLButtonElement.prototype);


 Ah, so... This would not work even if new HTMLButtonElement worked,
 right?


I guess I assumed this would work if new HTMLButtonElement() could
construct things


 In particular, if HTMLButtonElement were actually something that could
 construct things in Gecko, it would still ignore its argument when called
 and always creates a new object.  You can see the behavior with something
 like XMLHttpRequest if you want.


What I was expecting the above to produce is a constructor capable of
something like this:

  var smile = new Smile();
  smile.nodeType === 1;
  smile.outerHTML === button:)/button; // true
  // (and so forth)
  document.body.appendChild(smile);

results in something like this: http://gul.ly/de0


Rick




  Hopefully that clarifies?


 Somewhat.  Trying to understand what things we really need to support here
 and in what ways, long-term...

 -Boris

Re: File API: auto-revoking blob URLs

On Mon, Apr 15, 2013 at 8:04 PM, Anne van Kesteren ann...@annevk.nl wrote:
 What could maybe work is having all specifications invoke
 http://fetch.spec.whatwg.org/#concept-fetch synchronously which will
 then do the right thing for blob URLs (take a reference to the
 underlying object, etc). That seems like a better solution than
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 as having all
 APIs special case blob is just asking for trouble.

Never mind: http://krijnhoetmer.nl/irc-logs/whatwg/20130415#l-827

Back to no solution.


--
http://annevankesteren.nl/

Re: [webcomponents]: Of weird script elements and Benadryl

1) call 'init' when component instance tag is encountered, blocking
parsing,

Fwiw, it was said that calling user code from inside the Parser could
cause Armageddon, not just block the parser. I don't recall the details,
unfortunately.

On Mon, Apr 15, 2013 at 11:44 AM, John J Barton johnjbar...@johnjbarton.com
wrote:

On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.com wrote:

Thank you for your patience. :)

ditto.

? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?

I think the Pinocchio link makes the case that you have only three
choices:
1) call 'init' when component instance tag is encountered, blocking
parsing,
2) call 'init' later, causing reflows and losing the value of not
blocking parsing,
3) don't allow 'init' at all, limiting components.

So non-starter is just a vote against one of three Bad choices as far as
I can tell. In other words, these are all non-starters ;-).

But my original question concerns blocking component documents on their
own script tag compilation. Maybe I misunderstood.

Indeed, however the relative order of the component's script tag
processing and the component's tag element is all I was talking about.

On Mon, Apr 15, 2013 at 11:23 AM, John J Barton
johnjbar...@johnjbarton.com wrote:

On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.comwrote:

Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.

Yes we sure hope so!

The main document can have a bunch of markup for custom elements. If
the user has made element definitions a-priori to parsing that markup
(including inside link rel='import'), he expects those nodes to be 'born'
correctly.

Sure.

Sidebar: running user's instance code while the parser is constructing
the tree is Bad(tm) so we already have deferred init code until immediately
after the parsing step. This is why I keep saying 'ready-time' is different
from 'construct-time'.

? user's instance code? Do you mean: Running component instance
initialization during document construction is Bad?

You must block creating instances of components until component
documents are parsed and initialized. Because of limitations in HTML DOM
construction, you may have to block HTML parsing until instances of
components are created. Thus I imagine that creating instances may block
HTML parsing until component documents are parsed and initialized or the
HTML parsing must have two passes as your Pinocchio link outlines.

But my original question concerns blocking component documents on their
own script tag compilation. Maybe I misunderstood.

jjb

On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.com wrote:

On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.comwrote:

Why do the constructors of component instances run during
component loading?

I'm not sure what you are referring to. What does 'component loading'
mean?

Why not use standard events rather than callbacks?

I'll some of the doc you link below and re-ask.

On Apr 15, 2013 9:04 AM, Scott Miles sjmi...@google.com wrote:

Again, 'readyCallback' exists because it's a Bad Idea to run user
code during parsing (tree construction). Ready-time is not the same as
construct-time.

This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html

---

Here's why:

i) when we load component document, it blocks scripts just like a
stylesheet
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#a-style-sheet-that-is-blocking-scripts)

ii) this is okay, since our constructors are generated (no user code)
and most of the tree could be constructed while the component is
loaded.

iii) However, if we make constructors run at the time of tree
construction, the tree construction gets blocked much sooner, which
effectively makes component loading synchronous. Which is bad.

Why do the constructors of component *instances* which don't need to run
until instances are created, need to block the load of component
documents?

Seems to me that

[Bug 18551] [IndexedDB] Ambiguity about operations preceding a failed createIndex.

2013-04-15 Thread bugzilla

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

Joshua Bell jsb...@chromium.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Joshua Bell jsb...@chromium.org ---
I took as stab at this - as minimally as possible - in
https://dvcs.w3.org/hg/IndexedDB/rev/eeb7e443b582

I added an example to the createIndex case; a corresponding example for the
deleteIndex case seemed too contrived.

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

Re: File API: auto-revoking blob URLs

On Mon, Apr 15, 2013 at 7:49 PM, Anne van Kesteren ann...@annevk.nl wrote:
 So blob URLs are auto-revoked by default after the current script
 stops running. However, every fetch operation in existence (apart from
 synchronous XMLHttpRequest) does so asynchronous.

 So

 img.src = blobURL

 might very well start fetching at the point blobURL is already cleaned up.

 We need a different solution here. I'm not really sure what the
 solution is, but autoRevoke as-is does not work.

What could maybe work is having all specifications invoke
http://fetch.spec.whatwg.org/#concept-fetch synchronously which will
then do the right thing for blob URLs (take a reference to the
underlying object, etc). That seems like a better solution than
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 as having all
APIs special case blob is just asking for trouble.


--
http://annevankesteren.nl/

Re: [webcomponents]: Of weird script elements and Benadryl

*At least somebody explain why this is conceptually wrong.

*
Nothing is conceptually wrong with what you've stated Scott. I could live
with a prototype element that is scoped to the element as long as there
was some sort of 'registeredCallback' (as you previously alluded to many
posts back) that would be executed with access to the global scope just
once before the 'DOMElementsUpgraded' event fired. This preserves the
ability to setup, with minimal effort and hackery, delegate listeners and
other useful top-level scaffolding a component may require. Is this pretty
or optimal in terms of developer ergonomics? No - but it meet the
requirements.

For what it's worth: I talked to Brendan about this quandary and he favored
the creation of a special tag specifically for defining a component's
interface.


On Mon, Apr 15, 2013 at 12:46 PM, Rick Waldron waldron.r...@gmail.comwrote:




 On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 4/15/13 10:45 AM, Rick Waldron wrote:

 Sorry, I should've been more specific. What I meant was that:

 new HTMLButtonElement();

 Doesn't construct an HTMLButtonElement, it throws with an illegal
 constructor in Chrome and HTMLButtonElement is not a constructor in
 Firefox (I'm sure this is the same across other browsers)


 Oh, I see.  That's not anything inherent, for what it's worth; making
 this particular case work would be 10 lines of code.  Less on a
 per-element basis if we want to do this for most elements.


  function Smile() {
HTMLButtonElement.call(this);
this.textContent = :);
 }

 Smile.prototype = Object.create(**HTMLButtonElement.prototype);


 Ah, so... This would not work even if new HTMLButtonElement worked,
 right?


 I guess I assumed this would work if new HTMLButtonElement() could
 construct things


 In particular, if HTMLButtonElement were actually something that could
 construct things in Gecko, it would still ignore its argument when called
 and always creates a new object.  You can see the behavior with something
 like XMLHttpRequest if you want.


 What I was expecting the above to produce is a constructor capable of
 something like this:

   var smile = new Smile();
   smile.nodeType === 1;
   smile.outerHTML === button:)/button; // true
   // (and so forth)
   document.body.appendChild(smile);

 results in something like this: http://gul.ly/de0


 Rick




  Hopefully that clarifies?


 Somewhat.  Trying to understand what things we really need to support
 here and in what ways, long-term...

 -Boris

[Bug 20394] [IndexedDB] Spec should use WebIDL concepts such as sequenceT rather than Array

2013-04-15 Thread bugzilla

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

Joshua Bell jsb...@chromium.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Joshua Bell jsb...@chromium.org ---
(In reply to comment #5)
 What's left is a smattering of uses of codeArray/code throughout the
 spec far away from the method input definitions. Most of those are around
 keys (which should now be correct) but some are around key paths; those
 should more abstractly refer to a sequences, lists, or sets, not the input
 type.

(In reply to comment #6)
 There are still issues here for keyPath.  I filed bug 21555 on those.

Apart from the issues in 21555, I've updated the places that describe
array-type key paths to use sequenceDOMString consistently in
https://dvcs.w3.org/hg/IndexedDB/rev/5d92beba

The pedantic part of me would like to take this further and refer to them even
more abstractly as sequences of strings but this is probably sufficient.

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

Re: [webcomponents]: Of weird script elements and Benadryl

 What happens if the construction/initialization of the custom element
calls one of the element's member functions overridden by code in a
prototype?

IIRC it's not possible to override methods that will be called from inside
of builtins, so I don't believe this is an issue (unless we change the
playfield).

 How, as component author, do I ensure that my imperative set up code
runs and modifies my element DOM content before the user sees the
un-modified custom element declared in mark-up? (I'm cheating, since this
issue isn't specific to your prototype)

This is another can of worms. Right now we blanket solve this by waiting
for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
something) and handling this appropriately for our application.


On Mon, Apr 15, 2013 at 1:46 PM, John J Barton
johnjbar...@johnjbarton.comwrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code runs
 and modifies my element DOM content before the user sees the un-modified
 custom element declared in mark-up? (I'm cheating, since this issue isn't
 specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.com wrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can run
 init code directly after parsing, there are no 'this' issues or problems
 associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.com wrote:

   1) call 'init' when component instance tag is encountered, blocking
 parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered, blocking
 parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So non-starter is just a vote against one of three Bad choices as far
 as I can tell. In other words, these are all non-starters ;-).


  But my original question concerns blocking component documents on
 their own script tag compilation. Maybe I misunderstood.

 I don't think imports (nee component documents) have any different
 semantics from the main document in this regard. The import document may
 have an x-foo instance in it's markup, and element tags or link
 rel=import just like the main document.


 Indeed, however the relative order of the component's script tag
 processing and the component's tag element is all I was talking about.




 On Mon, Apr 15, 2013 at 11:23 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.comwrote:

 Dimitri is trying to avoid 'block[ing] instance construction'
 because instances can be in the main document markup.


 Yes we sure hope so!



 The main document can have a bunch of markup for custom elements. If
 the user has made element definitions a-priori to parsing that markup
 (including inside link rel='import'), he expects those nodes to be 
 'born'
 correctly.


 Sure.




 Sidebar: running user's instance code while the parser is
 constructing the tree is Bad(tm) so we already have deferred init code
 until immediately after the parsing step. This is why I keep saying
 'ready-time' is different from 'construct-time'.


 ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?



 Today, I don't see how we can construct a custom element with the
 right prototype at parse-time without blocking on imported scripts 
 (which
 is another side-effect of using script execution for defining prototype,
 btw.)


 You must block creating instances of components until component
 documents are parsed and initialized.  Because of limitations in HTML DOM
 construction, you may have to block HTML parsing

Re: [webcomponents]: Of weird script elements and Benadryl

*How, as component author, do I ensure that my imperative set up code runs
and modifies my element DOM content before the user sees the un-modified
custom element declared in mark-up? (I'm cheating, since this issue isn't
specific to your prototype) *

When you say ...runs before the user sees the unmodified..., what do you
mean? The 'readyCallback' is the *run-once-per-instance* imperative code
associated with a component, and would always run *after *something like
'registeredCallback*', *the *run-once-per-component* imperative
code...unless we are talking about different things? As far as what the
user visually sees, there is an understanding that a render my happen
wherein components are not yet inflated/upgraded - in this instance, the
developer should create some styles to account for the non-upgraded state.
This has been the thinking all along btw.


On Mon, Apr 15, 2013 at 1:46 PM, John J Barton
johnjbar...@johnjbarton.comwrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code runs
 and modifies my element DOM content before the user sees the un-modified
 custom element declared in mark-up? (I'm cheating, since this issue isn't
 specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.com wrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can run
 init code directly after parsing, there are no 'this' issues or problems
 associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.com wrote:

   1) call 'init' when component instance tag is encountered, blocking
 parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered, blocking
 parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So non-starter is just a vote against one of three Bad choices as far
 as I can tell. In other words, these are all non-starters ;-).


  But my original question concerns blocking component documents on
 their own script tag compilation. Maybe I misunderstood.

 I don't think imports (nee component documents) have any different
 semantics from the main document in this regard. The import document may
 have an x-foo instance in it's markup, and element tags or link
 rel=import just like the main document.


 Indeed, however the relative order of the component's script tag
 processing and the component's tag element is all I was talking about.




 On Mon, Apr 15, 2013 at 11:23 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.comwrote:

 Dimitri is trying to avoid 'block[ing] instance construction'
 because instances can be in the main document markup.


 Yes we sure hope so!



 The main document can have a bunch of markup for custom elements. If
 the user has made element definitions a-priori to parsing that markup
 (including inside link rel='import'), he expects those nodes to be 
 'born'
 correctly.


 Sure.




 Sidebar: running user's instance code while the parser is
 constructing the tree is Bad(tm) so we already have deferred init code
 until immediately after the parsing step. This is why I keep saying
 'ready-time' is different from 'construct-time'.


 ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?



 Today, I don't see how we can construct a custom element with the
 right prototype at parse-time without blocking on imported scripts 
 (which
 is another side-effect of using script execution for defining prototype,
 btw.)


 You must block creating instances of components until component
 documents are parsed and

Re: [webcomponents]: Of weird script elements and Benadryl


On 4/15/13 3:46 PM, Rick Waldron wrote:

What I was expecting the above to produce is a constructor capable of
something like this:

   var smile = new Smile();
   smile.nodeType === 1;


For that, you have to have a way for Smile to get the @@construct of 
HTMLButtonElement.  There's no way to do that with ES5.  :(


-Boris

Re: [webcomponents]: Of weird script elements and Benadryl

 So we can override some methods but not others, depending on the
implementation?

You can override methods that will be called from JS, but not from C++
(depending on platform).

 Gee, that's not very encouraging

I was trying to just say we have been aware of these issue too and there
are efforts going on here.

We are already building apps on these techniques and are exploring these
issues with developers. I'd rather not get into all those issues too on
this thread.

Rather, for the hard-core platform peeps here, I'd prefer to focus on some
semantics for document.register and element that doesn't cause hives (see
what I did there?).

Scott

On Mon, Apr 15, 2013 at 2:23 PM, John J Barton
johnjbar...@johnjbarton.comwrote:




 On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles sjmi...@google.com wrote:

  What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 IIRC it's not possible to override methods that will be called from
 inside of builtins, so I don't believe this is an issue (unless we change
 the playfield).


 Ugh. So we can override some methods but not others, depending on the
 implementation?

 So really these methods are more like callbacks with a funky kind of
 registration. It's not like inheriting and overriding, it's like onLoad
 implemented with an inheritance-like wording.  An API users doesn't think
 like an object, rather they ask the Internet some HowTo questions and get
 a recipe for a particular function override.

 Ok, I'm exaggerating, but I still think the emphasis on inheritance in the
 face of so me is a high tax on this problem.




  How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)

 This is another can of worms. Right now we blanket solve this by waiting
 for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
 something) and handling this appropriately for our application.


 Gee, that's not very encouraging: this is the most important kind of issue
 for a developer, more so than whether the API is inheritance-like or not.





 On Mon, Apr 15, 2013 at 1:46 PM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.comwrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can
 run init code directly after parsing, there are no 'this' issues or
 problems associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.comwrote:

   1) call 'init' when component instance tag is encountered, blocking
 parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 
 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered,
 blocking parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So non-starter is just a vote against one of three Bad choices as
 far as I can tell. In other words, these are all non-starters ;-).


  But my original question concerns blocking component documents on
 their own script tag compilation. Maybe I misunderstood.

 I don't think imports (nee component documents) have any different
 semantics from the main document in this regard. The import document may
 have an x-foo instance in it's markup, and element tags

Re: [webcomponents]: Of weird script elements and Benadryl

On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles sjmi...@google.com wrote:

  What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 IIRC it's not possible to override methods that will be called from inside
 of builtins, so I don't believe this is an issue (unless we change the
 playfield).


Ugh. So we can override some methods but not others, depending on the
implementation?

So really these methods are more like callbacks with a funky kind of
registration. It's not like inheriting and overriding, it's like onLoad
implemented with an inheritance-like wording.  An API users doesn't think
like an object, rather they ask the Internet some HowTo questions and get
a recipe for a particular function override.

Ok, I'm exaggerating, but I still think the emphasis on inheritance in the
face of so me is a high tax on this problem.




  How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)

 This is another can of worms. Right now we blanket solve this by waiting
 for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
 something) and handling this appropriately for our application.


Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.





 On Mon, Apr 15, 2013 at 1:46 PM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code runs
 and modifies my element DOM content before the user sees the un-modified
 custom element declared in mark-up? (I'm cheating, since this issue isn't
 specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.com wrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can run
 init code directly after parsing, there are no 'this' issues or problems
 associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.comwrote:

   1) call 'init' when component instance tag is encountered, blocking
 parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 
 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered, blocking
 parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So non-starter is just a vote against one of three Bad choices as
 far as I can tell. In other words, these are all non-starters ;-).


  But my original question concerns blocking component documents on
 their own script tag compilation. Maybe I misunderstood.

 I don't think imports (nee component documents) have any different
 semantics from the main document in this regard. The import document may
 have an x-foo instance in it's markup, and element tags or link
 rel=import just like the main document.


 Indeed, however the relative order of the component's script tag
 processing and the component's tag element is all I was talking about.




 On Mon, Apr 15, 2013 at 11:23 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles sjmi...@google.comwrote:

 Dimitri is trying to avoid 'block[ing] instance construction'
 because instances can be in the main document markup.


 Yes we sure hope so!



 The main document can have a bunch of markup for custom elements.
 If the user has made element definitions a-priori to parsing that 
 markup
 (including inside link rel='import'), he expects those nodes to be 
 'born'
 correctly.


 Sure.

Re: MathML and Clipboard API and events

2013-04-15 Thread Daniel Cheng

When I suggested formats that implementations ought to support, I
specifically mentioned image/svg+xml because it was mostly convertible to
native types (Windows metafile on Windows, PDF on Mac). I don't think
anyone's implemented this conversion, but it's technically possible.

On the other hand, MathML doesn't have a corresponding native equivalent on
Windows or Mac. You could argue that this is a chicken and egg problem, but
without any native format equivalents, there's no good way to map that data.

You should still be able to set MathML in the clipboard if you want. It
just won't be visible to native apps.

Daniel


On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote:

 Hi Halvord,

 Yes, your rewording sounds like a good direction to me. I still worry that
 placing plain text on the clipboard along with MathML will result in a lot
 of apps failing to paste the MathML but doing so would probably be
 considered a bug in such an app.

 Thanks for filing the bugs. I suspect that the MathML community would be
 eager to help define what needs to get stripped out of MathML to maintain
 security. However, speaking for myself, I do not know what kinds of things
 are considered dangerous. For example, MathML has markup that lets a math
 expression act as a hyperlink. Do we need to strip that out completely or
 is that dependent on the url? If there are guidelines on what is considered
 dangerous, then we could figure out exactly which MathML constructs need to
 be pruned. Or is there some other procedure for getting this done?

 Paul

  -Original Message-
  From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
  Sent: Monday, April 15, 2013 1:50 AM
  To: public-webapps@w3.org; Paul Topping
  Subject: Re: MathML and Clipboard API and events
 
  Hi Paul, thanks for your comments.
 
   Mathematical information
  
   This section says MathML often needs to be transformed to be
   copied as plain text, for example to make sure to the power of
   is shown with the caret ^ sign in a formula plain-text input.
   Such a transformation should not be part of a normal copy operation
   since that would transfer MathML. My concern is that readers get the
   idea that x 2 should always or often be transformed to x^2.
 
 
  What about saying something like
 
 
  Some applications may want to place plain text alternatives along with
  MathML formulas on he clipboard, for example to make sure .. ?
 
 
10.  Mandatory data types
  
   I am surprised not to see a MathML type in this list
 
 
  Well, since you mention it.. I've filed a bug (
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to
  your question. If you have comments or information please add (either by
  replying here or in the bug). Would be great if you could help me
 understand
  whether allowing an application to write MathML to the clipboard could
  expose an app to attacks if the MathML markup is pasted without further
  processing - see also
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700
 
 
  --
  Hallvord R. M. Steen
  Core tester, Opera Software

Re: [webcomponents]: Of weird script elements and Benadryl

*
*
*Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.*

IMO, the not-yet-upgraded case is nothing new, and developers will hardly
be surprised. This nit is no different than if devs include a jQuery plugin
script at the bottom of the body that 'upgrades' various elements on the
page after render - basically, it's an unfortunate case of That's Just Life™


Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Mon, Apr 15, 2013 at 2:23 PM, John J Barton
johnjbar...@johnjbarton.comwrote:




 On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles sjmi...@google.com wrote:

  What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 IIRC it's not possible to override methods that will be called from
 inside of builtins, so I don't believe this is an issue (unless we change
 the playfield).


 Ugh. So we can override some methods but not others, depending on the
 implementation?

 So really these methods are more like callbacks with a funky kind of
 registration. It's not like inheriting and overriding, it's like onLoad
 implemented with an inheritance-like wording.  An API users doesn't think
 like an object, rather they ask the Internet some HowTo questions and get
 a recipe for a particular function override.

 Ok, I'm exaggerating, but I still think the emphasis on inheritance in the
 face of so me is a high tax on this problem.




  How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)

 This is another can of worms. Right now we blanket solve this by waiting
 for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
 something) and handling this appropriately for our application.


 Gee, that's not very encouraging: this is the most important kind of issue
 for a developer, more so than whether the API is inheritance-like or not.





 On Mon, Apr 15, 2013 at 1:46 PM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.comwrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can
 run init code directly after parsing, there are no 'this' issues or
 problems associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.comwrote:

   1) call 'init' when component instance tag is encountered, blocking
 parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 
 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered,
 blocking parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So non-starter is just a vote against one of three Bad choices as
 far as I can tell. In other words, these are all non-starters ;-).


  But my original question concerns blocking component documents on
 their own script tag compilation. Maybe I misunderstood.

 I don't think imports (nee component documents) have any different
 semantics from the main document in this regard. The import document may
 have an x-foo instance in it's markup, and element tags or link
 rel=import just like the main document.


 Indeed, however the relative order of the component's script tag

RE: MathML and Clipboard API and events

2013-04-15 Thread Paul Topping

Why would the answer to this question be dictated by the need to convert the 
MathML format to some other “native” format? I just want my app (native or web) 
to be able to identify the clipboard data type so it can consume the data as it 
sees fit. Conversion to some other format is but one thing an app can do with 
data. If apps can’t identify MathML with confidence, they are stuck with ad hoc 
sniffing of any non-specific data types that might contain MathML. I might look 
at the plain text and XML data types to see if they contain “math”, for 
example.

In some sense MathML does have a native format on Mac and Windows. Microsoft 
and Design Science (my company) got together years ago and defined one. There 
are some other companies that support it but it seems like it is hard to get 
the word out there with a “standard” offered by commercial app vendors. If 
browsers supported MathML rendering and a distinct MathML clipboard type and 
both were defined by the W3C, it would go a long way to establishing a standard 
that matters and it would get adopted widely.

Paul

From: dch...@google.com [mailto:dch...@google.com] On Behalf Of Daniel Cheng
Sent: Monday, April 15, 2013 1:56 PM
To: Paul Topping
Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re: MathML and Clipboard API and events

When I suggested formats that implementations ought to support, I specifically 
mentioned image/svg+xml because it was mostly convertible to native types 
(Windows metafile on Windows, PDF on Mac). I don't think anyone's implemented 
this conversion, but it's technically possible.

On the other hand, MathML doesn't have a corresponding native equivalent on 
Windows or Mac. You could argue that this is a chicken and egg problem, but 
without any native format equivalents, there's no good way to map that data.

You should still be able to set MathML in the clipboard if you want. It just 
won't be visible to native apps.

Daniel

On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping 
pa...@dessci.commailto:pa...@dessci.com wrote:
Hi Halvord,

Yes, your rewording sounds like a good direction to me. I still worry that 
placing plain text on the clipboard along with MathML will result in a lot of 
apps failing to paste the MathML but doing so would probably be considered a 
bug in such an app.

Thanks for filing the bugs. I suspect that the MathML community would be eager 
to help define what needs to get stripped out of MathML to maintain security. 
However, speaking for myself, I do not know what kinds of things are considered 
dangerous. For example, MathML has markup that lets a math expression act as a 
hyperlink. Do we need to strip that out completely or is that dependent on the 
url? If there are guidelines on what is considered dangerous, then we could 
figure out exactly which MathML constructs need to be pruned. Or is there some 
other procedure for getting this done?

Paul

 -Original Message-
 From: Hallvord Reiar Michaelsen Steen 
 [mailto:hallv...@opera.commailto:hallv...@opera.com]
 Sent: Monday, April 15, 2013 1:50 AM
 To: public-webapps@w3.orgmailto:public-webapps@w3.org; Paul Topping
 Subject: Re: MathML and Clipboard API and events

 Hi Paul, thanks for your comments.

  Mathematical information
 
  This section says MathML often needs to be transformed to be
  copied as plain text, for example to make sure to the power of
  is shown with the caret ^ sign in a formula plain-text input.
  Such a transformation should not be part of a normal copy operation
  since that would transfer MathML. My concern is that readers get the
  idea that x 2 should always or often be transformed to x^2.


 What about saying something like


 Some applications may want to place plain text alternatives along with
 MathML formulas on he clipboard, for example to make sure .. ?


   10.  Mandatory data types
 
  I am surprised not to see a MathML type in this list


 Well, since you mention it.. I've filed a bug (
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to
 your question. If you have comments or information please add (either by
 replying here or in the bug). Would be great if you could help me understand
 whether allowing an application to write MathML to the clipboard could
 expose an app to attacks if the MathML markup is pasted without further
 processing - see also
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700


 --
 Hallvord R. M. Steen
 Core tester, Opera Software

Re: [webcomponents]: Of weird script elements and Benadryl

I think that rendering a placeholder (eg blank image) then filling it in
rather than blocking is good if done well (eg images with pre-allocated
space). Otherwise it's bad but less bad than blocking ;-).

But if you allow this implementation, then this whole discussion confuses
me even more. I'm thinking: If you don't need the custom constructors
during parsing, just wait for them to arrive, then call them. Something
else is going on I suppose, so I'm just wasting your time.


On Mon, Apr 15, 2013 at 2:42 PM, Daniel Buchner dan...@mozilla.com wrote:

 *
 *
 *Gee, that's not very encouraging: this is the most important kind of
 issue for a developer, more so than whether the API is inheritance-like or
 not.*

 IMO, the not-yet-upgraded case is nothing new, and developers will hardly
 be surprised. This nit is no different than if devs include a jQuery plugin
 script at the bottom of the body that 'upgrades' various elements on the
 page after render - basically, it's an unfortunate case of That's Just Life™


 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Apr 15, 2013 at 2:23 PM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles sjmi...@google.com wrote:

  What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 IIRC it's not possible to override methods that will be called from
 inside of builtins, so I don't believe this is an issue (unless we change
 the playfield).


 Ugh. So we can override some methods but not others, depending on the
 implementation?

 So really these methods are more like callbacks with a funky kind of
 registration. It's not like inheriting and overriding, it's like onLoad
 implemented with an inheritance-like wording.  An API users doesn't think
 like an object, rather they ask the Internet some HowTo questions and get
 a recipe for a particular function override.

 Ok, I'm exaggerating, but I still think the emphasis on inheritance in
 the face of so me is a high tax on this problem.




  How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)

 This is another can of worms. Right now we blanket solve this by waiting
 for an 'all clear' event (also being discussed, 'DOMComponentsReady' or
 something) and handling this appropriately for our application.


 Gee, that's not very encouraging: this is the most important kind of
 issue for a developer, more so than whether the API is inheritance-like or
 not.





 On Mon, Apr 15, 2013 at 1:46 PM, John J Barton 
 johnjbar...@johnjbarton.com wrote:

 What happens if the construction/initialization of the custom element
 calls one of the element's member functions overridden by code in a
 prototype?

 How, as component author, do I ensure that my imperative set up code
 runs and modifies my element DOM content before the user sees the
 un-modified custom element declared in mark-up? (I'm cheating, since this
 issue isn't specific to your prototype)


 On Mon, Apr 15, 2013 at 12:39 PM, Scott Miles sjmi...@google.comwrote:

 Sorry for beating this horse, because I don't like 'prototype' element
 anymore than anybody else, but I can't help thinking if there was a way to
 express a prototype without script 98% of this goes away.

 The parser can generate an object with the correct prototype, we can
 run init code directly after parsing, there are no 'this' issues or
 problems associating element with script.

 At least somebody explain why this is conceptually wrong.


 On Mon, Apr 15, 2013 at 11:52 AM, Scott Miles sjmi...@google.comwrote:

   1) call 'init' when component instance tag is encountered,
 blocking parsing,

 Fwiw, it was said that calling user code from inside the Parser could
 cause Armageddon, not just block the parser. I don't recall the details,
 unfortunately.


 On Mon, Apr 15, 2013 at 11:44 AM, John J Barton 
 johnjbar...@johnjbarton.com wrote:




 On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles sjmi...@google.comwrote:

 Thank you for your patience. :)

 ditto.




  ? user's instance code?  Do you mean: Running component instance
 initialization during document construction is Bad?

 My 'x-foo' has an 'init' method that I wrote that has to execute
 before the instance is fully 'constructed'. Parser encounters an
 x-foo/x-foo and constructs it. My understanding is that calling 
 'init'
 from the parser at that point is a non-starter.


 I think the Pinocchio link makes the case that you have only three
 choices:
1) call 'init' when component instance tag is encountered,
 blocking parsing,
2) call 'init' later, causing reflows and losing the value of not
 blocking parsing,
3) don't allow 'init' at all, limiting components.

 So

Re: MathML and Clipboard API and events

2013-04-15 Thread Daniel Cheng

On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping pa...@dessci.com wrote:

  Why would the answer to this question be dictated by the need to convert
 the MathML format to some other “native” format? I just want my app (native
 or web) to be able to identify the clipboard data type so it can consume
 the data as it sees fit. Conversion to some other format is but one thing
 an app can do with data. If apps can’t identify MathML with confidence,
 they are stuck with ad hoc sniffing of any non-specific data types that
 might contain MathML. I might look at the plain text and XML data types to
 see if they contain “math”, for example. 

 **

Because if there is no native format to convert it too, then every browser
is likely to do it differently anyway... which means you're stuck with ad
hoc detection of MathML anyway.

Like I said, there's nothing that stops you from setting text/mathml on the
HTML clipboard today. It just won't have the magic conversion to the native
type.


 
  **

 In some sense MathML does have a native format on Mac and Windows.
 Microsoft and Design Science (my company) got together years ago and
 defined one. There are some other companies that support it but it seems
 like it is hard to get the word out there with a “standard” offered by
 commercial app vendors.

I can't find any information about this native format. And even if there
is a native format, that is not the same as having a standard format in the
native data transfer object (IDataObject on Windows, NSPasteboard on Mac).

 If browsers supported MathML rendering and a distinct MathML clipboard
 type and both were defined by the W3C, it would go a long way to
 establishing a standard that matters and it would get adopted widely.

 ** **

 Paul

 ** **

 *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel
 Cheng
 *Sent:* Monday, April 15, 2013 1:56 PM
 *To:* Paul Topping
 *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org

 *Subject:* Re: MathML and Clipboard API and events

  ** **

 When I suggested formats that implementations ought to support, I
 specifically mentioned image/svg+xml because it was mostly convertible to
 native types (Windows metafile on Windows, PDF on Mac). I don't think
 anyone's implemented this conversion, but it's technically possible.

 ** **

 On the other hand, MathML doesn't have a corresponding native equivalent
 on Windows or Mac. You could argue that this is a chicken and egg problem,
 but without any native format equivalents, there's no good way to map that
 data.

 ** **

 You should still be able to set MathML in the clipboard if you want. It
 just won't be visible to native apps.

 ** **

 Daniel

 ** **

 On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote:***
 *

 Hi Halvord,

 Yes, your rewording sounds like a good direction to me. I still worry that
 placing plain text on the clipboard along with MathML will result in a lot
 of apps failing to paste the MathML but doing so would probably be
 considered a bug in such an app.

 Thanks for filing the bugs. I suspect that the MathML community would be
 eager to help define what needs to get stripped out of MathML to maintain
 security. However, speaking for myself, I do not know what kinds of things
 are considered dangerous. For example, MathML has markup that lets a math
 expression act as a hyperlink. Do we need to strip that out completely or
 is that dependent on the url? If there are guidelines on what is considered
 dangerous, then we could figure out exactly which MathML constructs need to
 be pruned. Or is there some other procedure for getting this done?

 Paul


  -Original Message-
  From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
  Sent: Monday, April 15, 2013 1:50 AM
  To: public-webapps@w3.org; Paul Topping
  Subject: Re: MathML and Clipboard API and events
 

  Hi Paul, thanks for your comments.
 
   Mathematical information
  
   This section says MathML often needs to be transformed to be
   copied as plain text, for example to make sure to the power of
   is shown with the caret ^ sign in a formula plain-text input.
   Such a transformation should not be part of a normal copy operation
   since that would transfer MathML. My concern is that readers get the
   idea that x 2 should always or often be transformed to x^2.
 
 
  What about saying something like
 
 
  Some applications may want to place plain text alternatives along with
  MathML formulas on he clipboard, for example to make sure .. ?
 
 
10.  Mandatory data types
  
   I am surprised not to see a MathML type in this list
 
 
  Well, since you mention it.. I've filed a bug (
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to
  your question. If you have comments or information please add (either by
  replying here or in the bug). Would be great if you could help me
 understand
  whether allowing an application to

RE: MathML and Clipboard API and events

2013-04-15 Thread Paul Topping

http://www.w3.org/TR/MathML3/appendixb.html mentions both Mac and Windows 
formats for MathML.

From: dch...@google.com [mailto:dch...@google.com] On Behalf Of Daniel Cheng
Sent: Monday, April 15, 2013 3:49 PM
To: Paul Topping
Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re: MathML and Clipboard API and events

On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping 
pa...@dessci.commailto:pa...@dessci.com wrote:
Why would the answer to this question be dictated by the need to convert the 
MathML format to some other “native” format? I just want my app (native or web) 
to be able to identify the clipboard data type so it can consume the data as it 
sees fit. Conversion to some other format is but one thing an app can do with 
data. If apps can’t identify MathML with confidence, they are stuck with ad hoc 
sniffing of any non-specific data types that might contain MathML. I might look 
at the plain text and XML data types to see if they contain “math”, for 
example.
Because if there is no native format to convert it too, then every browser is 
likely to do it differently anyway... which means you're stuck with ad hoc 
detection of MathML anyway.

Like I said, there's nothing that stops you from setting text/mathml on the 
HTML clipboard today. It just won't have the magic conversion to the native 
type.

In some sense MathML does have a native format on Mac and Windows. Microsoft 
and Design Science (my company) got together years ago and defined one. There 
are some other companies that support it but it seems like it is hard to get 
the word out there with a “standard” offered by commercial app vendors.
I can't find any information about this native format. And even if there is a 
native format, that is not the same as having a standard format in the native 
data transfer object (IDataObject on Windows, NSPasteboard on Mac).
If browsers supported MathML rendering and a distinct MathML clipboard type and 
both were defined by the W3C, it would go a long way to establishing a standard 
that matters and it would get adopted widely.

Paul

From: dch...@google.commailto:dch...@google.com 
[mailto:dch...@google.commailto:dch...@google.com] On Behalf Of Daniel Cheng
Sent: Monday, April 15, 2013 1:56 PM
To: Paul Topping
Cc: Hallvord Reiar Michaelsen Steen; 
public-webapps@w3.orgmailto:public-webapps@w3.org

Subject: Re: MathML and Clipboard API and events

When I suggested formats that implementations ought to support, I specifically 
mentioned image/svg+xml because it was mostly convertible to native types 
(Windows metafile on Windows, PDF on Mac). I don't think anyone's implemented 
this conversion, but it's technically possible.

On the other hand, MathML doesn't have a corresponding native equivalent on 
Windows or Mac. You could argue that this is a chicken and egg problem, but 
without any native format equivalents, there's no good way to map that data.

You should still be able to set MathML in the clipboard if you want. It just 
won't be visible to native apps.

Daniel

On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping 
pa...@dessci.commailto:pa...@dessci.com wrote:
Hi Halvord,

Yes, your rewording sounds like a good direction to me. I still worry that 
placing plain text on the clipboard along with MathML will result in a lot of 
apps failing to paste the MathML but doing so would probably be considered a 
bug in such an app.

Thanks for filing the bugs. I suspect that the MathML community would be eager 
to help define what needs to get stripped out of MathML to maintain security. 
However, speaking for myself, I do not know what kinds of things are considered 
dangerous. For example, MathML has markup that lets a math expression act as a 
hyperlink. Do we need to strip that out completely or is that dependent on the 
url? If there are guidelines on what is considered dangerous, then we could 
figure out exactly which MathML constructs need to be pruned. Or is there some 
other procedure for getting this done?

Paul

 -Original Message-
 From: Hallvord Reiar Michaelsen Steen 
 [mailto:hallv...@opera.commailto:hallv...@opera.com]
 Sent: Monday, April 15, 2013 1:50 AM
 To: public-webapps@w3.orgmailto:public-webapps@w3.org; Paul Topping
 Subject: Re: MathML and Clipboard API and events

 Hi Paul, thanks for your comments.

  Mathematical information

  This section says MathML often needs to be transformed to be
  copied as plain text, for example to make sure to the power of
  is shown with the caret ^ sign in a formula plain-text input.
  Such a transformation should not be part of a normal copy operation
  since that would transfer MathML. My concern is that readers get the
  idea that x 2 should always or often be transformed to x^2.

 What about saying something like

 Some applications may want to place plain text alternatives along with
 MathML formulas on he clipboard, for example to make sure .. ?

   10.  Mandatory data types

  I am surprised not to see a MathML

Re: MathML and Clipboard API and events

2013-04-15 Thread Daniel Cheng

I see. I wasn't aware of that reference since I didn't find it in my
searching. In that case, I don't have any particular objection though I
don't really know what would needs to be sanitized.

Daniel


On Mon, Apr 15, 2013 at 4:12 PM, Paul Topping pa...@dessci.com wrote:

  http://www.w3.org/TR/MathML3/appendixb.html mentions both Mac and
 Windows formats for MathML. 

 ** **

 *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel
 Cheng
 *Sent:* Monday, April 15, 2013 3:49 PM

 *To:* Paul Topping
 *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
 *Subject:* Re: MathML and Clipboard API and events

  ** **

 On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping pa...@dessci.com wrote:***
 *

  Why would the answer to this question be dictated by the need to convert
 the MathML format to some other “native” format? I just want my app (native
 or web) to be able to identify the clipboard data type so it can consume
 the data as it sees fit. Conversion to some other format is but one thing
 an app can do with data. If apps can’t identify MathML with confidence,
 they are stuck with ad hoc sniffing of any non-specific data types that
 might contain MathML. I might look at the plain text and XML data types to
 see if they contain “math”, for example. 

  Because if there is no native format to convert it too, then every
 browser is likely to do it differently anyway... which means you're stuck
 with ad hoc detection of MathML anyway.

 ** **

 Like I said, there's nothing that stops you from setting text/mathml on
 the HTML clipboard today. It just won't have the magic conversion to the
 native type.

  

   

  

 In some sense MathML does have a native format on Mac and Windows.
 Microsoft and Design Science (my company) got together years ago and
 defined one. There are some other companies that support it but it seems
 like it is hard to get the word out there with a “standard” offered by
 commercial app vendors.

  I can't find any information about this native format. And even if
 there is a native format, that is not the same as having a standard format
 in the native data transfer object (IDataObject on Windows, NSPasteboard on
 Mac).

  If browsers supported MathML rendering and a distinct MathML clipboard
 type and both were defined by the W3C, it would go a long way to
 establishing a standard that matters and it would get adopted widely.

  

 Paul

  

 *From:* dch...@google.com [mailto:dch...@google.com] *On Behalf Of *Daniel
 Cheng
 *Sent:* Monday, April 15, 2013 1:56 PM
 *To:* Paul Topping
 *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org


 *Subject:* Re: MathML and Clipboard API and events

  

 When I suggested formats that implementations ought to support, I
 specifically mentioned image/svg+xml because it was mostly convertible to
 native types (Windows metafile on Windows, PDF on Mac). I don't think
 anyone's implemented this conversion, but it's technically possible.

  

 On the other hand, MathML doesn't have a corresponding native equivalent
 on Windows or Mac. You could argue that this is a chicken and egg problem,
 but without any native format equivalents, there's no good way to map that
 data.

  

 You should still be able to set MathML in the clipboard if you want. It
 just won't be visible to native apps.

  

 Daniel

  

 On Mon, Apr 15, 2013 at 8:44 AM, Paul Topping pa...@dessci.com wrote:***
 *

 Hi Halvord,

 Yes, your rewording sounds like a good direction to me. I still worry that
 placing plain text on the clipboard along with MathML will result in a lot
 of apps failing to paste the MathML but doing so would probably be
 considered a bug in such an app.

 Thanks for filing the bugs. I suspect that the MathML community would be
 eager to help define what needs to get stripped out of MathML to maintain
 security. However, speaking for myself, I do not know what kinds of things
 are considered dangerous. For example, MathML has markup that lets a math
 expression act as a hyperlink. Do we need to strip that out completely or
 is that dependent on the url? If there are guidelines on what is considered
 dangerous, then we could figure out exactly which MathML constructs need to
 be pruned. Or is there some other procedure for getting this done?

 Paul


  -Original Message-
  From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
  Sent: Monday, April 15, 2013 1:50 AM
  To: public-webapps@w3.org; Paul Topping
  Subject: Re: MathML and Clipboard API and events
 

  Hi Paul, thanks for your comments.
 
   Mathematical information
  
   This section says MathML often needs to be transformed to be
   copied as plain text, for example to make sure to the power of
   is shown with the caret ^ sign in a formula plain-text input.
   Such a transformation should not be part of a normal copy operation
   since that

Re: [webcomponents]: Of weird script elements and Benadryl