Re: ::part Additions

[Bronislav Klučka]

On 3.7.2013 5:36, Steve Orvell wrote:



3/ ability to create complex selectors using ::part

This concerns me. I will stipulate that you have shown this is useful 
and that this type of styling is not otherwise as easily achievable.


The problem I see is that we've now exposed the structure of a 
shadowRoot as part of its 'public' styling api. If ::part(foo) > 
::part(bar) is an important state, I'm then not allowed to move part 
bar with respect to part foo. This 'implementation detail' of its 
ShadowDOM is now set in stone.


Perhaps we could achieve similar expressiveness without the inherent 
brittleness by adding the ability to specify parts that map to a 
complex selector specified within the shadowRoot.


From JavaScript, this might be something like: 
shadowRootHost.addPart('foobar', '::part(foo) > ::part(bar)');


As tab mentioned
in shadow, following parts


  

  

should be in direct descendant - ancestor relationship, regardless of what is 
in between (there just can be no other part), I guess this is reasonable 
exposition, from Delphi / Visual Studio controls experience, in more complex 
complex controls one simply has to understand the relationship of publicly 
visible parts of control (if I would want to set an icon on the second tab of 
PageControl, I simply have to know, where i can find this tab 
{CustomerInfo.Tabs[1].Icon})

But I like your idea, much more generic and looking at it, since this is Shadow 
internal issue, I would go as far as

shadowRootHost.addPart('article-time', 'article header time');

which would mean that all time elements in header elements in article within 
this shadow root would be reachable by ::part(article-time), and in next 
release one could change it to

shadowRootHost.addPart('article-time', 'article header time,article footer 
time');

and ::part(article-time) would target both

I like that, because it hides the internals and makes changes easier

B.







On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka 
mailto:bronislav.klu...@bauglir.com>> 
wrote:


Hi,

since new paradigm conserning Custom Pseudo Elements have been
introduced
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html
(part 5)

I'd like to suggest few additions/changes:

1/ ability to style nested shadow dom elements
2/ change of part attribute from DOMString to DOMTokenList
3/ ability to create complex selectors using ::part

the description/reasoning for this can be found here:
http://projects.webnt.eu/spec/shadow/index.php

In case ::part will not be in spec, the same still applies to pseudos

Bronislav Klucka

Re: ::part Additions

[Bronislav Klučka]

there are still too many strange things going on :]
see below

On 2.7.2013 22:19, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 9:16 AM, Bronislav Klučka
 wrote:

On 2.7.2013 18:03, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
 wrote:

On 2.7.2013 17:28, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
 wrote:

2/ change of part attribute from DOMString to DOMTokenList

This sounds all right.  part='' is already class-like, since multiple
elements can have the same part='' value.  The example at your page is
pretty compelling about this ability's usage.  I guess ::part() would
also expand to taking a list of idents.

Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)

and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)

:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))

Oh, no no no.  ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got.  The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax.  If we want to
support this, it has to be through something like "::part(node-checked
node-selected)".

As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like "x-video::part(controls)::part(play-button)" (assuming
the controls were actually implemented by another component nested
inside the  shadow tree).

so
x-video::part(controls)::part(play-button)
would target part="play-button" within part="controls" within x-video?

Not quite what I intended.  I was thinking that ::part(controls) would
be an  element or something, and ::part(play-button) would
be in the  shadow tree.

so it would select something like

   #SHADOW ROOT
   
  #SHADOW ROOT
 
   


how is it, that one time the ::part targets element and other time 
attribute? or is it



   #SHADOW ROOT
   
  #SHADOW ROOT
 
   

?
in both cases, how can you target element inside shadow tree? or do you 
essentially mean


   #SHADOW ROOT
   
  #SHADOW ROOT
 
   


so the no space syntax means crossing shadow boudaries and space syntax 
means no crossing

so

x-video::part(controls) ::part(play-button) //with space
would mean


   #SHADOW ROOT
   
 
   


I have a problem with that, described below




and the list of idents
::part(part1 part2) {without comma? with comma?}
would target part="part1 part2"? an AND operator?

the OR I've mentioned being correct?

Yes to all.


so how about this:

::part(node-checked)::part(node-selected)
would represent any selected node within checked node (regardless of level
of nesting)
::part(node-checked) > ::part(node-selected)
would represent selected node within checked node (directly within, no other
part in between)

No, this is definitely inconsistent.  The first one would have to be
"::part(node-checked) ::part(node-selected)" (with a space between
them).

An alternative is to go the ::content route, and kill the parentheses.
  As soon as you type ::part, you're in the "surface shadow tree" of
the component (which respects the shape of the real shadow tree, but
may skip nodes), and can then use the standard selectors/combinators
to get through it.

You'd need some additional work to make multiple part values work,
perhaps just treating part='' literally as a class, like:

x-video::part .play-button

Selecting multiple would be:

x-tree::part .node-checked.node-selected

(though I'd change the part='' stuff around so I could just write
".node.checked.selected")

Selecting children would be:

x-tree::part .node-checked .node-selected

Descending into nested shadow trees would just involve adding more
::part pseudos to the correct places.
And that is exactly the problem, TreeView, popup menu, pretty much every 
controls containers (thing about placing tabs into one tab of another 
tabs, that is placed into on tab of the third tabs)
The shadow nesting could go on and on, there is no way you can style 
that without knowing the exact structure


if I would want all LI to have disc, all I can do is type
li { list-style-type: disc; }
and it's always, everywhere

If I would want all inactive tabs of TabControl (implemented using 
shadow) to have gray text color what would I do? just wondering...

cannot target
tab-control::part(tabs) ::part(inactive) - you cannot target 
 ele

Re: ::part Additions

[Bronislav Klučka]

On 2.7.2013 18:21, Bronislav Klučka wrote:


On 2.7.2013 18:03, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
 wrote:

On 2.7.2013 17:28, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
 wrote:

2/ change of part attribute from DOMString to DOMTokenList

This sounds all right.  part='' is already class-like, since multiple
elements can have the same part='' value.  The example at your page is
pretty compelling about this ability's usage.  I guess ::part() would
also expand to taking a list of idents.

Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)

and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)

:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))

Oh, no no no.  ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got.  The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax.  If we want to
support this, it has to be through something like "::part(node-checked
node-selected)".

As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like "x-video::part(controls)::part(play-button)" (assuming
the controls were actually implemented by another component nested
inside the  shadow tree).

~TJ


And back to

x-video::part(controls)::part(play-button)

example

how it would be different from

x-video ::part(controls) ::part(play-button)

or this wouldn't be possible? the only possibilities being
::part(play-button)
or
::part(controls)::part(play-button)
or
x-video::part(controls)::part(play-button)

Brona







I do not want to spam this topic so just last thought on pseudo-elements 
and custom pseudo elements (parts), it's more generic issue (CSS 
selector syntax)
the no-space syntax can work when there is only one pseudo-element and 
usually the last one


p::first-letter - makes sense
thou as an "element:: it would be better to  for something like
p ::first-letter or p > ::first-letter not to target first letters in 
SPANs in P..

because its element within other element... not a filter
but when we start to nest and go more complex it becomes really strange

consider chessboard
--
with regular HTML+CSS one would go for something like

table td { background: silver; }
table tr:nth-of-child(2n + 1) td:nth-of-child(2n),
table tr:nth-of-child(2n) td:nth-of-child(2n + 1) { background: black; }
--
my way (wrong way)

chessboard ::part(cell) { background: silver; }
chessboard ::part(row):nth-of-child(2n + 1) ::part(cell):nth-of-child(2n),
chessboard ::part(row):nth-of-child(2n) ::part(cell):nth-of-child(2n + 
1) { background: black; }


nesting working as usual (no change there), replacing TR and TD with 
custom counterparts - intuitive, easy

--
correct way

chessboard::part(cell) { background: silver; }
chessboard::part(row):nth-of-child(2n + 1)::part(cell):nth-of-child(2n),
chessboard::part(row):nth-of-child(2n)::part(cell):nth-of-child(2n + 1) 
{ background: black; }


mixing of pseudo classes and pseudo elements into one strange selector 
one have to carefully read to separate parts, what is pseudo element, 
what is pseudo class.

--

the fact is, that no space creates filtering and space created nesting 
is throughout the CSS, regardless of selector (tag, class, id, 
attrribute), with this only exception. pseudo element is not actually 
filter on set of parents, but nested parts of all parents


p ::part(this1) + ::part(this2) makes sense and only one sense
p::part(this1) + p::part(this2) is confusing

as I wrote above, nesting several pseudo elements, allowing complex 
selectors makes this a lot more confusing.



 Brona

Re: ::part Additions

[Bronislav Klučka]

On 2.7.2013 18:03, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
 wrote:

