Re: Base Template (Was Re: Minimum viable custom elements)

2015-02-13 Thread Jan Miksovsky
Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts 
and needs for subclassing components.

Anne/Steve: I’d originally indicated that this technique couldn't be applied to 
extending native HTML elements. Since the two of your seemed interested in 
that, I spent some time tinkering with the idea, and it turns out that this 
technique can be made to work for that situation. I’ve posted a quick demo 
(http://janmiksovsky.github.io/base-template/extendButton.html 
http://janmiksovsky.github.io/base-template/extendButton.html) showing 
subclassing of a standard HTML button element. This works best under native 
Shadow DOM. Under polyfilled Shadow DOM, base class styles can’t (yet?) be 
inherited.

Anyway, I mention this in case it opens up some ideas. Thanks for the 
inspiration!

RE: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-13 Thread Travis Leithead
Marc,

I'd first mention that I am keenly interested in improving the state-of-the-art 
in DOM (I'm driving the project to update IE's 20-year-old DOM as my day job.) 
I've also done a lot of thinking about thread-safe DOM designs, and would be 
happy to chat with you more in depth about some ideas (perhaps off-list if 
you'd like).

I'd also refer you to a breakout session I held during last TPAC on a similar 
topic [1]. It had lots of interested folks in the room and I thought we had a 
really productive and interesting discussion (most of it captured in the IRC 
notes).

[1] https://www.w3.org/wiki/Improving_Parallelism_Page

-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu] 
Sent: Wednesday, February 11, 2015 12:34 PM
To: public-webapps@w3.org
Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous 
XMLHttpRequest

On 2/11/15 3:04 PM, Brendan Eich wrote:
 If you want multi-threaded DOM access, then again based on all that I 
 know about the three open source browser engines in the field, I do 
 not see any implementor taking the huge bug-risk and opportunity-cost 
 and
 (mainly) performance-regression hit of adding barriers and other 
 synchronization devices all over their DOM code. Only the Servo 
 project, which is all about safety with maximal hardware parallelism, 
 might get to the promised land you seek (even that's not clear yet).

A good start is defining terms.  What do we mean by multi-threaded DOM access?

If we mean concurrent access to the same DOM objects from both a window and a 
worker, or multiple workers, then I think that's a no-go in Servo as well, and 
not worth trying to design for: it would introduce a lot of spec and 
implementation complexity that I don't think is warranted by the use cases I've 
seen.

If we mean the much more modest have a DOM implementation available in 
workers then that might be viable.  Even _that_ is pretty hard to do in Gecko, 
at least, because there is various global state (caches of various sorts) that 
the DOM uses that would need to either move into TLS or become threadsafe in 
some form or something...  Again, various specs (mostly DOM and HTML) would 
need to be gone over very carefully to make sure they're not making assumptions 
about the availability of such global shared state.

 We should add lighter-weight workers and immutable data structures

I should note that even some things that could be immutable might involved a 
shared cache in current implementations (e.g. to speed up sequential indexed 
access into a child list implemented as a linked list)...  Obviously that sort 
of thing can be changed, but your bigger point that there is a lot of risk to 
doing that in existing implementations remains.

-Boris



RE: [clipboard API] platform integration stuff - in spec or out of scope?

2015-02-13 Thread Ben Peters
I agree with James. The reason to have it in the list is to have a normalized 
name for it (instead of worrying about platform specific clipboard types). As 
long as the browser isn’t required to handle it or prevented from handling it, 
it can included to make it both readable and writable by script. I haven’t seen 
vender pushback, but I haven’t been involved for as long as some.

From: James M. Greene [mailto:james.m.gre...@gmail.com]
Sent: Wednesday, February 11, 2015 6:59 PM
To: Hallvord Steen
Cc: public-webapps; Paul Libbrecht
Subject: Re: [clipboard API] platform integration stuff - in spec or out of 
scope?


Allow me to clarify my position.

My expectation is NOT for the browsers' default action on copy/cut to 
convert HTML into RTF. I do not see any such implication of that behavior in 
the spec language [1].

Rather, I just want to ensure that browsers will honor/maintain that clipboard 
format/segment if it is set during a custom copy event handler using the 
`event.clipboardData.setData` method. The current language of the spec [2] 
leaves the possibility open for an implementor to choose to ignore/discard any 
data formats that are not on the mandatory data types list [1], and I find that 
worrysome.

Is the problem that spec may be implying that the browser must know what to do 
with the data when PASTING from a clipboard segment associated with a mandatory 
data type? I could see that as more of a sticking point for implementors... but 
again, I really just want to ensure that the application/rtf clipboard 
segment is simply left intact bi-directionally. If the spec were to be updated 
to generally ensure that type of maintained/untouched transfer for data types 
that are NOT on the mandatory data types list (i.e. custom data types), then 
I would be fine leaving application/rtf OFF the mandatory data types list.

Can we get some clarification on the vendor pushback reasoning in this regard?

Thanks!

[1]: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types
[2]: 
http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard

Sincerely,
   James M. Greene
On Feb 11, 2015 3:15 PM, Hallvord Reiar Michaelsen Steen 
hst...@mozilla.commailto:hst...@mozilla.com wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene 
james.m.gre...@gmail.commailto:james.m.gre...@gmail.com wrote:
We never really came to a decision on if RTF (application/rtf) should be 
listed as a mandatory MIME type but the general consensus seemed to be leaning 
toward yes:
   https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html

There was some pushback from vendors - and I think their arguments were 
reasonable. Why should a web browser have to include code to generate RTF 
documents to write them to the clipboard? It's going to be a non-trivial amount 
of code, it will be rarely executed and could easily come with exploitable 
security vulnerabilities. It only makes sense to require this if there is a 
significant amount of software out there that supports pasting RTF data but 
does *NOT* support pasting HTML data - so that if we mandate support for 
writing HTML to the clipboard but leave RTF out, many users will have problems 
pasting text with formatting into another application. How many applications 
would have this issue on the various platforms? How widely are they used? Would 
users even expect to be able to preserve formatting on pasting into or copying 
from these applications?

A reply from you in the earlier discussion of these questions is here:
https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html

-Hallvord, wearing an invisible clipboard spec editor hat


Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-13 Thread Marc Fawzi
Travis,

That would be awesome.

I will go over that link and hopefully have starting points for the
discussion.

My day job actually allows me to dedicate time to experimentation (hence
the ClojureScript stuff), so if you have any private branches of IE with
latest DOM experiments, I'd be very happy to explore any new potential or
new efficiency that your ideas may give us! I'm very keen on that, too.

Off list seems to be best here..

Thank you Travis. I really appreciate being able to communicate freely
about ideas.

Marc

On Fri, Feb 13, 2015 at 11:20 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

 Marc,

 I'd first mention that I am keenly interested in improving the
 state-of-the-art in DOM (I'm driving the project to update IE's 20-year-old
 DOM as my day job.) I've also done a lot of thinking about thread-safe DOM
 designs, and would be happy to chat with you more in depth about some ideas
 (perhaps off-list if you'd like).

 I'd also refer you to a breakout session I held during last TPAC on a
 similar topic [1]. It had lots of interested folks in the room and I
 thought we had a really productive and interesting discussion (most of it
 captured in the IRC notes).

 [1] https://www.w3.org/wiki/Improving_Parallelism_Page

 -Original Message-
 From: Boris Zbarsky [mailto:bzbar...@mit.edu]
 Sent: Wednesday, February 11, 2015 12:34 PM
 To: public-webapps@w3.org
 Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous
 XMLHttpRequest

 On 2/11/15 3:04 PM, Brendan Eich wrote:
  If you want multi-threaded DOM access, then again based on all that I
  know about the three open source browser engines in the field, I do
  not see any implementor taking the huge bug-risk and opportunity-cost
  and
  (mainly) performance-regression hit of adding barriers and other
  synchronization devices all over their DOM code. Only the Servo
  project, which is all about safety with maximal hardware parallelism,
  might get to the promised land you seek (even that's not clear yet).

 A good start is defining terms.  What do we mean by multi-threaded DOM
 access?

 If we mean concurrent access to the same DOM objects from both a window
 and a worker, or multiple workers, then I think that's a no-go in Servo as
 well, and not worth trying to design for: it would introduce a lot of spec
 and implementation complexity that I don't think is warranted by the use
 cases I've seen.

 If we mean the much more modest have a DOM implementation available in
 workers then that might be viable.  Even _that_ is pretty hard to do in
 Gecko, at least, because there is various global state (caches of various
 sorts) that the DOM uses that would need to either move into TLS or become
 threadsafe in some form or something...  Again, various specs (mostly DOM
 and HTML) would need to be gone over very carefully to make sure they're
 not making assumptions about the availability of such global shared state.

  We should add lighter-weight workers and immutable data structures

 I should note that even some things that could be immutable might involved
 a shared cache in current implementations (e.g. to speed up sequential
 indexed access into a child list implemented as a linked list)...
 Obviously that sort of thing can be changed, but your bigger point that
 there is a lot of risk to doing that in existing implementations remains.

 -Boris