On Sat, Apr 13, 2013 at 12:03 PM, John J Barton wrote:
> While I completely understand the beauty of having any JS object bound to
> an inherit functions that make that object 'be an element', I'm
> unsure of the practical value.
>
> To me the critical relationship between the JS and the element
Can you guys file a bug so that we remember?
:DG<
On Mon, Apr 15, 2013 at 8:09 PM, Dominic Cooney wrote:
> On Thu, Apr 11, 2013 at 4:41 PM, Scott Miles wrote:
>>
>> On Thu, Apr 11, 2013 at 12:33 AM, Angelina Fabbro
>> wrote:
>>>
>>> > I don't believe it's *needed* exactly, but we imagined some
On Thu, Apr 11, 2013 at 4:41 PM, Scott Miles wrote:
> On Thu, Apr 11, 2013 at 12:33 AM, Angelina Fabbro <
> angelinafab...@gmail.com> wrote:
>
>> > I don't believe it's *needed* exactly, but we imagined somebody wanting
>> to import HTML, use it destructively, then import it again.
>>
>> That doe
On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson wrote:
> For the record I'm opposed to what you are proposoing. I don't like that
> you lose the symmetry between innerHTML and outerHTML.
>
Sorry for replying to such a cold thread.
Could you elaborate on what symmetry is being broken here? outer
On Mon, Apr 15, 2013 at 1:49 PM, Anne van Kesteren wrote:
> So blob URLs are auto-revoked by default after the current script
> stops running. However, every fetch operation in existence (apart from
> synchronous XMLHttpRequest) does so asynchronous.
>
> So
>
> .src = blobURL
>
For anyone not fa
Would this be possible using the Scott and Brendan's idea of using a
specific element for prototyping? -->
https://gist.github.com/csuwldcat/5392291
On Mon, Apr 15, 2013 at 3:33 PM, John J Barton
wrote:
> I think that rendering a placeholder (eg blank image) then filling it in
> rather than bloc
I see. I wasn't aware of that reference since I didn't find it in my
searching. In that case, I don't have any particular objection though I
don't really know what would needs to be sanitized.
Daniel
On Mon, Apr 15, 2013 at 4:12 PM, Paul Topping wrote:
> http://www.w3.org/TR/MathML3/appendixb
http://www.w3.org/TR/MathML3/appendixb.html mentions both Mac and Windows
formats for MathML.
From: dch...@google.com [mailto:dch...@google.com] On Behalf Of Daniel Cheng
Sent: Monday, April 15, 2013 3:49 PM
To: Paul Topping
Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re:
On Mon, Apr 15, 2013 at 3:07 PM, Paul Topping wrote:
> Why would the answer to this question be dictated by the need to convert
> the MathML format to some other “native” format? I just want my app (native
> or web) to be able to identify the clipboard data type so it can consume
> the data as i
I think that rendering a placeholder (eg blank image) then filling it in
rather than blocking is good if done well (eg images with pre-allocated
space). Otherwise it's bad but less bad than blocking ;-).
But if you allow this implementation, then this whole discussion confuses
me even more. I'm th
Why would the answer to this question be dictated by the need to convert the
MathML format to some other “native” format? I just want my app (native or web)
to be able to identify the clipboard data type so it can consume the data as it
sees fit. Conversion to some other format is but one thing
*
*
*Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.*
IMO, the not-yet-upgraded case is nothing new, and developers will hardly
be surprised. This nit is no different than if devs include a jQuery
When I suggested formats that implementations ought to support, I
specifically mentioned image/svg+xml because it was mostly convertible to
native types (Windows metafile on Windows, PDF on Mac). I don't think
anyone's implemented this conversion, but it's technically possible.
On the other hand,
On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles wrote:
> >> What happens if the construction/initialization of the custom element
> calls one of the element's member functions overridden by code in a
> ?
>
> IIRC it's not possible to override methods that will be called from inside
> of builtins, so
>> So we can override some methods but not others, depending on the
implementation?
You can override methods that will be called from JS, but not from C++
(depending on platform).
>> Gee, that's not very encouraging
I was trying to just say we have been aware of these issue too and there
are eff
On 4/15/13 3:46 PM, Rick Waldron wrote:
What I was expecting the above to produce is a constructor capable of
something like this:
var smile = new Smile();
smile.nodeType === 1;
For that, you have to have a way for Smile to get the @@construct of
HTMLButtonElement. There's no way to do
*How, as component author, do I ensure that my imperative set up code runs
and modifies my element DOM content before the user sees the un-modified
custom element declared in mark-up? (I'm cheating, since this issue isn't
specific to your ) *
When you say "...runs before the user sees the unmodifi
>> What happens if the construction/initialization of the custom element
calls one of the element's member functions overridden by code in a
?
IIRC it's not possible to override methods that will be called from inside
of builtins, so I don't believe this is an issue (unless we change the
playfield
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20394
Joshua Bell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
*At least somebody explain why this is conceptually wrong.
*
Nothing is conceptually wrong with what you've stated Scott. I could live
with a element that is scoped to the as long as there
was some sort of 'registeredCallback' (as you previously alluded to many
posts back) that would be executed
On Mon, Apr 15, 2013 at 7:49 PM, Anne van Kesteren wrote:
> So blob URLs are auto-revoked by default after the current script
> stops running. However, every fetch operation in existence (apart from
> synchronous XMLHttpRequest) does so asynchronous.
>
> So
>
> .src = blobURL
>
> might very well s
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551
Joshua Bell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
> 1) call 'init' when component instance tag is encountered, blocking
parsing,
Fwiw, it was said that calling user code from inside the Parser could
cause Armageddon, not just block the parser. I don't recall the details,
unfortunately.
On Mon, Apr 15, 2013 at 11:44 AM, John J Barton wrote:
>
t seems like a better solution than
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 as having all
> APIs special case blob is just asking for trouble.
Never mind: http://krijnhoetmer.nl/irc-logs/whatwg/20130415#l-827
Back to no solution.
--
http://annevankesteren.nl/
On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky wrote:
> On 4/15/13 10:45 AM, Rick Waldron wrote:
>
>> Sorry, I should've been more specific. What I meant was that:
>>
>> new HTMLButtonElement();
>>
>> Doesn't construct an HTMLButtonElement, it throws with an "illegal
>> constructor" in Chrome an
Editors, Test Facilitators,
During next week's f2f meeting [Agenda], we will once again go through
[PubStatus] (aka the group's `dashboard`) to verify the data and to help
us all (not just WG members) understand the status, plans, issues, etc.
regarding all of our Specs and Test Suites.
If y
So blob URLs are auto-revoked by default after the current script
stops running. However, every fetch operation in existence (apart from
synchronous XMLHttpRequest) does so asynchronous.
So
.src = blobURL
might very well start fetching at the point blobURL is already cleaned up.
We need a diffe
On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles wrote:
> Thank you for your patience. :)
>
ditto.
>
>
> > ? user's instance code? Do you mean: Running component instance
> initialization during document construction is Bad?
>
> My 'x-foo' has an 'init' method that I wrote that has to execute bef
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21649
Joshua Bell changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Mon, Apr 15, 2013 at 12:50 PM, Anne van Kesteren wrote:
> On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking wrote:
>> So I guess the current solution is fine as longs as either
>> * No JS libraries will want to implement APIs that uses locks, or
>> * Such libraries are ok with not using the built
On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles wrote:
> Dimitri is trying to avoid 'block[ing] instance construction' because
> instances can be in the main document markup.
>
Yes we sure hope so!
>
> The main document can have a bunch of markup for custom elements. If the
> user has made eleme
Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.
The main document can have a bunch of markup for custom elements. If the
user has made element definitions a-priori to parsing that markup
(including inside wrote:
>
>
>
> On Mon, A
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles wrote:
> >> Why do the constructors of component instances run during component
> loading?
>
> I'm not sure what you are referring to. What does 'component loading' mean?
>
> >> Why not use standard events rather than callbacks?
>
>
> I'll some of the
Sorry for the extra posts. I promise to slow down.
>> Why not use standard events rather than callbacks?
I believe a better answer is that it was decided these callbacks had to
work synchronously relative to imperative construction.
So, I can do
var xfoo = document.createElement('x-foo');
x
>> The callbacks are convenient because (1) there is no question of 'who
registers a listener' (2) I can simply call my 'super' callback (or not) to
get inherited behavior.<<
One minute later, these seem like bad reasons. I shouldn't have shot from
the hip, let me do some research.
On Mon, Apr 1
>> Why do the constructors of component instances run during component
loading?
I'm not sure what you are referring to. What does 'component loading' mean?
>> Why not use standard events rather than callbacks?
This was discussed quite a bit, here is my off-the-cuff response. I may
have to do arc
Why do the constructors of component instances run during component loading?
Why not use standard events rather than callbacks?
Thanks,
jjb
On Apr 15, 2013 9:04 AM, "Scott Miles" wrote:
> Again, 'readyCallback' exists because it's a Bad Idea to run user code
> during parsing (tree construction)
Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.
This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Scott
On Mon, Apr 15, 2013 at 7:45 AM,
On 4/15/13 10:45 AM, Rick Waldron wrote:
Sorry, I should've been more specific. What I meant was that:
new HTMLButtonElement();
Doesn't construct an HTMLButtonElement, it throws with an "illegal
constructor" in Chrome and "HTMLButtonElement is not a constructor" in
Firefox (I'm sure this is the
Hi Halvord,
Yes, your rewording sounds like a good direction to me. I still worry that
placing plain text on the clipboard along with MathML will result in a lot of
apps failing to paste the MathML but doing so would probably be considered a
bug in such an app.
Thanks for filing the bugs. I su
On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky wrote:
> On 4/14/13 5:35 PM, Rick Waldron wrote:
>
>> I have a better understanding of problem caused by these generated
>> HTML*Element constructors: they aren't constructable.
>>
>
> I'd like to understand what's meant here. I have a good understa
On Mon, Apr 15, 2013 at 1:55 PM, Boris Zbarsky wrote:
> On 4/14/13 4:57 PM, Rick Waldron wrote:
>> Of course, but we'd also eat scraps from the trash if that was the only
>> edible food left on earth. document.createElement() is and has always
>> been "the wrong way"—the numbers shown in those gra
On 4/14/13 5:35 PM, Rick Waldron wrote:
I have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable.
I'd like to understand what's meant here. I have a good understanding
of how these constructors work in Gecko+SpiderMonkey, but I'm
On 4/14/13 4:57 PM, Rick Waldron wrote:
Of course, but we'd also eat scraps from the trash if that was the only
edible food left on earth. document.createElement() is and has always
been "the wrong way"—the numbers shown in those graphs are grossly
skewed by a complete lack of any real alternativ
On 4/14/13 3:07 PM, Allen Wirfs-Brock wrote:
>> 2, 3, 4
I believe have been suggested in one form or another, but as I
mentioned, were determined to be non-starters for Gecko. I don't think
we've heard anything from IE team.
Well #4 has been accepted for ES6 by all TC39 participants including
On 4/14/13 1:49 PM, Scott Miles wrote:
Erik Arvidsson came up with a strategy for overcoming this in Blink, but
to my recollection Boris Zbarsky said this was a non-starter in Gecko.
Just to be clear, the proposal there was to take an already existing
function object and call some UA-provided
Thanks for the extra long explanation. That was a good confirmation of
what I thought the issues were.
On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking wrote:
> Since Futures normally call their callbacks asynchronously, we can't
> set the open-flag to true right before the call, and set it back ri
Hi Paul, thanks for your comments.
> Mathematical information
>
> This section says "MathML often needs to be transformed to be
> copied as plain text, for example to make sure "to the power of"
> is shown with the caret "^" sign in a formula plain-text input."
> Such a transformation should not
48 matches
Mail list logo