On 2.7.2013 17:28, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
 wrote:

2/ change of part attribute from DOMString to DOMTokenList

This sounds all right.  part='' is already class-like, since multiple
elements can have the same part='' value.  The example at your page is
pretty compelling about this ability's usage.  I guess ::part() would
also expand to taking a list of idents.

Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)

and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)

:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))

Oh, no no no.  ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got.  The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax.  If we want to
support this, it has to be through something like "::part(node-checked
node-selected)".

As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like "x-video::part(controls)::part(play-button)" (assuming
the controls were actually implemented by another component nested
inside the  shadow tree).

~TJ


And back to

x-video::part(controls)::part(play-button)

example

how it would be different from

x-video ::part(controls) ::part(play-button)

or this wouldn't be possible? the only possibilities being
::part(play-button)
or
::part(controls)::part(play-button)
or
x-video::part(controls)::part(play-button)
  


Brona

Re: ::part Additions

[Bronislav Klučka]

On 2.7.2013 18:03, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
 wrote:

On 2.7.2013 17:28, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
 wrote:

2/ change of part attribute from DOMString to DOMTokenList

This sounds all right.  part='' is already class-like, since multiple
elements can have the same part='' value.  The example at your page is
pretty compelling about this ability's usage.  I guess ::part() would
also expand to taking a list of idents.

Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)

and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)

:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))

Oh, no no no.  ::part() is not a pseudo-class, it's a pseudo-element -
it points to a brand new element, rather than filtering the one you've
got.  The fact that part='' is acting like class='' notwithstanding,
using ::part() like would be an abuse of the syntax.  If we want to
support this, it has to be through something like "::part(node-checked
node-selected)".

As an example of why violating the syntax model is a bad idea, this
directly conflicts with your desire to surface the ::part()s of nested
components - the thing that exposes them might be exposed as a
::part() as well, so you need to be able to chain off of an existing
::part(), like "x-video::part(controls)::part(play-button)" (assuming
the controls were actually implemented by another component nested
inside the  shadow tree).

~TJ

so
x-video::part(controls)::part(play-button)
would target part="play-button" within part="controls" within x-video?

and the list of idents
::part(part1 part2) {without comma? with comma?}
would target part="part1 part2"? an AND operator?

the OR I've mentioned being correct?

so how about this:

::part(node-checked)::part(node-selected)
would represent any selected node within checked node (regardless of level of 
nesting)
::part(node-checked) > ::part(node-selected)
would represent selected node within checked node (directly within, no other 
part in between)

?





Brona

Re: ::part Additions

[Bronislav Klučka]

On 2.7.2013 17:28, Tab Atkins Jr. wrote:

On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
 wrote:

Hi,

since new paradigm conserning Custom Pseudo Elements have been introduced
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html
(part 5)

I'd like to suggest few additions/changes:

1/ ability to style nested shadow dom elements

We discussed this in a previous meeting (surfacing nested component
parts, either automatically or via a switch) but I don't recall what
the conclusion was.  Dimitri?

As Dimitri mentioned, there is a bug
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22462
I'm mentioning it in my document, I'm fine with this solution, the 
question there is with default value.

2/ change of part attribute from DOMString to DOMTokenList

This sounds all right.  part='' is already class-like, since multiple
elements can have the same part='' value.  The example at your page is
pretty compelling about this ability's usage.  I guess ::part() would
also expand to taking a list of idents.


Why would it? We have established convention for AND operator
.class1.class2
would became
::part(node-checked)::part(node-selected)

and for OR operator
.class1, .class2
would became
::part(node-checked), ::part(node-selected)

:matches(.class1, .class2)
would became
:matches(::part(node-checked), ::part(node-selected))




3/ ability to create complex selectors using ::part

Interesting!  I guess it would just surface a synthesized tree based
on only the elements that contain part=''?  That is, two elements
would have a parent-child relationship (and thus be selectable with
the > combinator) if they were the closest elements with part='', even
if there were other elements between them?  Like:


   
 
   


~TJ
Interesting point, maybe little bit counter intuitive for some people, 
but since it's shadow and we are essentially

targeting the only visible parts within the DOM it makes sense

Brona

::part Additions

[Bronislav Klučka]

Hi,

since new paradigm conserning Custom Pseudo Elements have been introduced
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html
(part 5)

I'd like to suggest few additions/changes:

1/ ability to style nested shadow dom elements
2/ change of part attribute from DOMString to DOMTokenList
3/ ability to create complex selectors using ::part

the description/reasoning for this can be found here:
http://projects.webnt.eu/spec/shadow/index.php

In case ::part will not be in spec, the same still applies to pseudos

Bronislav Klucka

Re: Web Component Element definition

[Bronislav Klučka]

  
  
Hi,
  
  I actually came across this issue while using Polymer's
  platform.js...
  I could not make it work... 
  
  I have to do magic like this...
  
    <br>
      if (this !== window) <br>
      {<br>
    var first = true;<br>
    this.register({<br>
      prototype: {<br>
    "readyCallback": function() {<br>
      <br>
      <br>
      if (first)<br>
      {<br>
    Object.defineProperties(XBauglirListItem.prototype,
  {  <br>
      "foox": {<br>
    "value": function() { <br>
      alert('d');<br>
    },<br>
      }<br>
    }); <br>
      }<br>
      first = false;<br>
    },<br>
  <br>
      }<br>
    });<br>
      }<br>
    
  
  putting the definition outside readyCallback caused unknown XBauglirListItem error

so I'm wondering how it's gonna be in web Components... since
the mechanism is the same... until readyCallback
  i called, the construstor function does not exists I assume
  
  ---

({
  readyCallback: function() { },
  get foo() {},
  set foo() {}
})
  confuses me... I 've seen the whole
  ({
  }) 
  contruct in web comps for the first time and I think it's web
  comps specific... 
  
  and the setters and getters... from your example... are those
  getter and setters for method foo or property foo? Shouldn't
  setter have a parameter? The value that is about to be set? how do
  I define whether property is changable, enumerable? 
  
  Or is this working proposition of Web Comps based on working
  proposition of ES6?

 
  Brona

On 23.6.2013 21:11, Scott Miles wrote:


  
To be clear, this question doesn't really have
  anything to do with the components spec. The bottom line from
  the spec is that the completion-value of the script should
  reference an object that will be used as the element
  prototype.


How you generate that prototype is completely up
  to you, and there are many ways you can do it.  See examples
  below.



Fwiw, my team (http://www.polymer-project.org/)
  is not an advocate of the completion-value gambit. We are
  pushing for two-way initialization. In other words, a separate
  method to register the prototype.


In any case, here are examples. 


You can use descriptors, but you don't need them
  for get/set:


({
  readyCallback: function() { },
  get foo() {},
  set foo() {}
})


if you really want to use descriptors, you can do


Object.create(Object.prototype, {

   property: {
 
    get: function() { return 5; },
   
    set: function(value) {}

   }
});


or you can mix and match:


var prototype = {
  readyCallback: function() { },
};
Object.defineProperty(prototype,
{ 
   
property: {
   
      get: function() { return 5; },
   
      set: function(value) {}
   
  }
  });

prototype;
      
      


On Sun, Jun 23, 2013 at 11:45 AM,
  Bronislav Klučka <bronislav.klu...@bauglir.com>
  wrote:
  

  
On 23.6.2013 20:42, Bronislav Klučka wrote:

  Hi,
  http://www.w3.org/TR/2013/WD-components-intro-20130606/#lifecycle-callbacks
  
  shows defining element methods, next to the life cycle
  it also shows definition of methods "ticks" and
  "chime",
  I wonder how this construct
  
  ({
  
  });
  
  is compatible with ES5 object properties descriptors,
  in ES5 it is possible to define getters and settes for
  properties/methods, is it the possible to do something
  l

Re: Web Component Element definition

[Bronislav Klučka]

On 23.6.2013 20:42, Bronislav Klučka wrote:

Hi,
http://www.w3.org/TR/2013/WD-components-intro-20130606/#lifecycle-callbacks 

shows defining element methods, next to the life cycle it also shows 
definition of methods "ticks" and "chime",

I wonder how this construct

({

});

is compatible with ES5 object properties descriptors, in ES5 it is 
possible to define getters and settes for properties/methods, is it 
the possible to do something like



...


({
  readyCallback: function () {
//init component
  },
});

</pre><tt>Object.defineProperties(this.prototype, {  // or maybe 
</tt><tt>Object.defineProperties(this, {
</tt><pre style="margin: 0em;">
  "property": {
"get": function() { return 5; }
"set": function(value) {}
}
});




Will it work? Is it suppose to work?

Brona




Of course I ment
Object.defineProperties(ElementConsructorName.prototype

Brona

Web Component Element definition

[Bronislav Klučka]

Hi,
http://www.w3.org/TR/2013/WD-components-intro-20130606/#lifecycle-callbacks
shows defining element methods, next to the life cycle it also shows 
definition of methods "ticks" and "chime",

I wonder how this construct

({

});

is compatible with ES5 object properties descriptors, in ES5 it is 
possible to define getters and settes for properties/methods, is it the 
possible to do something like



...


({
  readyCallback: function () {
//init component
  },
});

Re: [webcomponents]: First stab at the Web Components spec

[Bronislav Klučka]

hi
let's apply KISS here
how about just
rel="document"
or
rel="htmldocument"

Brona

On 8.3.2013 22:05, Dimitri Glazkov wrote:

On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell  wrote:

Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
modules. Perhaps "package" is better?

The name is difficult. My main point is that using "components" causes
unnecessary confusion.

I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules:

1) must reflect the intent and convey the meaning.
2) link type and name of the spec must match.
3) no biting.

:DG<

Re: [webcomponents]: First stab at the Web Components spec

[Bronislav Klučka]

yes, it actually is document related to current document... does not 
seem confusing to me at all,

but I can go with fragment or stub as well :]

