Re: [FileAPI] createObjectURL isReusable proposal
2012/2/3 Bronislav Klučka > How would you create copies programmaticaly? How would you reassign src > attribute of one image to another? The idea, that sometimes the attribute > would return string (regular URL, FileSystem APi URL) sometimes Blob... > What would you do in case like this > > img.src = blob; > div.appendChild(img); > var s = div.innerHTML; > div.innerHTML = ''; > div.innerHTML = s; > > which would work with regular URL, would fail in your suggestion... > This would fail just as badly with auto-releasing URLs. No approach so far makes this work (other than the explicit releasing that we're trying to give alternatives to). -- Glenn Maynard
Re: [selectors4][css3-syntax] should document.querySelector("html /* ") throw? (and some editorial comments)
On 2/3/12 8:52 PM, Kang-Hao (Kenny) Lu wrote:
# Unexpected end of style sheet. User agents must close all open
# constructs (for example: blocks, parentheses, brackets, rules,
# strings, and comments) at the end of the style sheet. For example:
...
IE9, FF9.0.1, Opera12alpha don't throw in this case, but Chromium 18 and
Safari 5.1 do throw.
That's presumably because WebKit generally doesn't implement the
above-quoted provision about end-of-stylesheet. Trivial testcase:
div::before { content: "PASS
which everyone but WebKit passes.
I don't have an opinion as to which is more correct
as this example is contrived anyway, but I think the spec should say
something about it, even if it's an "undefined".
Agreed, but it shoul also be made clear how the Selectors API parsing
does or doesn't coincide with CSS parsing. Especially because Selectors
API wants to change the parsing rules for its arguments so they no
longer quite match the CSS ones... Putting webapps back on the cc list
for that reason.
-Boris
[selectors4][css3-syntax] should document.querySelector("html /* ") throw? (and some editorial comments)
(Bcc public-webapps as this case is only observable via the Selectors API)
I found an edge case where the relevant specs don't provide a consistent
answer. Consider,
document.querySelector("html /* ")
should it throw or not?
The Selectors API calls the following production "selector string"[1]:
dom_selectors_group
: S* [ selectors_group ] S*
;
and use this term almost everywhere except this paragraph:
# Selectors are evaluated against a given element in the context of
# the entire DOM tree in which the element is located. If the given
# group of selectors is invalid ([SELECTORS4], section 3.7), the
# implementation must raise a SYNTAX_ERR exception
# ([DOM-LEVEL-3-CORE], section 1.4).
which references Selectors 4 (by the way, the link still links to
Selectors 3 and should be updated).
If we only look at the formal syntax, then an open comment, whether that
leads to a BAD_COMMENT token, is not part of the dom_selectors_group and
hence the example should throw. But it's not clear if the wildcard in
CSS2.1 core grammar[2] :
# Unexpected end of style sheet. User agents must close all open
# constructs (for example: blocks, parentheses, brackets, rules,
# strings, and comments) at the end of the style sheet. For example:
applies there, and I read the claim that if spec prose and formal
grammar disagrees, the prose trumps the formal. Also, The definition of
invalid selectors[3] in Selectors 4 has a line:
# a selector containing an invalid simple selector, an invalid
# combinator or an invalid token is invalid.
and it's also not clear if BAD_COMMENT counts as an invalid token.
IE9, FF9.0.1, Opera12alpha don't throw in this case, but Chromium 18 and
Safari 5.1 do throw. I don't have an opinion as to which is more correct
as this example is contrived anyway, but I think the spec should say
something about it, even if it's an "undefined".
== other editorial comments on selectors 4 (all syntax related) ==
In [3],
# User agents must observe the rules for handling parsing errors:
# * a simple selector containing an undeclared namespace prefix is invalid
# * a selector containing an invalid simple selector, an invalid
combinator
# or an invalid token is invalid.
# * a selector list containing an invalid selector is invalid.
this doesn't seem to have anything to do with error handling but
definitions of "invalid X". Some comments here:
1. If this section depends on the formal grammar then I think it should
say so. For example, "invalid combinator" isn't defined anywhere in the
spec except in the "combinator" production in the formal grammar.
2. There seems no definition of "invalid token". Is this term equivalent
to "unexpected token" or "a token which is not allowed at the current
parsing point."?
In [4]
# The argument to :nth-child() must match the grammar below, where
# INTEGER matches the token [0-9]+ and the rest of the tokenization
# is given by the Lexical scanner in section 10.2:
, I am not an expert in parsers but shouldn't this be
| The argument to :nth-child() must match the grammar below, where
| INTEGER is a NUMBER token that also matches [0-9]+ and the rest
| of the tokenization is given by the Lexical scanner in section 10.2:
?
The formal syntax section[5] says it needs to be updated, but I'll just
point out some problems now:
1. "compound_selector" is not defined. I am understand this correctly,
it should read "simple_selector_sequence".
2. "selector [ COMMA S* selector ]*" should read "selector [ S* COMMA
S* selector ]*"
3. If selectors_group is allowed to have S* on both sides, I think the
Selectors API spec no longer needs dom_selectors_group.
[1] http://dev.w3.org/2006/webapi/selectors-api2/#selector-string
[2] http://www.w3.org/TR/CSS2/syndata.html#parsing-errors
[3] http://dev.w3.org/csswg/selectors4/#invalid
[4] http://dev.w3.org/csswg/selectors4/#nth-child-pseudo
[5] http://dev.w3.org/csswg/selectors4/#formal-syntax
Cheers,
Kenny
[Bug 15866] Support HTML parsing in DOMParser
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15866 Ms2ger changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Ms2ger 2012-02-03 20:46:58 UTC --- Thanks. Let me know if I need anything else. https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/e978cc42a8b2 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [FileAPI] Blob protocol version - is this needed?
- Original Message - > On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote: > > Greetings Adrian, > > > > Sorry for the delay in responding to this email. > > > > Strictly speaking, we could remove the Blob Protocol Version (BLV) > > [1]. It > > isn't returned in getAllResponseHeaders. BLV 's purpose was in > > case the > > protocol changes, and to differentiate between versions. But the > > protocol is > > internally consumed within the UA. I can remove it. > > Thanks - I think that would be the right move. I don't think there's > a way to > test it (and as I mentioned in my previous note our implementation > doesn't > have it). (Done). http://dev.w3.org/2006/webapi/FileAPI/ -- A*
[Bug 15872] dear sir/mam, i inform for some malfunction of your item furchasing to your item mall was not found in item bank.please take it action.thanks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15872 Ms2ger changed: What|Removed |Added Status|NEW |RESOLVED CC||ms2...@gmail.com Resolution||INVALID --- Comment #1 from Ms2ger 2012-02-03 19:29:28 UTC --- It's invisible, sorry. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15872] New: dear sir/mam, i inform for some malfunction of your item furchasing to your item mall was not found in item bank.please take it action.thanks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15872 Summary: dear sir/mam, i inform for some malfunction of your item furchasing to your item mall was not found in item bank.please take it action.thanks Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: dear sir/mam, i inform for some malfunction of your item furchasing to your item mall was not found in item bank.please take it action.thanks Posted from: 94.96.95.169 User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [FileAPI] createObjectURL isReusable proposal
On 3.2.2012 15:13, Anne van Kesteren wrote: On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie, is this possible? Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). My idea was that innerHTML and getAttribute and such would get back about:blob or some such. I think having the same object associated with two images should be fine, so copy & pasting should probably work. about:blob is just for serialization purposes. How would you create copies programmaticaly? How would you reassign src attribute of one image to another? The idea, that sometimes the attribute would return string (regular URL, FileSystem APi URL) sometimes Blob... What would you do in case like this img.src = blob; div.appendChild(img); var s = div.innerHTML; div.innerHTML = ''; div.innerHTML = s; which would work with regular URL, would fail in your suggestion... B.
Re: [FileAPI] createObjectURL isReusable proposal
On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie, is this possible? Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). My idea was that innerHTML and getAttribute and such would get back about:blob or some such. I think having the same object associated with two images should be fine, so copy & pasting should probably work. about:blob is just for serialization purposes. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 15866] New: Support HTML parsing in DOMParser
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15866 Summary: Support HTML parsing in DOMParser Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: hsivo...@iki.fi QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org http://html5.org/specs/dom-parsing.html#the-domparser-interface Please specify that when the MIME type argument to parseFromString is "text/html", the other argument gets parsed as HTML in the non-fragment mode with scripting disabled (
[Bug 15864] New: [IndexedDB] Array as key, avoid array loops
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15864 Summary: [IndexedDB] Array as key, avoid array loops Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: odi...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org > Note that Arrays that contain other Arrays are allowed as valid keys. > In this case the algorithm above runs recursively when comparing the > individual values in the arrays. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#key-construct Using an array embedding itself makes a loop, the spec doesn't clarify how to deal with that. var a = []; a[0] = a; I guess you wouldn't want to /recurse/ two of those to find which is biggest ;-) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
