On Wed, May 29, 2013 at 9:39 PM, Michael[tm] Smith wrote:
> +Ojan, +Alex
>
> Jirka Kosek , 2013-05-14 17:22 +0200:
>
> > Hi,
> >
> > are there any plans to change Microdata API? From the following
> > conversation between Chromium developers it's not clear to me whether
> > they consider API itse
On 29 May 2013 01:30, Nils Dagsson Moskopp
wrote:
> "Constantine A. Murenin" schrieb am Tue, 28 May
> 2013 12:35:37 -0700:
>
>> […]
>>
>> The use-case is a deterministic URL shortener, where the user wants to
>> get access to certain information, which may be available via multiple
>> independent
Hi Boris,
div.setAttribute("fruit", "orange");
div.attributes.fruit = "apple";
alert(div.attributes.fruit); // apple
div.removeAttribute("fruit");
alert(div.attributes.fruit); // apple
alerts "apple" in current trunk Firefox both times, for example.
Okay, we will try
And this is why we should make named getter/setters a thing of the
past. New specs are still being written which use these WebIDL
features and almost all of them end up with confusing behavior like
this.
+1 +1 +1 +1e100 :)
Michael
--
Prince: Print with CSS!
http://www.princexml.com
On Wed, May 29, 2013 at 8:34 PM, Boris Zbarsky wrote:
>> div.attributes.fruit = "apple";
>> alert(div.attributes.fruit); // apple
>> div.setAttribute("fruit", "orange");
>> alert(div.attributes.fruit); // [object Attr]
>> div.removeAttribute("fruit");
>> alert(div.att
On 5/30/13 12:06 AM, Michael Day wrote:
This part still seems inconsistent with current browsers:
4) Setting a property name that is currently exposed does a Reject
(which means throw in strict mode, silently do nothing in
non-strict mode). Unless there is a named setter, of course.
+Ojan, +Alex
Jirka Kosek , 2013-05-14 17:22 +0200:
> Hi,
>
> are there any plans to change Microdata API? From the following
> conversation between Chromium developers it's not clear to me whether
> they consider API itself bad or only their implementation.
>
> https://groups.google.com/a/chrom
Hi Boris,
Thank you for the detailed explanation. Having the WebIDL named getter
definition helps to simplify things.
This part still seems inconsistent with current browsers:
4) Setting a property name that is currently exposed does a Reject
(which means throw in strict mode, silently
On 5/29/13 11:08 PM, Michael Day wrote:
For example, setting an attribute will create a property with the same
name as the attribute:
div = document.createElement("div");
div.setAttribute("foo", "bar");
alert(div.attributes.foo); // [Object Attr]
The DOM spec as written right no
Hi,
In the definition of the Element.attributes collection here:
http://dom.spec.whatwg.org/#dom-element-attributes
It doesn't seem to describe the behaviour for setting direct properties
of the attributes collection, and how they map to attributes.
For example, setting an attribute will cre
Let's actually back up a second.
What problem are you really trying to solve by changing the ordering?
As I see it, right now the situation is as follows (in implementations,
if not in the spec):
1) pagehide fires, with a boolean indicating whether at this point the
UA plans to place the pa
On 5/29/13 4:30 PM, Brady Eidson wrote:
I see in the HTML spec that the step *before* firing pagehide is “set
the Document’s page showing flag to false,” but I can’t find language
that says pagehide fires *before* the page is actually hidden, and
unload fires *after* the page is actually hidden.
On 5/29/13 4:27 PM, Brady Eidson wrote:
Does Mozilla have a test for this that I could explore in WebKit?
It's pretty trivial to create a testcase. Something simple like this:
test1.html:
Click me to open
a window, then follow the instructions in that window
Click me to dispatch an event
The spec for what should happen to that is the first step of
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-intr
This case clearly seems like a bug in Gecko: it's treating the
as if it's an HTML . That is, it's comparing only the local name (or
"
On Wed, 27 Feb 2013, Adam Klein wrote:
>
> Consider the following script:
>
> tr = document.createElement('tr')
> tr.innerHTML = '';
>
> That is, the fragment is parsed with tr as the context element. What
> should the generated DOM be?
Up to the it's unambiguous and uncontroversial, I hope; a
On May 29, 2013, at 12:02 PM, Boris Zbarsky wrote:
>
>> I’ve tried these search terms and the only obviously relevant thing I
>> could find was
>> http://lists.w3.org/Archives/Public/public-web-perf/2012Feb/0111.html
>
> Uh...
> http://www.w3.org/Search/Mail/Public/search?keywords=pagehide&h
Spinning this off as it’s become tangential to my original message:
On May 29, 2013, at 12:02 PM, Boris Zbarsky wrote:
> On 5/29/13 2:25 PM, Brady Eidson wrote:
>>> So what happens when script calls dispatchEvent on a node that's in a
>>> document that's in your page cache?
>>
>> I believe the
On Mon, 8 Apr 2013, Mohammad Al Houssami (Alumni) wrote:
>
> In the tokenizer specifications of the HTML5 parser the following is
> written :
>
> "Otherwise, if there is a current node and it is not an element in the
> HTML namespace "
>
> What does it mean ?
It's saying that the subsequent st
On 5/29/13 2:25 PM, Brady Eidson wrote:
So what happens when script calls dispatchEvent on a node that's in a
document that's in your page cache?
I believe the design is “nothing.”
That's a spec violation, then: there are no provisions in any DOM spec
for dispatchEvent on an EventTarget not
On May 28, 2013, at 10:11 PM, Boris Zbarsky wrote:
> On 5/29/13 12:55 AM, Brady Eidson wrote:
>>> This expectation was always wrong: events can be dispatched by script at
>>> any time to pages in the page cache.
>>
>> I'm sorry, who's page cache are you talking about?
>
> Gecko's, which initi
On 29/05/13 11:12, Takayoshi Kochi (河内 隆仁) wrote:
> Hi WHATWG,
>
> We work on W3C IME API (http://www.w3.org/TR/ime-api/) and we got comment
> from
> Microsoft people that it would be nice to have inputmode attribute in
> conjunction with the API.
>
> Currently the inputmode attribute is spec'ed
Hi WHATWG,
We work on W3C IME API (http://www.w3.org/TR/ime-api/) and we got comment
from
Microsoft people that it would be nice to have inputmode attribute in
conjunction with the API.
Currently the inputmode attribute is spec'ed as
http://www.whatwg.org/specs/web-apps/current-work/multipage/ass
"Constantine A. Murenin" schrieb am Tue, 28 May
2013 12:35:37 -0700:
> […]
>
> The use-case is a deterministic URL shortener, where the user wants to
> get access to certain information, which may be available via multiple
> independent content providers (which are all known to the shortening
> s
23 matches
Mail list logo