B.


On 8.3.2013 22:25, Dimitri Glazkov wrote:

On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles  wrote:

Agree. Seems like Dimitri and Anne decided that these targets are
'document', did they not?

rel="document" seems to communicate that the relation of the linked
resources to the document is "document", which is at least cyclical if
not totally wrong :)

:DG<

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 7.3.2013 19:54, Scott González wrote:



Who is killing anything?

Hi, given
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0676.html
I've misunderstood your point as advocating against Shadow altogether.

My concerns are twosome:
1st one is ideological: you do not touch internals, it's not good 
practice, but I appreciate the fact, that good practice is not a dogma 
and from time to time is good thing to break it.
2nd is is practical: not having to care about the internals, so I do not 
break it by accident from outside. If the only way to work with 
internals is by explicit request for internals and then working with 
them, but without the ability to breach the barrier accidentally, 
without the explicit request directly on the shadow host, this concern 
is satisfied and yes, there will be no clashes except for control naming.


Brona

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

  
  

On 7.3.2013 19:08, Scott González
  wrote:


  This just seems like a big rant. 

may seem a bit harsh, but I'm trying to compress my point of view,
it's not like we can have hours long discussion about pros and cons.
i mean no harm :)


  Your questions about things like should scripts use
closures are just derailing the conversation. I'm honestly not
sure it's worth replying to any of your points. But to clarify
some points I think are relevant:


You are right, because someone is trying to kill important (from my
point of view) technology: being able to actually create reusable UI
libraries. You may think we have those, we do not... Againg from my
experience from other languages... I have approx. 200 controls
installed in my Delphy from approx. 12 vendors. I can use them in
any combination... seamlessly, without caring how are those written
(unless pig wrote them). You cannot do that on Web, don't get me
wrong I admire jQuery, it's like the alphabet of JS programming. But
regardless of how clever people work on it, it's not self contained,
it leaks where? in DOM/CSS and it collides. 


  

  

It's not possible to expose potions of a DOM. So, if you
  want any customization at the DOM level, it's all or nothing.
  You can't expect to expose a JS API on top of a web component
  that is small and nice to work with and provide the
  flexibility of having control over the DOM. You can document
  that your web component provides some hierarchical structure
  and uses classes in a specific way. Then users can make
  modifications, for example, injecting additional markup,
  without breaking the structure or semantics of the existing
  web component. I'm not advocating for total anarchy.
  

But that is exactly my point. I do not want to expose the whole DOM
and then make programmer read tons of docs. about internals because
they leak. I cannot imagine to have app using 50 different
controls/component from 4 vendors and having to figure out how to
make them not clash 
If it's safe to modify DOM, I make it public. If it's not, than it
is not, then do not touch it.

  


As for the  example: This isn't
  arbitrary 3rd party scripts coming and crippling your DOM in
  unexpected ways. This is you as the developer of the site
  saying the native experience is too limiting and then opting
  in to a different UI. This is also not global, change the
  world behavior, this is on a per-element basis.
  

well... if the 3rd party control is not fitting to your scenario,
don't use it, or rewrite it (if you have the permission). My JS
example may seem like distraction to you, but it's actually the same
point here yet again. If you find JS class that is almost there, 
you have 3 choices: rewrite it, throw it away and find another or
write your own.
Yes, you are the developer of the site, so you can choose what you
want/can use. It's not mandatory for you to use input[type="date"]
containing shadow. Pick another, write your own.

If it's wrong technology for you, do not use it. But why killing it
altogether for anyone? Because someone else wrote something you
cannot modify?

B.





  
    

  
  

On Thu, Mar 7, 2013 at 12:55 PM,
  Bronislav Klučka <bronislav.klu...@bauglir.com>
  wrote:
  
On 7.3.2013 17:51, Scott González wrote:

  

  On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky <bzbar...@mit.edu
  bzbar...@mit.edu>>
  wrote:
  
      On 3/6/13 1:31 PM, Scott González wrote:
  
          but we feel the pros of exposing internals
  outweigh the cons.
  
  
      When you say "exposing internals" here, which one
  of the following
      do you mean:
  
      1)  Exposing internals always.
      2)  Exposing internals by default, with a way to
  opt into not
      exposing.
      3)  Not exposing internals by default, with a way
  to opt into
      exposing.
  
  
  I was replying in the context of jQuery, in which we
  expose most internals always. 

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 7.3.2013 17:51, Scott González wrote:
On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky > wrote:


On 3/6/13 1:31 PM, Scott González wrote:

but we feel the pros of exposing internals outweigh the cons.


When you say "exposing internals" here, which one of the following
do you mean:

1)  Exposing internals always.
2)  Exposing internals by default, with a way to opt into not
exposing.
3)  Not exposing internals by default, with a way to opt into
exposing.


I was replying in the context of jQuery, in which we expose most 
internals always. There is no option to have jQuery hide it's internals.


And what do you feel the pros are of whichever one you're talking
about compared to the items after it on the list, just so we're on
the same page?


In terms of web components, I'm not sure I (or anyone else on the 
jQuery team) have too strong of an opinion on the default. However, I 
can say that I find it extremely annoying that I can't reach into the 
Shadow DOM for new input types and just kill everything. I want type="date"> to render as  because native HTML will 
likely never be as flexible as custom JS components. Obviously I'd 
prefer a standard, and web components are supposed to solve this. But 
in the meantime, we're provided with useful semantics and validation 
that go unused if you want the flexibility of a JS date picker.


As someone building JS components, I see the benefit of having the 
internals exposed to me so I can do as I please. I also recognize the 
pain of maintaining code that reaches into internals. As someone who 
cares about the future of the web, I see the very real danger of this 
becoming widespread and ending up in the situation Boris wants us to 
avoid.


I do not mean to sound cocky here, but I'd really like to know how many 
people here are used to languages that can separate internals and 
externals, because if you are simply not used to it, you simply cannot 
see the benefits and all goes to "I'm used to play with internals of 
controls", regardless how wrong it is. I mean it's like discussion of 
introducing private properties of an class and someone complaining that 
he/she is used to touch everything he/she desires. I find it hard to 
explain how wrong that simply is. You do not touch anything else than 
external API provided by opaque blackbox. As someone building components 
in several languages not being able to hide certain things is scary to me.


I mean why do we wrap JS code in anonymous functions?
(function(){
//place code here
})();
well.. are you advocating in jQuery not to do that? Because someone 
wants to play with internals? are you advocating that it does not matter 
what can anyone change in jQuery internals or what can leak from jQuery 
internals to outside space? - "well he/she likes to play, let him/her, 
and if anything brakes down, his/hers fault, and by the way he/she have 
to be especially careful not to use variable names we are using already 
, functions as well... but he/she gets used to it" - I mean where is the 
difference here? Just open jQuery code... bunch of internal variables... 
why are those not public? Again, how can you advocate for non-private 
DOM while working in script that is whole private... just exposing the 
necessary.
And thanks for making my point, if my control depends on type=date> I do not want some external script to cripple it!
I opened jQuery datepicker source code (you seem to like it, I cannot 
tell you how glad I am for Chrome date picker that I can finally get rid 
of jQ datepicker [and jQ altogether])... so many private variables... 
should I repeat myself? Where is the difference? Apparently even jQuery 
team does not care whether programers wants to play with everything, but 
cares about that fact, that you can plug jQuery anywhere and it will not 
break by outside scripts and that outside space will not break by jQuery.
And that's what I'm expecting from ShadowDOM = controls you insert and 
they work, no side effects what so ever.


From my JS/HTML control experience?
* I want all my tables to look certain way - boom jQury datepicker 
brokes down, tinyMCE brokes down
* I want all my tables to have and option for exporting data - boom 
jQury datepicker brokes down, tinyMCE brokes down
* I switch from content-box to border-box - pretty much every 3rd party 
control breaks down
* I want to autogenerate table of contents (page menu links) from 
headings in the article, f*ck, some stupid plugin gets involved

that's like the last week experience
I mean why do I have to spend time learning *internals* of controls in 
HTML? Why do I have to look to what class names that control is using 
not to break thinks? etc.


And I can go on and on and on... I mean there are people who see the 
clear borders as benefit for their work. Why not giving them this option 
(considering HTML/JS controls are like the only major language 
constructed controls 

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 6.3.2013 21:00, Boris Zbarsky wrote:

On 3/6/13 1:31 PM, Scott González wrote:

but we feel the pros of exposing internals outweigh the cons.


When you say "exposing internals" here, which one of the following do 
you mean:


1)  Exposing internals always.
2)  Exposing internals by default, with a way to opt into not exposing.
3)  Not exposing internals by default, with a way to opt into exposing.

?  And what do you feel the pros are of whichever one you're talking 
about compared to the items after it on the list, just so we're on the 
same page?


-Boris



What does the "exposing internals" means anyway? Does it mean that there 
are no boundaries at all and e.g. document.querySelector can access 
internal? Or does it mean that you can access internals only by 
explicitly asking for existing shadowRoot of element and than work with it?


B.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 6.3.2013 18:50, Dimitri Glazkov wrote:
On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan > wrote:


On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson mailto:a...@google.com>> wrote:
> Also, if shadows are public by default the API to access the
shadow is well
> defined. If shadows are private by default and components decide
to expose
> the shadow ad hoc then there is no standardized API.

This doesn't have to be the case. Shadows can be private by default
with a well defined and consistent API to override the default.


So, here's a quick strawman:

1) add an optional parameter to createShadowRoot to indicate whether 
the shadow tree will be public or private (default TBD)
2) when a shadow tree is private, the corresponding 
HTMLElement.shadowRoot and HTMLShadowElement.olderShadowRoot return 
either a) the next older public tree root or b) null if older tree 
doesn't exist, effectively skipping from the private shadow tree over 
to the next older public tree.


WDYT?

If this is okay with everyone, we can focus on debating the default 
parameter value.


:DG<


Frankly from my perspective, which would be default (public or private) 
is no issue at all, just pick one, could not care less. Discussion on 
this mater (as long as we agree on the point that the value is Boolean 
:) ) seems like a waste of time to me. Thou I would go for private as 
default if default option is chosen.
The best solution would be to not go with default at all, make it nice 
explicit parameter (mandatory), but that may conflict with existing 
usage (?). For my controls I'll go with global option for all controls: 
full private for release, probably public for development (for testing, 
how the control behave, it may be useful to have access to its internals).


B.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 25.2.2013 19:52, Scott Miles wrote:
Don't we have a situation where people can simply take your source and 
change it regardless (barring legal imperatives, which are orthogonal 
in my view)?
Sure we do, but clear edges makes clear contract what can change in the 
future without informing anyone and what is carved is stone.


Given Boris' arguments, Big Marketshare can simply always mess up his 
project and blame me and it's my fault. I don't accept it.
Boris is not saying customers are right, Boris is saying they do it, 
simply because it's easy o blame someone else.


Btw, If Big Marketshare is so powerful, why haven't we already fixed 
whatever thing he is monkey patching?

Because someone else may be using original functionality


This part of this discussion is not about whether someone can/cannot 
monkey-patch... It's always possible. It's about clarity what is and 
what is not public. And this clarity is not only for programmers but for 
runtime as well. It's quite easy to work 50k+ lines program code with 60 
3rd party controls when the edges are clear (and you do not even need to 
use use 3rd party controls). The overhead you have to go through, either 
you alone or in team, not to mess something completely independent in 
big project just because missing isolation is quite huge.




>> Can we go with options when creating Shadow dom?

My understanding is that we have this option and are only talking 
about what would be the default.


Well if there is/will be such option (I cannot find it in Shadow DOM 
spec), I'm fine either way, but I do understand that we will probably 
have to go with less strict option as default. But frankly it will not 
solve e.g. Google Feedback issue if someone (like me) will opt for total 
isolation. Or we need to make more granularity (total, read/write {thou 
it's like a normal dom}, read-only, whatever), but regardless of apps 
like GF, the total one is important step I think we need to do.



B.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 25.2.2013 19:15, Scott Miles wrote:

I agree with Tab 100% on this.

You cannot accidentally stumble into ShadowDOM. You have to actively 
take that step.
Sure, someone can actively take step to access my shadow DOM, thou I 
explicitly made it shadow and in next version of the control things will 
break.




For one thing, I suggest that most of the time, the component code is 
shipping w/your application, you are not depending on some resource 
that will simply be upgraded out from under you.
Sure, but as a desktop programmer I cannot tell how many times over the 
last decade I have upgraded my applications including 3rd party 
controls... And all I have to do is to check the points whee my app 
touches the controls... Not caring about the rest, because the rest 
cannot be broken (well, can, under extreme circumstances)




For another thing, if I decide it's necessary to monkey-patch some 
third-party code that's I'm using in my application, I'm generally 
pretty upset if that code is privatized. It makes that unpleasant work 
much harder. I need to ship ASAP, and maintenance concerns are secondary.
Assuming of course you can legally do that... privacy of 3rd party 
control has nothing to do with monkey-patchif you have the code... sure 
you cannot do that from outside of the control, but that makes no 
difference (the problem with private clause is inheritance, protected is 
better choice)


I suppose there is a moral hazard argument: if we make it possible, 
people will overdo it. This is probably true, but IMO it's akin to 
saying chefs should only use butter knives because they could cut 
themselves on the sharp kind.
Again, do we have to go with one choice here? Either or? Can we go with 
options when creating Shadow dom?




Lastly, only a subset of possible upgrades actually are transparent, 
not affecting public API or behavior. Intersect that set of updates 
with monkey-patchers who can't live without the update, and you are 
talking about a relatively small affected class.

Well.. yours upgrades maybe...


Scott



B.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 25.2.2013 18:38, Tab Atkins Jr. wrote:

On Mon, Feb 25, 2013 at 6:21 AM, Boris Zbarsky  wrote:

On 2/25/13 12:11 AM, Tab Atkins Jr. wrote:

We've gone back and forth.  It seems that allowing monkeypatching by
default is the better choice, as most uses aren't security conscious

Tab, could you please read and respond to what Blake actually wrote?  He
didn't mention the word "security" at all.

True, but that's often something that comes up.  Sorry for implying
that was the only concern Blake had.

Still, though, the "private by default" impulse is nearly always
wrong, and contrary to a lot of patterns on the web.  As I alluded to,
and Elliot explicitly said in the 2012 email that Bronislav quotes,
the current status quo, where shadow DOM is hidden from everything
unless you're explicitly looking for it, is necessary for *lots* of
useful and completely benign things.  Because of this, hiding the
shadow is *not* something that's obviously good, and I argue that it
should rarely be necessary in the first place.

If you want high integrity (not security - this is a much broader
concept), it's expensive.  This is always true, because low-integrity
things are *useful*, and people often try to reach for high-integrity
without thinking through its downsides.

~TJ



My opinion of course... but you wrong on so many levels... I'm 
originally desktop applications programmer (still doing some), and 
private by default is the best policy (actually it's protected, but 
there's no such concept in HTML and no such thing in JS yet), it is 
contrary to lot of patters on web (given JS and DOM sharing space over 
all document regardless of origin), but this is serious flaw of the 
design, not a pro, it's con.


Sure I can say "please not change the internals of that DOM it may 
change in the future, do not count on existence of some node in that 
DOM, it may change in the future" but again, what is the point of Shadow 
than?


Yes, high integrity is expensive, so what? That is not an argument at 
all. It's a choice... do I need it? I'll use Shadow DOM, is it pointless 
for the result? I will not use it... We are not making anything 
mandatory. Shadow DOM is the way hi to create actual blackbox 
control/component/widget as it's normal and beneficiary in other languages.


"This is always true, because low-integrity things are *useful*, and 
people often try to reach for high-integrity without thinking through 
its downsides." Generalization excusing poor decisions of programmers? 
How about those, who can make good one?



But to argue your original point: keeping the smallest amount of point 
application can connect to control/component/widget blackbox is the best 
way how to ensure continuous, long time, functionality without breaking 
everything else. Because you are keeping the boundaries sharp.  When you 
have e.g. Delhi control, you know the contract between the original 
author and you. Having HTML+JS+CSS mess you know nothing at all.


I do recognize the history of the web, and I'm fine with making access 
policy to Shadow DOM more granular as long as I'm able to actually say 
"I do not want you to see anything other that I choose to expose in any 
way".




B.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

  
  

On 25.2.2013 18:33, Tab Atkins Jr.
  wrote:


  On Mon, Feb 25, 2013 at 7:53 AM, Bronislav Klučka
 wrote:

  
I'd like to second that, shadow DOM is explicitly designed not to be
accessible from outside, to stay consistent, to be sure that nothing gets
broken by altering the internals of Shadow DOM control/widget. I'd like to
be able to create controls in the future and give those controls to users to
place them anywhere. I do not want to hear "our site is broken, because
something else on our page was checking if there's a DIV there and you
changed it to SECTION, you suck!", internals of the controls should stay
internals of the control. You are effectively crippling half of the
advantage of Shadow DOM: the ability do whatever I want to do inside the
control as long as I expose the same API between versions.

  
  
If a script is explicitly looking inside the shadows of unknown
controls and checking their contents (and then failing when the
unknown control has different contents than whatever it expected),
something is *messed up* with that script.

You don't just accidentally see the insides of shadows.  All the
traditional movement and search APIs skip them.  I don't think this is
a realistic fear (not to say it won't happen somewhere, sometime - the
web is big, and people tile the possibility space, including all the
bad ideas).


No, I did not mean bug in browser, I ment making shadow traversable
so shadow internals can be reached from outside... and someone can
be counting on it.


  


  
So if this is going to be breached, there should be a way for control
authors to decide, whether they want to opt for this traversing or not...

  
  
There is.

~TJ



-- 
      
  
    s pozdravem
 Bronislav Klučka




http://www.bauglir.com
bronislav.klu...@bauglir.com

  * webové aplikace
  * software na zakázku


  

  

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 22.2.2013 3:33, Blake Kaplan wrote:

Hello everybody,

I'm coming into this conversation late, but wanted to add my thoughts.

As has been pointed out in this thread, the web has traditionally been
very open and malleable. JavaScript has very few readonly properties,
doesn't generally throw exceptions instead guessing or returning bogus
values. Making shadow trees hidden clearly goes against this idiom
and, by definition, limits what pages will be able to do with external
libraries built using shadow DOMs.

Even given this downside, though, I think that it's a mistake to make
shadow trees accessible to the bound document by default. One of the
most important features for frameworks is the ability to provide an
encapsulated API. Without that, it becomes extremely difficult to fix
bugs or add features to the framework without risking breaking
downstream clients. Shadow DOMs are one of a host of features being
designed and implemented that make HTML + CSS + JavaScript usable for
programming in the wild and it feels like an oversight to make the
default imitate the bad ol' days of monkey patching and low to no
encapsulation.

Finally, reading through the thread, it seems like one of the main
use-cases for open-by-default is features like Google Feedback. From
my point of view, it seems like features like that need to be
considered from the beginning of a site's design. So if a site wants
to have something like GF and also use web components and shadow DOMs,
then the designers of the components should have to explicitly set the
bit that says "let other people poke at my internals." I don't think
that this one use-case needs to trump the good programming practices
of every other library.
--
Blake Kaplan


I'd like to second that, shadow DOM is explicitly designed not to be 
accessible from outside, to stay consistent, to be sure that nothing 
gets broken by altering the internals of Shadow DOM control/widget. I'd 
like to be able to create controls in the future and give those controls 
to users to place them anywhere. I do not want to hear "our site is 
broken, because something else on our page was checking if there's a DIV 
there and you changed it to SECTION, you suck!", internals of the 
controls should stay internals of the control. You are effectively 
crippling half of the advantage of Shadow DOM: the ability do whatever I 
want to do inside the control as long as I expose the same API between 
versions.


So if this is going to be breached, there should be a way for control 
authors to decide, whether they want to opt for this traversing or not...



BTW looking at mail
From: Elliott Sprehn 
Date: Thu, 8 Nov 2012 01:45:16 -0800
Traversable shadows are a requirement for a number of things like:
- Generic page level libraries and polyfills that need to transform DOM
nodes
- Generic event handling libraries (ex. Pointer events)
- Creating screenshots of the page by rendering every node to a canvas (ex.
Google Feedback)
- Creating awesome bookmarklets like Readability

Maybe I'm coming too late to this discussion, but how did everyone 
missed those first 2 points? Is this actually a suggestion that 
someone/something should be able not only read my DOM but alter it as 
well? So what is the point of Shadow DOM then?





B.

Re: File Save As

[Bronislav Klučka]

On 6.1.2013 8:22, Florian Bösch wrote:
On Sun, Jan 6, 2013 at 1:33 AM, Boris Zbarsky > wrote:


This, I agree is a problem.

The semantic used by countless applications and which is an extremely 
well established UX pattern is:


- First "Save" -> Open Save As dialog
- Subsequent "Save" -> overwrite previous location
- Any "Save As" -> Always opens a Save As dialog

Lacking this is not a dealbreaker, but it unpleasantly departs from 
known functionality and makes things that little more inconvenient for 
the user and keeps reminding him he's using a webapp.




Yes, this is application/UI/UX issue, from programmers' point of view, 
it's up to me, whether I decide to give user the possibility to choose 
file (path) or whether I siply open some kind of file stream somewhere 
and write into it. But that is not possible for web apps due to 
security. But this could be a way for JS API. Give blob/file/stream both 
functions and the first call of either save or saveAs on such object 
would always trigger Save As dialog, subsequent call to save() would 
only flush data on disc, while saveAs() would trigger the dialog again, 
write to new file and assign new file name for subsequent save() calls. 
Unless I missed something, Blobs/Files cannot be changed once created, 
but this could & should work for streams at least (because always 
forcing user to select the same file over and over again is poor 
design... application already has been granted acces to certain file).
BTW it would be great if application could get some persistent disc file 
URN and persistent priveleges to it (if user select file once, 
application would be able to asses such file always (in next session) 
without user having to select it once again, the same for writing), so 
application would only remember files URN (IndexDB, LocalStorage, 
whatever) and access it anytime later. Origin based of course.



Brona

Re: File Save As

[Bronislav Klučka]

On 6.1.2013 0:51, Jonas Sicking wrote:

3. What should the UI in the browser look like in order to communicate
to the user that this is different from the 
file-picker which only allows reading.



Well generally OS do have dialogs for Open and Save As, users use those 
allhe time in applications (browser included, when downloading content) 
so what is the problem here?


Or do you mean UI within the page? The actual input rendered on the 
page? First of all, do we need one? One thing is to have input for 
reading file, as a part of form, file (file content) as one property of 
a form, this have been working for web rot 2 decades, desktop 
application works the same way. But why special input here? Why this 
cannot be JS API only trigger by click/whatever?


BTW current input file is an exaple of poor design... the thole thing is 
unstylable, if your application has certain look and feel, this thing 
sticks up like sore thumb and you probably end up with stylable regular 
button and crete fileinput on demand with JS a calling .click() in JS as 
well.


Brona

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

[Bronislav Klučka]

On 22.8.2012 1:13, Tab Atkins Jr. wrote:

On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard  wrote:

FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say "#myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; }" or "a { rel:
noreferrer; }" would be great.

Having it not apply changes dynamically seems weird, since it looks and
feels like CSS.  It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:

var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = "foo"; // and we override them

var div = createMyDiv();
div.className = "foo"; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten

Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, "document.documentElement.appendChild(parentNode)"
happens before or after.

Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously.  As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).

~TJ

Which does not correspond to CSS behavior and may be cofusing, any 
changes would require something like


var div = createMyDiv();
parentNode.appendChild(div);
setTimeout(function(div) {div.className = 'foo';}, 0, div);
that's weird.

How about this: element is created with all attributes marked as clean, 
any settings (input.value = 5; input.setAttribute('value', 5); delete 
input.value; input.removeAttribute('value')) would mark such property as 
dirty, and inserting new element into DOM would trigger task, that would 
set up all properties based on DOM document's CAS except dirty ones. In 
such case, no ambiguity would occure.


Browsers are able to do it for CSS, should be able to do it for CAS

Brona.




--

s pozdravem
 Bronislav Klučka


http://www.bauglir.com <http://www.bauglir.com>

http://www.bauglir.com
bronislav.klu...@bauglir.com  <mailto:bronislav.klu...@bauglir.com>

  * webové aplikace
  * software na zakázku

Re: [Workers] Worker same-origin and usage in JS libraries...

[Bronislav Klučka]

On 18.7.2012 1:05, Ian Hickson wrote:

And if you want it to be defined in JS file itself, I'll suggest "use
strict" approach:

file> ---
"Access-Control-Allow-Origin: *";
(function(){
 "use strict";
   var x = 5;
})();
---
Whether it's a string or a comment seems like a detail. If we do do this,
I expect we'll find something that's somewhat language-agnostic (e.g.
allowing any leading and trailing punctuation on the first line, or
something to that effect).

Well not exactly a detail... we already have comment processing in HTML 
and JS... (IE). Script minifiers can have issues with that, JS engines 
would have to start parse end somehow execute comments to look for 
something suspicious in a text without recognizable syntax and semantics 
(garbage)
Maybe some specific object, as a property on window / worker scope would 
be inline with language and requiremenets (=to define script properties)

(this|self).ScriptProperties = {
   DisableCrossOriginExecution = false, //to disable CO script sharing, 
since current default is true
   AllowCrossOriginWorkerExecution = true //to enable CO in workers, 
since current default is false

}

it would also allow any future extensions

BK

Re: [Workers] Worker same-origin and usage in JS libraries...

[Bronislav Klučka]

  
  

On 17.7.2012 23:53, Ian Hickson wrote:


  My plan is to make it so that cross-origin URLs start cross-origin
  workers. The main unresolved question is how to do this in an
  opt-in manner. The best idea I've come up with so far is having
  scripts that want to opt-in to being run in such a way start with
  a line line: // Cross-Origin Worker for: http://example.net
  ...or (for multiple domains): // Cross-Origin Worker for:
  http://example.com https://example.org
  ...or (for any domain): // Cross-Origin Worker for all origins
  ...but that doesn't seem super neat.


Since script is loaded using HTTP, why not use already defined CORS
headers on server side while serving those scripts?
And if you want it to be defined in JS file itself, I'll suggest
"use strict" approach:

file>
---
"Access-Control-Allow-Origin: *";
(function(){
    "use strict";
  var x = 5;
})();
---

and define CORS headers as a string (maybe with the restriction that
those headers must be first executable/runnable code in JS file - so
there may be comments and whitespaces before)

B.

    -- 
  
  
s pozdravem
 Bronislav Klučka




http://www.bauglir.com
bronislav.klu...@bauglir.com

  * webové aplikace
  * software na zakázku


  



  

Re: Working with FormData as an object

[Bronislav Klučka]

On 14.5.2012 14:37, Anne van Kesteren wrote:

On Mon, May 14, 2012 at 2:00 PM, Anne van Kesteren  wrote:

http://wiki.whatwg.org/wiki/FormData has some ideas on how we could
update FormData, XMLHttpRequest, and HTMLFormElement to address the
various use cases presented thus far. Feedback welcome.

The one potentially problematic thing is exposing Blob passed to
FormData as File since they always have a filename. This might give
you distinct references to the underlying system file object. I'm not
sure if that is problematic. If it is problematic, I am not sure how
to keep the FormData API simple. I guess we should then introduce
FormEntry objects and change the API proposal to work with those.



Hi,
before I start, it may not seem connected to it, but I'll get there :)
0/ toJSON method of Blob should be implemented (see 
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf JSON.stringify, 
page 205, if anyone does not know). To create string representation of 
Blob or File, such object would expose all public properties (size, 
type, name, etc.) and content (either binary string ot data url).
WebKit (or Chromium, I'm not sure), actually implements something, 
JSON.stringify on file dropped displayes:

{"type":"image/png","name":"bauglir.png","webkitRelativePath":"","lastModifiedDate":"2011-06-01T14:44:18.000Z","size":7968}
but no data... no good
The question is whether this should not be async (but that would require 
alteration of ECMA method).


to FormData issue:
1/ we can go with something like
object toObject(boolean includeBlobs)
void fromObject(object Data, boolean include Blobs)

I hope the names are clear (I do not case about actual names, those are 
for being obvious). those methods would work as I described in 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0366.html
and they would either include or exclude working with blobs in either 
FormData (toObject) or object(fromObject) .
and if working with blob: append in form data 
(http://www.w3.org/TR/XMLHttpRequest2/#interface-formdata) has 3rd 
parameter form file, so internally this name must be stored somewhere 
before sending, so toObject can use it to determine, that such blob is 
actually a File and expose it as File (i do not know about 
lastModifiedData, but I do not care that much at this point). And 
fromObject can determine, whether blob value is Blob of File and use it 
to internally call append with appropriate parameters


2/ we can go with
string _toString(boolean includeBlobs) //or probably better name
void fromString(string someJSON, boolean include Blobs)
to do the same, but wirk with string representation (JSON),
and there is where i get to my 0/, stringification of Blob, because 
sure, we can go with 1/, I can get an object, and call JSON.stringify, 
but if such object would contain binary data, I'm lost, I cannot store 
it (or maybe IndexDB could be able, but that very limiting). And I would 
have to go through such object with some recursion and parse it on my own.



All those functions may need to be async (have a callback parameter to 
actually return data or signal end of parsing [one way or the other]), 
because of possible Blobs.


Brona

Re: File constructor

[Bronislav Klučka]

On 11.5.2012 18:59, Alfonso Martínez de Lizarrondo wrote:
Almost a year ago there was a thread about this issue (ability to set 
the filename for a Blob) :

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1342.html


2012/5/11 Bronislav Klučka <mailto:bronislav.klu...@bauglir.com>>


Hi,
currently File object cannot be constructed, only Blob can.
I'm currently implementing XHR blob upload, that blob can either
be File (selected by user) or programatically created Blob.
On server side :
1/ In case of File, I get file name as part of the file metadata
(name, size, type, etc)
2/ In case of Blob, I cannot specify name and I have to send it as
additional parameter and ignore name metadata

sending multiple files/blobs at once can be a mess

is there a reason, while File cannot be created? It is Blob with
has name and lastModifyDate .
http://dev.w3.org/2006/webapi/FileAPI/#file

Could there be File constructor, that would work as Blob
constructor with 3rd parameter specifying the name of the file and
lastModifiedDate set to creation date

Brona Klucka



I see... there seems to be some consensus, but it probably died on 
little actual interest.


Going through the ideas there, we could amend Jonas'es idea ad consider 
something like


var file = blob.getFile(DOMString filename, optional DomString contentType);

to actually get a File object (since we are moving away from BlobBuilder)


Brona Klucka

File constructor

[Bronislav Klučka]

Hi,
currently File object cannot be constructed, only Blob can.
I'm currently implementing XHR blob upload, that blob can either be File 
(selected by user) or programatically created Blob.

On server side :
1/ In case of File, I get file name as part of the file metadata (name, 
size, type, etc)
2/ In case of Blob, I cannot specify name and I have to send it as 
additional parameter and ignore name metadata


sending multiple files/blobs at once can be a mess

is there a reason, while File cannot be created? It is Blob with has 
name and lastModifyDate .

http://dev.w3.org/2006/webapi/FileAPI/#file

Could there be File constructor, that would work as Blob constructor 
with 3rd parameter specifying the name of the file and lastModifiedDate 
set to creation date


Brona Klucka

Re: Working with FormData as an object [Was: Request for FormData.remove() method]

[Bronislav Klučka]

On 11.5.2012 11:40, Odin Hørthe Omdal wrote:
On Thu, 26 Apr 2012 17:43:24 +0200, Bronislav Klučka 
 wrote:
So the ability to somehow work with FormData as an object (al least 
get object out of it, or create it based on object) and the ability 
to get FormData from form (that we have) and fill form based on 
FormData (that's missing) would be huge time saver


I agree with this.

I remembered this thread when I read Hixies outburst on #whatwg 
yesterday:


[10:29]  we really still have no way for JS to access the 
form data set on submission?

[10:30]  who's running this show, a clown?

  src: http://krijnhoetmer.nl/irc-logs/whatwg/20120510#l-483


It seems we're many who want this, and there are clear use cases for it.

  http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0366.html


FormData need not be tied to XHR either, maybe IndexedDB should also 
be able to just take FormData directly?  I can see how that could be 
useful.  Although getting methods for serializing/deserializing 
FormData would make it possible to just do the load/save logic on your 
own.





FormData can be left tight to XHR, serializing/deserializing should be 
enough (actually as long as we are able to manipulate FormData, there is 
almost no difference). The only question is, how to 
serialize/deserialize Blob.


Brona

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

[Bronislav Klučka]

On 2.5.2012 19:07, Ryosuke Niwa wrote:
On Wed, May 2, 2012 at 9:44 AM, Bronislav Klučka 
mailto:bronislav.klu...@bauglir.com>> 
wrote:


On 2.5.2012 18:15, Ryosuke Niwa wrote:

On Wed, May 2, 2012 at 8:55 AM, Bronislav Klučka
mailto:bronislav.klu...@bauglir.com>> wrote:

Bear with me...
Delphi (Object Pascal) Visual Component Library has concept
of Actions, some Actions can be assigned to Controls (those
would be here menu/contextmenu items of the browser, would be
great to be able to assign such Action (or some inherited
object) to my own ), one Action can be assigned to
unlimited number of controls. Action has 2 important
methods/events (either overriding the method or listening to
the event default method triggers). First one is Execute,
that is called, when Control default activation happens
(click/enter on button, click on menu item), which helps to
utilize functionality for several controls in one place
(essentially one event handler function, we can do that of
course in JS..)
The important thing is, Action also has Update method
(OnUpdate event), that is called every time application gets
to idle state (application receive message (system message
like click, paint, keydown, whatever), application processes
this message and any subsequent messages if any new are in
the queue and goes to idle). And in that idle state
application goes through all the Actions in the application
and calls Update method and then the Action can decide,
whether is enabled or not. And all Controls with this Action
assigned would change this property as well

 I could express it in JS as
var deleteUserAction = new Action();

deleteUserAction.addEventHandler('execute', function()
{
 //some code to delete all selected users
});

deleteUserAction.addEventHandler('update', function()
{
 this.enabled = (myList.selectedUsers.length > 1) &&
havingRightsToDeleteUsers;
});
mainMenuItemDelete.action = deleteUserAction;
contextMenuItemDelete.action = deleteUserAction;
toolbarButtonDelete.action = deleteUserAction;

So the update handler allows you not to care about how many
controls should you disable/enable, just assign this action
to any control, in this action handler set up enabled to this
action and all controls are updated. So except the assignment
of Action to Control, no additional work needed. And the
concept of calling the update method guarantees, the UI is up
to date (user is doing something, messages are queued and
processed, the second there is time, all actions are
updated). Since it is in idle state, programmer does not have
to care when and how to set up all controls.
Action also has e.g. caption, image, etc. when updated again,
all assigned controls are updated to have the same caption,
image, etc...

I'm currently trying to implement this in my web application
(would be handy to have idle event), because it would
simplify UI management on programmers level, but something
like this could help to update browser's UI as well.


This is why I've suggested to tie command elements to execCommand
in
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1232.html
to be used as a state machine.

Basically yes... self updatable state machine (that "self" part is
extremely important to me), but if doing so, it would be great not
to bing it some specific feature (Editing API, browser UI), but
make it more generic = usable.


But scripts can already do that if they don't need / want to 
communicate any intents with the browser; e.g. you're implementing it 
for your web app.


- Ryosuke



Hi,
Scripts can update controls, of course, but the question is (that is 
discussed here, that is handled by Delphi's Idle state) when to do that...


B.

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

[Bronislav Klučka]

  
  


On 2.5.2012 18:15, Ryosuke Niwa wrote:

  On Wed, May 2, 2012 at 8:55 AM, Bronislav Klučka <bronislav.klu...@bauglir.com>
wrote:
  

  Bear with me...
  Delphi (Object Pascal) Visual Component Library has concept of
  Actions, some Actions can be assigned to Controls (those would
  be here menu/contextmenu items of the browser, would be great
  to be able to assign such Action (or some inherited object) to
  my own ), one Action can be assigned to
  unlimited number of controls. Action has 2 important
  methods/events (either overriding the method or listening to
  the event default method triggers). First one is Execute, that
  is called, when Control default activation happens
  (click/enter on button, click on menu item), which helps to
  utilize functionality for several controls in one place
  (essentially one event handler function, we can do that of
  course in JS..)
  The important thing is, Action also has Update method
  (OnUpdate event), that is called every time application gets
  to idle state (application receive message (system message
  like click, paint, keydown, whatever), application processes
  this message and any subsequent messages if any new are in the
  queue and goes to idle). And in that idle state application
  goes through all the Actions in the application and calls
  Update method and then the Action can decide, whether is
  enabled or not. And all Controls with this Action assigned
  would change this property as well
  
   I could express it in JS as
  var deleteUserAction = new Action();
  
  deleteUserAction.addEventHandler('execute', function()
  {
   //some code to delete all selected users
  });
  
  deleteUserAction.addEventHandler('update', function()
  {
   this.enabled = (myList.selectedUsers.length > 1)
  && havingRightsToDeleteUsers;
  });
  mainMenuItemDelete.action = "">
  contextMenuItemDelete.action = "">
  toolbarButtonDelete.action = "">
  
  So the update handler allows you not to care about how many
  controls should you disable/enable, just assign this action to
  any control, in this action handler set up enabled to this
  action and all controls are updated. So except the assignment
  of Action to Control, no additional work needed. And the
  concept of calling the update method guarantees, the UI is up
  to date (user is doing something, messages are queued and
  processed, the second there is time, all actions are updated).
  Since it is in idle state, programmer does not have to care
  when and how to set up all controls.
  Action also has e.g. caption, image, etc. when updated again,
  all assigned controls are updated to have the same caption,
  image, etc...
  
  I'm currently trying to implement this in my web application
  (would be handy to have idle event), because it would simplify
  UI management on programmers level, but something like this
  could help to update browser's UI as well.



This is why I've suggested to tie command elements to
  execCommand in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1232.html
  to be used as a state machine.


- Ryosuke


  


Basically yes... self updatable state machine (that "self" part is
extremely important to me), but if doing so, it would be great not
to bing it some specific feature (Editing API, browser UI), but make
it more generic = usable.

B.
  

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

[Bronislav Klučka]

On 2.5.2012 15:57, Boris Zbarsky wrote:

On 5/2/12 2:23 AM, Aryeh Gregor wrote:

For the former, I'd suggest onbeforecontextmenu, with some way to
disable specific options


I would think that disabling cut/copy/paste would apply to main menus 
too, not just context menus.  Most people I know who use menus for 
this (which is precious few, btw, for the most part people I know seem 
to use keyboard shortcuts for cut/copy/paste) use the main menu, not 
the context menu...


One question is whether this use case (which I agree seems worth 
addressing) requires a new event.  That is, is it better for the 
browser to fire events every time a menu is opened, or is it better 
for apps that want to maintain state like this to update some property 
on the editable area whenever their state changes and for browsers to 
just read those properties when opening a menu?


The latter is, from my point of view as a browser implementor, 
somewhat simpler to deal with, since it doesn't involve having to 
worry about alert() or sync XHR or window.close() in menu-opening 
code.  But I can see that it might be more complicated to author 
against...


-Boris


Bear with me...
Delphi (Object Pascal) Visual Component Library has concept of Actions, 
some Actions can be assigned to Controls (those would be here 
menu/contextmenu items of the browser, would be great to be able to 
assign such Action (or some inherited object) to my own ), one 
Action can be assigned to unlimited number of controls. Action has 2 
important methods/events (either overriding the method or listening to 
the event default method triggers). First one is Execute, that is 
called, when Control default activation happens (click/enter on button, 
click on menu item), which helps to utilize functionality for several 
controls in one place (essentially one event handler function, we can do 
that of course in JS..)
The important thing is, Action also has Update method (OnUpdate event), 
that is called every time application gets to idle state (application 
receive message (system message like click, paint, keydown, whatever), 
application processes this message and any subsequent messages if any 
new are in the queue and goes to idle). And in that idle state 
application goes through all the Actions in the application and calls 
Update method and then the Action can decide, whether is enabled or not. 
And all Controls with this Action assigned would change this property as 
well


 I could express it in JS as
var deleteUserAction = new Action();

deleteUserAction.addEventHandler('execute', function()
{
  //some code to delete all selected users
});

deleteUserAction.addEventHandler('update', function()
{
  this.enabled = (myList.selectedUsers.length > 1) && 
havingRightsToDeleteUsers;

});
mainMenuItemDelete.action = deleteUserAction;
contextMenuItemDelete.action = deleteUserAction;
toolbarButtonDelete.action = deleteUserAction;

So the update handler allows you not to care about how many controls 
should you disable/enable, just assign this action to any control, in 
this action handler set up enabled to this action and all controls are 
updated. So except the assignment of Action to Control, no additional 
work needed. And the concept of calling the update method guarantees, 
the UI is up to date (user is doing something, messages are queued and 
processed, the second there is time, all actions are updated). Since it 
is in idle state, programmer does not have to care when and how to set 
up all controls.
Action also has e.g. caption, image, etc. when updated again, all 
assigned controls are updated to have the same caption, image, etc...


I'm currently trying to implement this in my web application (would be 
handy to have idle event), because it would simplify UI management on 
programmers level, but something like this could help to update 
browser's UI as well.


Brona

Re: Request for FormData.remove() method

[Bronislav Klučka]

On 26.4.2012 16:15, Anne van Kesteren wrote:
On Thu, 26 Apr 2012 15:29:44 +0200, Bronislav Klučka 
 wrote:

On 26.4.2012 13:55, Anne van Kesteren wrote:

Why would you not simply use a JavaScript object for this?


Of course you want to use JS object for this in case of storing in 
e.g. IDB... the point is, how do you create this object? No, you have 
to reimplement FormData construction, instead of using it.


So the reason you want FormData is not because of FormData, it's 
because FormData has a hook into HTML's "constructing the form data set".


Not really sure what would be the best solution here.



Hi,
actually what would be the best
1/ be able to get FormData from  and then be able to get JS object 
from it
2/ and the vice versa, create FormData (either value by value or from 
object) and assign it to  and let the form be filled


I've already encounter both scenarios... If you imagine e.g. users form 
(name, surname, gender, age , address, interests) and the form behind it,








you can imagine that saving it on server can be easy, you create 
FormData and send it... on the other side, you get an object, something like

{
  name: "Brona",
  gender: "male",
  address: {
 street: "B. Smetany",
 country: "cz"
  },
  "interest": [IT, music]
}

but do that in JS itself, is pain, you need to go through all fields, 
validate them (is it valid data? is it not disabled? if text, then get 
value; if radio check for checked and then get value; if multiple 
select...), parse the name, whether it is just field (name), or field 
within object (address[street]), or array(interest[]) or something more 
complex (data[][field][]). At least the task before parsing name is done 
in FormData, even be able to get to those data would be saving of time 
(getting JSON out of it, or object would be even better).


And on the other side, lets say you get JSON/Object representing user 
from server and you need to fill the form back... you need to go 
recursively through  the object and identify the corresponding form 
element.. Why not just fill up FormData and assign them to form? (You 
may also have an object itself, just object, and you may want it to send 
to server... just filling up FormData with that object... without again 
traversing through it..)


So the ability to somehow work with FormData as an object (al least get 
object out of it, or create it based on object) and the ability to get 
FormData from form (that we have) and fill form based on FormData 
(that's missing) would be huge time saver



Brona

Re: Request for FormData.remove() method

[Bronislav Klučka]

On 26.4.2012 13:55, Anne van Kesteren wrote:
On Wed, 18 Apr 2012 20:07:57 +0200, Bronislav Klučka 
 wrote:
FormData can be useful not only to be sent via XHR, but essentially 
to hold form values easily, e.g. you can have settings form (that you 
do not need to send any where = you do not need to store it or you 
store it in e.g. IndexDb), then get this settings and alter 
application according to this settings... Instead of doing exactly 
the same, but manually


Why would you not simply use a JavaScript object for this?


Of course you want to use JS object for this in case of storing in e.g. 
IDB... the point is, how do you create this object? No, you have to 
reimplement FormData construction, instead of using it.


B.

Re: Request for FormData.remove() method

[Bronislav Klučka]

On 18.4.2012 6:50, David Sickmiller wrote:

Hi,

I must admit I am ignorant of the W3C process for drafting the 
XMLHttpRequest, but I see that the webpage says to send feedback to 
this address, so I am writing this email to submit my feedback.


The "new FormData(form)" constructor is an especially handy way to 
slurp in all the data for a given form.  As the documentation 
describes, the algorithm for constructing the form data set is quite 
intricate -- it takes 3 pages to describe.


I have an application where I need to change or remove field values 
that were received from the user, before they are submitted using an 
XHR.  (I'm removing cue text from text input fields.)  It would be 
ideal to call some sort of FormData.remove() (or perhaps 
"removeAllByName") method.  Unfortunately, no function like that is 
defined in the FormData interface.  The most obvious alternative is to 
re-implement the 3-page algorithm to construct the form data set, and 
then add my application-specific twist.  That's not a simple task to 
get perfect.
Agreed, being able to work with FormData as an object (setters, getters, 
deleters) would be improvement... so far we only have setters


any get(DOMString name)
method to retrieve FormData value

DOMString name(number index)
to get FormData name at particular index (function could return empty 
string if there is no name at that index),

var i = 0;
while (name = formData.name(i++)) { doSomething(formData.get(name)); }

or maybe even count property to get the number of names

FormData can be useful not only to be sent via XHR, but essentially to 
hold form values easily, e.g. you can have settings form (that you do 
not need to send any where = you do not need to store it or you store it 
in e.g. IndexDb), then get this settings and alter application according 
to this settings... Instead of doing exactly the same, but manually


Brona

Re: File API "oneTimeOnly" is too poorly defined

[Bronislav Klučka]

On 30.3.2012 15:21, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka <mailto:bronislav.klu...@bauglir.com>>


If I understand you, you find it problematic that by using weak
ref, URL would for some time reference actual Blob and other time
it would not?


The problem is that the following code might or might not work, 
depending on the behavior of the browser's GC:


url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);

If the timer executes before GC collects the blob, this works, because 
the URL is still valid.  Otherwise, it fails, because--since the Blob 
no longer exists--the URL is no longer valid.


--
Glenn Maynard



That should not be problematic; yes, GC may actually free that blob 
allocated memory later than that timeout function triggers, but there is 
explicit release of that blob (blob = null), so this must fail (memory 
might be allocated by blob data, but that variable should be out). But 
following may cause the same issue


var url = createObjectUrl(new Blob(['hello']));
setTimeout(function() { img.src = url; }, 0);

and even this in some aggressive GC implementation

img.src = createObjectUrl(new Blob(['hello']));
//since nothing references this blob, it could be destroyed right after 
function ends, but before assigning result,
// thou GC works most likely in some application idle state not to delay 
application process, theoretically this
// applies as well, since the functionality of GS is not specified = 
implementation specific


Thou I could live with such issue, I see the problem (from others 
programmers perspective and from specification perspective)... there's 
no light at the end of this tunnel...
Either carefully treat weak refs, or have one time ULRs with 
dereferencing and concurrency issues, or explicit URL release one might 
forget..


Brona

Re: File API "oneTimeOnly" is too poorly defined

[Bronislav Klučka]

On 30.3.2012 5:54, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka <mailto:bronislav.klu...@bauglir.com>>


The point was not to talk about weak refs, but about not creating
a GC reference from URL to Blob


If the lifetime of the URL is tied to the lifetime of the Blob, then 
that's what a weak reference *is*.


--
Glenn Maynard



If I understand you, you find it problematic that by using weak ref, URL 
would for some time reference actual Blob and other time it would not?


Brona Klucka

Re: File API "oneTimeOnly" is too poorly defined

[Bronislav Klučka]

On 30.3.2012 5:40, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka <mailto:bronislav.klu...@bauglir.com>>


Sure, weak referencing is probably not well explored approach, but
the underlying idea applied to blob is interesting: URL creates no
reference to Blob (from GC perspective), meaning Blob is subjected
to GC regardless of BlobUrl existence. This would remove the need
for revoking URL, programmers would only need to maintain blobs
they want to be persistent (e.g. in some global array).


Weak referencing is pretty well explored, I think.  It's intentionally 
not supported for the most part in JavaScript, because most weakref 
features expose garbage collection behavior to scripts.  Web APIs 
don't do that.


This approach exposes GC behavior, making it possible to write code 
that behaves differently depending on GC.


--
Glenn Maynard



The point was not to talk about weak refs, but about not creating a GC 
reference from URL to Blob


Brona

Re: File API "oneTimeOnly" is too poorly defined

[Bronislav Klučka]

On 30.3.2012 0:19, Glenn Maynard wrote:
On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher > wrote:


I've never been terribly happy with createObjectURL and the
requirement for
folks to remember to call revokeObjectURL.  I really like that
we're talking
about ways to minimize this pain :-)

I noticed the WeakRefs proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs


This exposes GC behavior, though.  They try to reduce that by making 
it only collectable during the event loop, but it's still observable.  
For example,


blob = createObjectURL();
blob = null;
setTimeout(function() { img.src = blob; }, 0);
return;

might or might not succeed.

(IIRC, WeakMaps avoid GC exposure by being non-enumerable.  That seems 
to make them not very useful, since it's hardly different from simply 
assigning properties to the object.)


On Thu, Mar 29, 2012 at 6:08 AM, Robert O'Callahan 
mailto:rob...@ocallahan.org>> wrote:


It might be a bit better to revoke the URL at the next stable
state. Microtask checkpoints can happen during synchronous script
execution.


I'm confused.  I'd never seen microtasks actually defined (only 
suggested), but I see it's just not defined in the page I was viewing. 
 It looks like Google's returning out of date spec links 
(http://www.whatwg.org/specs/web-apps/current-work/.w3c-html-core/webappapis.html#processing-model-2). 
 This is the second time I've been bit recently by landing on a weird, 
out-of-date spec URL (ignoring the /TR/ trap, which I know to watch 
out for)...


So, "microtask" isn't what we need here (and not what IndexedDB needs, 
either).  Stable state might be correct.  I think that has another 
effect, which you don't get by waiting for the event loop: blob URLs 
would also be freed between  execution.  That is, in