Re: [WebIDL] T[] migration

2016-02-16 Thread Simon Pieters

On Thu, 07 Jan 2016 20:12:44 +0100, Boris Zbarsky <bzbar...@mit.edu> wrote:


On 12/18/15 3:53 AM, Simon Pieters wrote:

Note that it requires liveness. Does that work for a frozen array?


No.  You'd have to create a new array object at the point when you want  
to update the set of values in the array.


OK...


Maybe this particular API should be a method instead that returns a
sequence?


Will that cause anyone to implement it?  Because if no one is planning  
to ever implement it, it should probably be removed, not twiddled.


Yes, you're right. Removed.

https://github.com/w3c/csswg-drafts/commit/e5353d078e686136fdb28c7de37ffd375cd6d79f
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29471

--
Simon Pieters
Opera Software



Re: Can we land heycam's WebIDL tests as-is and address review comments following?

2015-12-21 Thread Simon Pieters
On Mon, 21 Dec 2015 07:34:12 +0100, Zhang, Zhiqiang  
<zhiqiang.zh...@intel.com> wrote:



Hi,

2+ years ago, heycam submitted WebIDL tests at

https://github.com/w3c/web-platform-tests/pull/271

These tests have been reviewed by several guys but get no update ever  
since.


I wonder if we could land the tests as-is and address the review  
comments in further pull requests? Then we can make a test suite to  
advance the specification and for people to understand the specification.


Thoughts?

Thanks,
Zhiqiang


Personally I don't object to that plan, but an alternative is to create a  
new branch in w3c/web-platform-tests with these changes, and anyone with  
push access to w3c/web-platform-tests can make changes to that branch, and  
then we can merge to master when it's ready.


git fetch origin refs/pull/271/head:refs/remotes/origin/pr/271 --force
git checkout -b webidl-tests origin/pr/271
git push -u origin webidl-tests

--
Simon Pieters
Opera Software



Re: [WebIDL] T[] migration

2015-12-21 Thread Simon Pieters

On Fri, 18 Dec 2015 18:04:27 +0100, Olli Pettay <o...@pettay.fi> wrote:


On 12/18/2015 06:20 PM, Domenic Denicola wrote:

From: Simon Pieters [mailto:sim...@opera.com]


Note that it requires liveness. Does that work for a frozen array?


Frozen array instances are frozen and cannot change. However, you can  
have the property that returns them start returning a new frozen array.  
The spec needs to track when these new instances are created.



Changing the array object wouldn't be backwards compatible.
(The attribute used to be DOMStringList)

Maybe this particular API should be a method instead that returns a  
sequence?

Also not backwards compatible.

But I'd assume the first option (changing the array) would be less  
backwards incompatible, so I'd prefer that one.


OK, but... Document#styleSheetSets is not widely implemented, and appears  
to not be widely used. On github I see 80 code matches in javascript,  
where most are just listing stuff, some are browser sniffing, and some  
might be actual usage (maybe with a fallback for other browsers?).  
Although it has been implemented in Gecko for a long time, I think it is  
possible to make incompatible changes (or maybe drop altogether).


--
Simon Pieters
Opera Software



Re: [WebIDL] T[] migration

2015-12-18 Thread Simon Pieters

On Thu, 16 Jul 2015 18:16:04 +0200, Boris Zbarsky <bzbar...@mit.edu> wrote:


Other references:

·CSS OM


Presumably this is Document.styleSheetSets?  In practice, I believe no  
one except Gecko implements this and I therefore don't expect it to make  
it to REC... Updating this draft to use FrozenArray<> would be possible,  
of course.


Fixed in  
https://github.com/w3c/csswg-drafts/commit/e8a91deb46b670d6c2d8d302492a64222928d08a


Note that it requires liveness. Does that work for a frozen array?

Maybe this particular API should be a method instead that returns a  
sequence?


--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote:

http://www.w3c-test.org/websockets/keeping-connection-open/001.html --  
the test is wrong.  Passing undefined means the argument is not present  
per Web IDL, so this should not throw.


I assume you mean some other test since that test doesn't use undefined.  
(I'll have a look and fix ones that use undefined.)


https://github.com/w3c/web-platform-tests/pull/1702

--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 26 Mar 2015 18:24:22 +0100, Boris Zbarsky bzbar...@mit.edu wrote:


On 3/26/15 10:51 AM, Arthur Barstow wrote:

If anyone is willing to help with the failure analysis, that would be
very much appreciated.


Taking a brief look at some of the failures in Firefox, in addition to  
the ones Olli already posted about:


http://www.w3c-test.org/websockets/keeping-connection-open/001.html --  
the test is wrong.  Passing undefined means the argument is not present  
per Web IDL, so this should not throw.


I assume you mean some other test since that test doesn't use undefined.  
(I'll have a look and fix ones that use undefined.)


http://www.w3c-test.org/websockets/cookies/001.html seems racy to me: it  
kicks off an async test and then immediately removes the cookie, so it's  
not obvious to me why it expects that cookie to be present in the  
websocket connection; the cookie may well be removed before the  
connection is set up.


I agree. The spec says to return from the constructor and establish the  
connection in parallel, so it is not guaranteed which cookies to include.  
Fix: https://github.com/w3c/web-platform-tests/pull/1701


But arguably that is a spec bug. It would be nice if it was deterministic.  
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28393


http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html  
looks wrong to me: the value it should get is in fact undefined, since  
the property got deleted from the prototype.


(Will have a look.)

--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote:

http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html  
looks wrong to me: the value it should get is in fact undefined, since  
the property got deleted from the prototype.


(Will have a look.)


http://heycam.github.io/webidl/#es-attributes
[[
configurable is false if the attribute was declared with the [Unforgeable]  
extended attribute and true otherwise;

]]

Fix: https://github.com/w3c/web-platform-tests/pull/1703

--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 26 Mar 2015 18:06:15 +0100, Boris Zbarsky bzbar...@mit.edu wrote:


On 3/26/15 1:02 PM, Boris Zbarsky wrote:

It looks like the tests that are failed with an Error as opposed to a
Fail are not being counted in the 2 passes list?


And the for  
http://www.w3c-test.org/websockets/keeping-connection-open/001.html  
which is all-Timeout.


This test passes for me in Blink and Gecko. It has a meta indicating it  
needs a long timeout. Is it a bug in the test runner being used here?


--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote:

websockets/interfaces.html  the test itself has bugs (uses old  
idlharness.js?).


https://github.com/w3c/web-platform-tests/pull/1714

--
Simon Pieters
Opera Software



Re: [websockets] Test results available

2015-04-02 Thread Simon Pieters

On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote:

Also websockets/interfaces/WebSocket/events/013.html is buggy. Seems to  
rely on blink/presto's EventHandler behavior, which is not

what the specs says should happen.


It probably matched the spec at the time the test was written.

Spec now says [TreatNonObjectAsNull] so this should return the object, not  
null.

https://html.spec.whatwg.org/multipage/webappapis.html#eventhandlernonnull

Fix: https://github.com/w3c/web-platform-tests/pull/1704

--
Simon Pieters
Opera Software



Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

2015-03-27 Thread Simon Pieters
On Sat, 21 Mar 2015 13:52:25 +0100, Arthur Barstow art.bars...@gmail.com  
wrote:


As previously mentioned on [p-w], the test results for Web Messaging  
[All] indicate significant interoperability with only two tests that  
have less than two passes [2]. The two tests, including a short  
analysis of the failure, are:


1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test  
failure (which passes on Firefox) can be considered more of a Web IDL  
implementation issue and thus not a significant interop issue.


2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this  
test failure (which passes on IE) is considered an implementation bug  
(MessageChannel and MessagePort are supposed to be exposed to Worker)  
that is expected to be fixed.


Cindy created a Draft PR [PR] that includes Hixie's updates since the  
[CR] was published (but not the PortCollection interface [PC] which is  
not broadly implemented). Overall, we consider the changes since the CR  
as non-substantive bug fixes and clarifications that align the spec with  
current implementations, and that the test suite tests the updated spec.  
See [Diff] for all of changes between the CR and the draft PR and note  
the draft PR's status section includes a short summary of the changes.


As such, this is a Call for Consensus to publish a Proposed  
Recommendation of Web Messaging using the [PR] as the basis. Agreement  
with this CfC means you consider the test results shows interoperability  
and the changes since CR are not substantive.


If you have any comments or concerns about this CfC, please reply to  
this e-mail by March 28 at the latest. Positive response is preferred  
and encouraged, and silence will be considered as agreement with the  
proposal. If there are no non-resolvable objections to this proposal,  
the motion will carry and we will request the PR be published.


Opera supports publishing.


-Thanks, ArtB

[p-w]  
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html

[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5







--
Simon Pieters
Opera Software



Re: [XHR] UTF-16 - do content sniffing or not?

2015-03-23 Thread Simon Pieters
On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen  
hst...@mozilla.com wrote:



Hi,
I've just added a test loading UTF-16 data with XHR, and it exposes an
implementation difference that should probably be discussed:

Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
send charset=UTF-16 in the Content-Type header - should the browser
detect the encoding, or just assume UTF-8 and return mojibake-ish data?

Per my test, Chrome detects the UTF-16 encoding while Gecko doesn't. I
think the spec currently says one should assume UTF-8 encoding in this
scenario. Are WebKit/Blink - developers OK with changing their
implementation?

(The test currently asserts detecting UTF-16 is correct, pending  
discussion

and clarification.)


What is your test doing? From what I understand of the spec, the result is  
different between e.g. responseText (honors utf-16 BOM) and JSON response  
(always decodes as utf-8).


--
Simon Pieters
Opera Software



Re: [XHR] UTF-16 - do content sniffing or not?

2015-03-23 Thread Simon Pieters
On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen  
hst...@mozilla.com wrote:



On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote:


On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen 
hst...@mozilla.com wrote:



Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
send charset=UTF-16 in the Content-Type header - should the browser
detect the encoding, or just assume UTF-8 and return mojibake-ish data?





What is your test doing? From what I understand of the spec, the result  
is
different between e.g. responseText (honors utf-16 BOM) and JSON  
response

(always decodes as utf-8).



It tests responseText.


OK.

I think the spec currently says one should assume UTF-8 encoding in  
this scenario.


My understanding of the spec is different from yours. Let's step through  
the spec.


https://xhr.spec.whatwg.org/#text-response

[[
Let bytes be response's body.

If bytes is null, return the empty string.

Let charset be the final charset.
]]

final charset is null.

[[
If responseType is the empty string, charset is null, and final MIME type  
is either null, text/xml, application/xml or ends in +xml, use the rules  
set forth in the XML specifications to determine the encoding. Let charset  
be the determined encoding. [XML] [XMLNS]

]]

Which MIME type did you use in the response? BOM sniffing in XML is  
non-normative IIRC. For other types, see below.


[[
If charset is null, set charset to utf-8.

Return the result of running decode on byte stream bytes using fallback  
encoding charset.

]]

-
https://encoding.spec.whatwg.org/#decode

[[
For each of the rows in the table below, starting with the first one and  
going down, if the first bytes of buffer match all the bytes given in the  
first column, then set encoding to the encoding given in the cell in the  
second column of that row and set BOM seen flag.

]]

This step honors the BOM. The fallback encoding is ignored.

--
Simon Pieters
Opera Software



Re: oldNode.replaceWith(...collection) edge case

2015-01-21 Thread Simon Pieters
On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com  
wrote:



Ah, thank you for letting me know.

I vaguely remember document fragment is introduced just to reduce  
reflows. Looks like this best practice is obsolete now? (I remember  
myself wondering why bowsers couldn’t optimize that back then.) Many  
people still suggest it though, including google  
(https://developers.google.com/speed/articles/javascript-dom  
https://developers.google.com/speed/articles/javascript-dom the  
DocumentFragment DOM Generation” section), and you can find more by  
googling “why use document fragment.


I think that article is a bit misguided. Changing a class does trigger a  
reflow, but it doesn't force a reflow while the script is running (maybe  
it does in old browsers). Asking for layout information does force a  
reflow.


I think documentfragment has been faster in several browsers and maybe  
still is, but in Blink at least it appears that the different methods are  
getting about equally fast. It probably depends on how you do it, though.  
This jsperf might be interesting:


http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81

So to recap, when you have the need to pass the context node as an  
argument along with other nodes, just use before() and after() to insert  
these other nodes? And even insert them one by one is fine?


Yeah.

--
Simon Pieters
Opera Software



Re: oldNode.replaceWith(...collection) edge case

2015-01-20 Thread Simon Pieters
On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang curvedm...@gmail.com  
wrote:


I wonder what the correct method should be? For the example I gave in  
the previous mail, it looks like I have to either create two fragments  
(and compute which nodes go to which fragment) and insert them before or  
after the node (two reflows), or implement the transient node algorithm  
myself (but with no suppressing observer ability, also three reflows  
(insert fake node, pull out context node, insert fragment), i guess if  
browsers implement it natively, they can reduce it to just one reflow?).  
Both doesn’t sound very optimal.


In all cases it would be just one reflow after the script has finished,  
unless you force a reflow by asking for layout information (e.g.  
offsetTop) between the mutations.


--
Simon Pieters
Opera Software



Re: Defining a constructor for Element and friends

2015-01-19 Thread Simon Pieters

On Fri, 16 Jan 2015 20:08:30 +0100, Domenic Denicola d...@domenic.me wrote:


From: Anne van Kesteren [mailto:ann...@annevk.nl]

How can that work if the custom element constructor needs to look in  
the registry to find its name? Pick a name at random?


Nah, it just automatically starts acting like HTMLQuoteElement: the  
localName option becomes required. See


https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L229-L233

https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L51-L54


Consider if HTML adds a new element that uses the same interface as  
another element, let's say foobar, so that both foobar and data use  
HTMLDataElement. When this happens, new HTMLDataElement() starts throwing?


Similarly, if HTML is changed such that an element changes to use a more  
specific interface, e.g. ruby changes from HTMLElement to  
HTMLRubyElement, then new HTMLElement('ruby') will start throwing?


If so, it seems it removes some flexibility with how HTML uses interfaces.  
In particular many elements use HTMLElement and it should be possible to  
change them to use a more specific interface. How do you envision to solve  
this? Should we assign element-specific interfaces to all post-HTML4  
elements now, just in case? Or make new HTMLElement('ruby') create an  
HTMLRubyElement? Something else?


--
Simon Pieters
Opera Software



Re: [editing] Responsive Input Terminology

2014-12-12 Thread Simon Pieters
On Fri, 12 Dec 2014 13:39:47 +0100, Tobie Langel tobie.lan...@gmail.com  
wrote:



On Fri, Dec 12, 2014 at 1:00 PM, Arthur Barstow art.bars...@gmail.com
wrote:


What is your counter-proposal?



Heh.

Fair enough, I guess. :)

These seem related to what Java calls semantic events [JAVADOC], so I'd
give that a try to see if it fits the model. If not, would abstract
events or simply high-level events work? Sorry if these have already
been discussed and dismissed (haven't had much time to look through the
archives, tbh).


How about device-independent events?

--
Simon Pieters
Opera Software



Re: [editing] Responsive Input Terminology

2014-12-12 Thread Simon Pieters
On Fri, 12 Dec 2014 17:02:25 +0100, Frederico Knabben  
f.knab...@cksource.com wrote:



On Friday, 12 December 2014 at 14:40, Simon Pieters wrote:

How about device-independent events?
Aren’t we missing what kinds of events we’re talking about? We would  
just know that those events are device-independent.


So far we’ve been talking about “input” events. If this is still the  
case, this should be clear.


Option 1: You agree that because we’re talking about “device”, “input”  
is an implicit information. I’m unsure.


I think this is generally understood. You wouldn't refer to e.g. the  
'load' event as a device-independent event even though it technically is.



Option 2: Device-Independent Input Events (dii-events then).

Option 3: We’re talking about a totally new group of events, which don’t  
include only input, but everything that is “device-independent”. Then  
use cases should be listed.


--
Simon Pieters
Opera Software



Re: [eventsource] ACTION-742: Re sse test results, followup on the timeouts with the 2 test facilitators (Web Applications Working Group)

2014-11-13 Thread Simon Pieters
On Thu, 13 Nov 2014 10:14:38 +0100, Anne van Kesteren ann...@annevk.nl  
wrote:



On Thu, Nov 13, 2014 at 9:20 AM, Zhang, Zhiqiang
zhiqiang.zh...@intel.com wrote:
We may need to re-evaluate the tests, however, because the latest  
editor draft has removed this statement in the CR:


[[
This constructor must be visible when the script's global object is  
either a Window object or an object implementing the WorkerUtils  
interface.

]]

Thoughts, Simon  Odin?


Redundant with [Exposed].

Please use  
https://html.spec.whatwg.org/multipage/comms.html#server-sent-events

when implementing.


What Anne said. :-)

--
Simon Pieters
Opera Software



Re: [Custom] Custom elements and ARIA

2014-08-29 Thread Simon Pieters
On Thu, 28 Aug 2014 16:57:00 +0200, Domenic Denicola  
dome...@domenicdenicola.com wrote:


Hi Steve, thanks greatly for your help. It's clear now that I should  
have reached out to you for your expertise directly before being very  
wrong on a public mailing list :)


From: Steve Faulkner faulkner.st...@gmail.com

It appears (please correct me) you have made the assumption that  
'strong native semantics' for roles is a UA requirement? This is not  
the case (in the W3C HTML spec [1] at least, can't speak for where the  
WHATWG spec has gone in defining ARIA in HTML), they  are author  
conformance requirements.


Yes, I was misled about that pretty badly. That changes things, as it  
means there are no non-overridable roles or stoperties (as you show with  
hr role=menuitem).


States and properties can be non-overridable, though, as I understand it.

[[
When a host language declares a WAI-ARIA [state/property] attribute to be  
in direct semantic conflict with a native attribute for a given element,  
user agents MUST ignore the WAI-ARIA attribute and instead use the host  
language attribute with the same implicit semantic.

]]
http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict_header

From my reading though, the default implicit ARIA semantics are still UA  
requirements, right?


Yes.


[...]


--
Simon Pieters
Opera Software



Re: HTML imports: new XSS hole?

2014-06-03 Thread Simon Pieters
On Mon, 02 Jun 2014 11:32:45 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



How big of a problem is it that we're making link as dangerous as
script? HTML imports can point to any origin which then will be able
to execute scripts with the authority of same-origin.


I still think it is a problem.

http://www.w3.org/mid/op.ww3ecpo5idj3kv@simons-macbook-pro.local

--
Simon Pieters
Opera Software



Re: where do tests for window.opener go?

2014-05-21 Thread Simon Pieters
On Wed, 21 May 2014 17:54:44 +0900, Zhang, Zhiqiang  
zhiqiang.zh...@intel.com wrote:



From: Hallvord R. M. Steen [mailto:hst...@mozilla.com]
Sent: Wednesday, May 21, 2014 4:22 AM
To: public-webapps
Subject: [web-platform-tests] where do tests for window.opener go?

Hi,
we have a window.opener issue and would like to have some tests for it.  
I'm

planning to write some and thought I might as well add them to the web-
platform-tests suite. Where? Would this be a suitable location:
https://github.com/w3c/web-platform-
tests/tree/master/html/browsers/the-window-object/security-window ?
-HR


For security, yes.

For navigating auxiliary browsing contests in the DOM, better to  
https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts


Alternatively, if there are multiple plausible places, and you want some  
related tests to be in the same place but still annotate some of them as  
being a test for another section, you can do that with link rel=help.


--
Simon Pieters
Opera Software



Re: Custom Elements: 'data-' attributes

2014-05-12 Thread Simon Pieters
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On the other hand, if the same element had exposed contentEditable  
property, then UA's native contentEditable property would simply be  
overridden since it would appear higher up in the prototype chain.   
It's true that this custom element's contentEditable would have  
completely different semantics from that on other elements but that  
wouldn't break websites that use this custom element as long as authors  
are only accessing contentEditable property on instances of the custom  
element for semantics C.


I forgot the exact details, but we had some amount of trouble when we
introduced min and max attributes due to sites using expandos with the
same names.

I think we need something better than encouraging certain conventions
if we want this to work.


Bare names in event handler content attributes are troublesome.

For instance, sites doing:

button onclick=action()

made us have to rename button action to button formaction (the new  
.action reflecting action= was closer in the scope chain than the  
intended function).


Global attributes have the same issue.

So when we research if it's safe to add a new global attribute, it's not  
enough to measure how often such an attribute is used in the wild. We need  
to research bare names in event handlers also.


--
Simon Pieters
Opera Software



Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

2013-12-18 Thread Simon Pieters

On Wed, 18 Dec 2013 11:58:07 +0100, Simon Pieters sim...@opera.com wrote:

On Tue, 17 Dec 2013 17:06:57 +0100, Boris Zbarsky bzbar...@mit.edu  
wrote:



On 12/17/13 3:29 AM, Jonas Sicking wrote:

This is a good point. Would this have performance implications for
down-level browsers? I don't know if prescanners etc in contemporary
browsers are smart enough to ignore script tags that use a non-JS
type attribute.


Gecko's is not.  Not least because as far as I can tell scripts with  
unknown type are in fact always loaded,


In my testing this appears to not be the case.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2697

This gives nothing in the Network tab in Firefox or in my TCP inspector.

I think this is the same as what the spec requires and what at least  
WebKit/Blink/Presto also do.


Sorry, not Presto.

See step 7 in  
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#prepare-a-script  
(the fetch happen in step 14).



But it seems you are correct about the behavior of the speculative  
parser in Gecko:


http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2698


Same in WebKit/Blink.

--
Simon Pieters
Opera Software



Re: Refactoring SharedWorkers out of Web Workers W3C spec

2013-12-12 Thread Simon Pieters
On Wed, 11 Dec 2013 14:42:15 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:



One of the issues here is  `missing data`.


Indeed.

The first Call for workers Test Results was sent over a half-year ago  
and another one a few weeks before WebApps' Shenzhen meeting. Despite  
those requests, the workers implementation report [IR] remains empty.


Simon - would you please add results for Presto?


Done.

First I ran the tests using https://bitbucket.org/ms2ger/test-runner/src  
on a local server, but then I couldn't think of a straight-forward way to  
put the results in the wiki so I just ran the tests manually, too. :-(  
Since most tests are automated it's silly to run them manually and edit a  
wiki page. Is there a better way?


I also found a bug in a test  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24074


(Actually there were several tests with bugs but I didn't investigate  
further.)


Kinuko - would you please add results for Chrome (as you said you would  
do in Shenzhen [Mins])?


Travis - would you please add results for IE?

Another issue is that during the related discussion in Shenzhen, I don't  
think this new info from Jonas was available. Jonas - can someone please  
run the tests on FF Nightly (see [IR] or the test suite [Tests])?


Depending on the test results, it might make sense to (re)consider if it  
still makes sense to create a spec of without shared workers.


-Thanks, ArtB

[IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers
[Tests] http://w3c-test.org/web-platform-tests/master/workers/
[Mins] http://www.w3.org/2013/11/12-webapps-minutes.html#item08






--
Simon Pieters
Opera Software



Re: Refactoring SharedWorkers out of Web Workers W3C spec

2013-12-11 Thread Simon Pieters
On Tue, 10 Dec 2013 20:14:35 +0100, Travis Leithead  
travis.leith...@microsoft.com wrote:


During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove  
Shared Workers from the W3C Web Workers spec [3] in order for the spec  
to pass the first of the two stated CR exit criteria in the spec itself.


I'm afraid that won't be enough; if you two implementations passing all  
approved tests you need to remove the spec for dedicated workers also.  
Safest is probably to remove the whole spec and all the tests, then we'll  
have 100% pass rate.


Seriously though, I really don't understand the motivation here. I'd  
rather we remove the first exit criteria than try to punch conformance  
holes in the spec for failing tests.


--
Simon Pieters
Opera Software



Re: Refactoring SharedWorkers out of Web Workers W3C spec

2013-12-11 Thread Simon Pieters

On Tue, 10 Dec 2013 22:09:38 +0100, Jonas Sicking jo...@sicking.cc wrote:


We at Mozilla just finished our implementation of Shared Workers. It
will be turned on in the nightly releases starting tomorrow (or maybe
thursday) and will hit release on April 29th.


Excellent.


So if we are only reason we're doing anything here is lack of a 2nd
implementation, then we might already be good.


The premise here appears to be that Presto doesn't count. Why?

Presto has been shipping shared workers for 3,5 years now (introduced in  
Opera 10.60). As far as I can tell Presto-based Opera products match the  
definition of implementation in the CR exit criteria.



That said, I don't know what the test suite status is etc, so I'm
totally fine with punting Shared Workers for now.


The test suite coverage is about the same between dedicated workers and  
shared workers, I believe.



However I'd really like to see us start a level 2 of the spec. The
synchronous messaging channels is something else I'd like to see done
there.

/ Jonas



--
Simon Pieters
Opera Software



Re: Sync IO APIs in Shared Workers

2013-11-22 Thread Simon Pieters

On Fri, 22 Nov 2013 03:33:51 +0100, Jonas Sicking jo...@sicking.cc wrote:


The only browser shipping SharedWorkers is Chrome (not sure if Opera
does too?),


Yes, both Presto-based (since Opera 10.60) and Chromium-based.

--
Simon Pieters
Opera Software



Re: Define window.orientation

2013-11-06 Thread Simon Pieters

On Wed, 06 Nov 2013 01:17:31 +0100, Jonas Sicking jo...@sicking.cc wrote:


window.screen.orientation seems like a better way forward.


Why would window.screen.orientation be any more correctly implemented than  
window.orientation?


--
Simon Pieters
Opera Software



Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

2013-10-29 Thread Simon Pieters
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl  
wrote:



We are considering not throwing in XML.


Only on getting innerHTML, though, right?

--
Simon Pieters
Opera Software



Re: [clipboard] typo in WebIDL

2013-10-08 Thread Simon Pieters
On Tue, 08 Oct 2013 12:32:22 +0200, Hallvord R. M. Steen  
hst...@mozilla.com wrote:





Better now, right?
http://dev.w3.org/2006/webapi/clipops/clipops.html#dictionary-clipboardeventinit-members



Not quite, you removed the attribute keyword from the interface
declaration too, where it is needed.


Guilty, and fixed - I obviously need to study that WebIDL spec in some  
detail.. :-/


Pro tip: use http://www.w3.org/2009/07/webidl-check (I invoke it in my  
Makefile for CSSOM).


--
Simon Pieters
Opera Software



Re: [clipboard] typo in WebIDL

2013-10-08 Thread Simon Pieters

On Tue, 08 Oct 2013 17:19:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote:


On 10/8/13 7:47 AM, Simon Pieters wrote:

Pro tip: use http://www.w3.org/2009/07/webidl-check (I invoke it in my
Makefile for CSSOM).


Hmm.  What makes sure this is updated when the spec is updated?  I just  
tried this:


   interface Foo {
 void x(optional long y, long z);
   };

and the checker reports an error...


See the footer. Please report bugs on github.  
https://github.com/dontcallmedom/webidl-checker/issues


--
Simon Pieters
Opera Software



Re: [XHR] Content-Length header for data: URLs

2013-09-20 Thread Simon Pieters

On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:


On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net wrote:
Sure, what I actually meant is that you'd need to somehow pre-parse the  
data

URL to extract the exact length before storage. Dunno how
desirable/desired/common this is.


I would hardly call taking the length subtracting any characters
before the , and applying a multiplier parsing. You don't have to
look at any characters after the , at all.


Just applying a multiplying doesn't take percent-escaping into account,  
though.


--
Simon Pieters
Opera Software



Re: [XHR] xhr.responseXML.cookie ?

2013-09-20 Thread Simon Pieters
On Fri, 20 Sep 2013 12:53:23 +0200, Hallvord Steen hst...@mozilla.com  
wrote:



Hi,
per this test:
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm
some implementations define responseXML.cookie and some don't. This  
probably isn't really XML-related, but I guess it should be raised and  
possibly defined somewhere (is it already?)?


It's defined here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie

Since that document has no browsing context, getting returns empty string  
and setting does nothing, per spec.


--
Simon Pieters
Opera Software



Re: [XHR] responseXML.referrer

2013-09-20 Thread Simon Pieters
On Fri, 20 Sep 2013 12:58:42 +0200, Hallvord Steen hst...@mozilla.com  
wrote:


Another issue exposed by  
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm


Gecko sets responseXML.referrer to the requesting URL. Most other  
implementations set it to an empty string. Where is / should this be  
spec'ed?


http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-referrer

The XHR spec doesn't seem to set the document's referrer, so the value  
is the empty string per spec.


--
Simon Pieters
Opera Software



Re: [XHR] statusText, status and network errors

2013-09-20 Thread Simon Pieters
On Fri, 20 Sep 2013 13:20:44 +0200, Hallvord Steen hst...@mozilla.com  
wrote:


Test case  
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-redirect-bogus.htm  
has an interesting behaviour in Gecko. Last test fails with output:

assert_equals: expected  but got WEBSRT MARKETING

Test returns a bogus redirect like

HTTP/1.1 303 WEBSRT MARKETING
Location: foobar:some...@example.org

Per spec, this is a network error. Now, the spec does *not* explicitly  
say that exposing .statusText for network errors is wrong, although the  
test asserts that it is. Maybe some spec clarification is required? Or  
maybe it makes sense to pass status and statusText on to the script even  
if redirects fail, and we should spec that?

-Hallvord


http://xhr.spec.whatwg.org/#network-error
-
http://xhr.spec.whatwg.org/#request-error
-
http://xhr.spec.whatwg.org/#terminate-the-request
-
Set the error flag.

http://xhr.spec.whatwg.org/#dom-xmlhttprequest-statustext
-
If the error flag is set, return the empty string.

(I'm not sure where the spec says that the above case is a network error,  
though.)


--
Simon Pieters
Opera Software



Re: when will serializing a document throw?

2013-09-20 Thread Simon Pieters
On Fri, 20 Sep 2013 14:01:36 +0200, Hallvord Steen hst...@mozilla.com  
wrote:


If a document is passed to send(), the spec says re-throw any  
exception the serializing throws. There is a test that attempts to test  
this statement:


http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-entity-body-document-bogus.htm

It passes a completely empty document without even a document element to  
send(). No implementation throws.


Is the incomplete spec attemt on  
http://domparsing.spec.whatwg.org/#concept-serialize-xml the best  
reference we have at the moment? Even the statement I found there about  
serializing comments that do not match the comment syntax seems not to  
match reality - Gecko serialized a document containing 'html!--  
invalid comment ---/html just fine.


I think the reason here is that what the spec says is the right thing, and  
there probably isn't a Web compat reason not to do the right thing, but  
browsers haven't considered this to be high priority to fix.


Maybe we could remove the throwing from the spec, but it seems kind of sad  
to not catch this in the serializer.


Does anyone have examples of documents that should and actually DO throw  
when serialized? Or should we just drop that test and leave that spec  
statement untested?


Why would you drop the test?

--
Simon Pieters
Opera Software



Re: when will serializing a document throw?

2013-09-20 Thread Simon Pieters
On Fri, 20 Sep 2013 14:34:55 +0200, Hallvord Steen hst...@mozilla.com  
wrote:


I think the reason here is that what the spec says is the right thing,  
and

there probably isn't a Web compat reason not to do the right thing, but
browsers haven't considered this to be high priority to fix.


Well, that may be the reason - and I'm not aware of any compat issues  
anyone has had in the past because of exceptions here. It still seems a  
bit suspect that all implementors have aligned perfectly on the  
spec-wise wrong behaviour. It also carries a bit of a risk to push for  
introducing new exceptions and make code that didn't throw historically  
change behaviour.


Sure.

Not throwing gives the impression that it will round-trip, but actually it  
won't. That's bad. Catching the error early is better.


(Another solution to this problem would be to make the XML parser error  
tolerant, but that hasn't been a great success so far.)


Maybe we could remove the throwing from the spec, but it seems kind of  
sad

to not catch this in the serializer.


Sort of.. but then again, I guess a completely empty string could be  
considered a valid representation of a completely empty document..? :-)


XML can't represent an empty document.

--
Simon Pieters
Opera Software



Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

2013-06-05 Thread Simon Pieters
On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen  
kenneth.r.christian...@intel.com wrote:



I support adding some CSSOM API's for CSS Device Adaptation, but I would
not do so for the viewport meta tag, which has its share of issues.


There's currently http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces

Is that sufficient?

--
Simon Pieters
Opera Software



Re: webcomponents: import instead of link

2013-05-15 Thread Simon Pieters
On Wed, 15 May 2013 20:26:36 +0200, Dimitri Glazkov  
dglaz...@chromium.org wrote:



On Tue, May 14, 2013 at 2:21 PM, Simon Pieters sim...@opera.com wrote:

That seems to be an argument based on aesthetics. That's worth  
considering,
of course, but I think is a relatively weak argument. In particular I  
care

about the first bullet point above. link is not capable of executing
script from an external resource today. What are the implications if it
suddenly gains that ability?


Given that WebAppSec peeps suggested that CSP treats link rel=import
as script-src, I am pretty sure we're okay here. Are there any other
things that we should worry about?


That by itself doesn't make me confident that there are no security  
problems. If this has been reviewed by the security team at one or several  
browser vendors, that would inspire more confidence. Has it?


I don't have a specific attack scenario to present right now. I'm just  
presenting my knee-jerk reaction to making an existing element capable of  
executing script from an external file.


Case study: img was historically not capable of executing script from an  
external file. This lead to sites expecting img to be safe (e.g. allow  
untrusted comments to use img). When browsers wanted to support SVG in  
img, scripting had to be disabled in order to not break the assumption  
that img is safe.



There's one more ditty that seems valuable: HTML Imports
scripts-blocking behavior is much closer to how link rel=stylesheet
works  
(https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html#dfn-import-ready-flag

and thereabouts)


I'm not familiar with the code for this in browsers, but it seems to me  
that it shouldn't be much harder to reuse the mechanism for this if we use  
script import rather than link rel=import.


--
Simon Pieters
Opera Software



Re: webcomponents: import instead of link

2013-05-14 Thread Simon Pieters
On Tue, 14 May 2013 09:45:01 +0200, Hajime Morrita morr...@google.com  
wrote:


Just after started prototyping HTML Imports on Blink, this idea comes to  
my

mind: Why not have import for HTML Imports?

The good old link has its own semantics which allows users to change  
the

attributes dynamically. For example, you can change @href to load other
stylesheets. @type can be dynamically changed as well.

In contrast, importing HTML document is one-shot action. We don't allow
updating @href to load another HTML. (We cannot do that anyway since  
there

is no de-register of custom elements.) This difference will puzzle page
authors.

And an implementer (me) is also having troubles... Current link
implementation is all about dynamic attribute changes. disabling its
dynamic nature only with @rel=import seems tricky.

Well, yes. I can just refactor the code. But this complication implies  
that

making it interoperable will be a headache. There will be many hidden
assumptions which come from underlying link implementation. For  
example,

what happens if we update @rel from import to style after the element
imported document or vice versa? We need to clarify all these cases if we
choose link as our vehicle. It seems burden for me.

Using new element like import doesn't have such issues. We can just
define what we need. Also,
we'll be able to introduce import-specific attributes like @defer, @async
or even something like @sandbox without polluting link vocabulary.

One downside is that we'll lose the familiarity of link.  But having
indirection like the Import interface smells like we're just abusing  
it.


What do you think? Is this reasonable change or am I just restarting
something discussed before?


I have proposed script import=url/script instead of link rel=import  
href=url before.


http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0009.html
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0024.html

Benefits:

 * Components can execute script from an external resource, which script  
src can do as well, so that seems like a good fit in terms of security  
policy and expectations in Web sites and browsers.
 * script src is not dynamic, so making script import also not dynamic  
seems like a good fit.
 * script can appear in head without making changes to the HTML parser  
(in contrast with a new element).


To pre-empt confusion shown last time I suggested this:

 * This is not script src.
 * This is not changing anything of the component itself.

--
Simon Pieters
Opera Software



Re: Fixing appcache: a proposal to get us started

2013-04-04 Thread Simon Pieters

On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon ro...@w3.org wrote:


On 29/03/2013 21:08 , Jonas Sicking wrote:

* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content negotiation headers for images vs media files. I'm not sure
that this is worth it though given how few websites use content
negotiation headers.
* Use script to detect which formats are supported by the UA and then
use cacheURL to add the appropriate URL to the cache.
* Use the NavigationController feature.
* Use UA-string detection. You can either send different manifests
that point to different URLs for the media, or use a single manifest
but do the UA detection and serve different media files from the same
media URL. This is a pretty crappy solution though.


Another option: in your list of URLs to cache, instead of just strings  
you can also have objects of the form { video/webm: kittens.webm,  
video/evil: dead-kittens.mv4 } that would operate in a manner  
modelled on source, caching only what's needed.


Is this intended only for video resources, or arbitrary resources?  
Non-media elements (and hence, non-media resources) don't have the  
source mechanism, so maybe the syntax should make it clear that it's  
media-specific.


e.g.:

MEDIA
kittens.webm video/webm; codecs=...
kittens.mp4 video/mp4; codecs=...

# one MEDIA block per resource?

This doesn't include the media= attribute of source, but I think that  
should be dropped from the element anyway.


Something similar could be done for img srcset, maybe, which is a  
different beast than source.


It's a bit verbose, but it's a lot less verbose than loading the content  
twice.





--
Simon Pieters
Opera Software



Re: [editing] defaultParagraphSeparator

2013-03-18 Thread Simon Pieters
On Tue, 05 Feb 2013 01:41:14 +0100, Alex Mogilevsky  
alex...@microsoft.com wrote:



± From: Pablo Flouret [mailto:pab...@motorola.com]
± Sent: Monday, February 4, 2013 12:47 PM
±
± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky  
alex...@microsoft.com

± wrote:
±
±  There was a discussion here a while ago on desired default behavior
±  for Enter in contenteditable and options for
±  execCommand(defaultParagraphSeparator):
±   
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thre

±  ad.html#msg171
± 
±  Did it ever get to consensus? Or is there new thinking on how that
±  should work?
±
± I implemented this in Opera and WebKit[1], can't really tell from the
± bugzilla bug if it's in firefox too[2], but i think they were on board  
as

± well.
±
± [1] https://bugs.webkit.org/show_bug.cgi?id=59961
± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303

The Editing API document flags defaultParagraphSeparator as having  
issues, some are mentioned in the document and more raised in the  
discussion. Such as


* default value (currently 'p', but not consistent in implementations)


Opera used p for compat with IE, though I don't have a strong opinion  
about what the default should be, so long as we all do the same thing.


* default styles (if 'p' is default, it adds default 1em margin before  
first line, which most people consider undesirable)


The undesirable style is basically the reason we implemented this in  
Opera. We didn't want to just use div by default because it was  
considered risky compat-wise.


* when should Enter insert a line break instead of block (e.g. when  
inside pre)?


Isn't this defined in the spec?
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command


* can/should the default block be set per editable area and how?


This is not specific to defaultparagraphseparator but applies to many  
commands, and there has been a proposal to expose execCommand on elements.



* why only 'p' and 'div'?


Only p and div addresses the use case of p having undesirable style.

If there is a chance to settle on what's right for any of these, it  
would be awesome.


Alex

[1]  
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-defaultparagraphseparator-command



--
Simon Pieters
Opera Software



Re: [editing] defaultParagraphSeparator

2013-03-18 Thread Simon Pieters
On Sat, 09 Feb 2013 02:11:41 +0100, Alex Mogilevsky  
alex...@microsoft.com wrote:



± From: Pablo Flouret [mailto:pab...@motorola.com]
± Sent: Monday, February 4, 2013 12:47 PM
±
± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky  
alex...@microsoft.com

± wrote:
±
±  There was a discussion here a while ago on desired default behavior
±  for Enter in contenteditable and options for
±  execCommand(defaultParagraphSeparator):
±   
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thre

±  ad.html#msg171
± 
±  Did it ever get to consensus? Or is there new thinking on how that
±  should work?
±
± I implemented this in Opera and WebKit[1], can't really tell from the
± bugzilla bug if it's in firefox too[2], but i think they were on board  
as

± well.
±
± [1] https://bugs.webkit.org/show_bug.cgi?id=59961
± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303

I can't find any documentation for any of the implementations, perhaps  
you could answer if the following is true:


* The command name is defaultParagraphSeparator, unprefixed


In Presto, it's opera-defaultblock (we implemented it before it was in  
the spec).



* Argument is case insensitive
* The only available options are P and DIV
* Default is P


In Presto, yes.


Is that correct?

Thanks
Alex



--
Simon Pieters
Opera Software



Re: Monkeypatching document.createElement() is wrong

2013-03-18 Thread Simon Pieters
On Tue, 12 Feb 2013 12:24:59 +0100, Anne van Kesteren ann...@annevk.nl  
wrote:



If the goal of custom elements is to expose the guts of what happens
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
is the wrong solution. Currently new Image() and createElement(img)
are equivalent and no additional magic is required. Same for new
Audio() and createElement(audio).


Not quite, actually. new Audio() sets the content attribute preload=auto.

--
Simon Pieters
Opera Software



Re: RfR: Web Workers Test Cases; deadline March 28

2013-03-15 Thread Simon Pieters
 (in the window context). The worker should not return true  
in onerror for these tests.


The column member of ErrorEvent is not tested.

http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/Worker_cross_origin_security_err.htm

This test is wrong, data: should not throw per spec.

http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/Worker_dispatchEvent_ErrorEvent.htm

This test is wrong, initErrorEvent was removed from the spec and replaced  
with event constructors. The test should check that initErrorEvent is  
*absent* and that the constructor works.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/postMessage_clone_port.htm

test(function(){ assert_equals(e.data, ping); }, Data  
sent through remote port is received by the new cloned port);


This should create the test object up-front with async_test and do a  
step() here instead. Otherwise, if something fails before this code runs,  
there will be no test object at all, and that would be confusing when  
looking at the recorded results.


Alternatively, if it doesn't need to be a separate test, it can just do a  
step of the first test.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/postMessage_ports_readonly_array.htm

The bulk of the code should be in a step() since if e.g. `new   
MessageChannel()` throws, the harness doesn't catch it. This probably  
applies to most tests.


The postMessage tests appear to be testing MessageChannel rather than  
workers.


--
Simon Pieters
Opera Software



Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

2013-03-14 Thread Simon Pieters

On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky bzbar...@mit.edu wrote:

And if so, which objects should they be on?  Window?  Documents?   
Elements?


Currently event handlers are available on all of Window, Document and  
HTMLElement even if the relevant event just fires on one of them, so I  
suggest we do that.


--
Simon Pieters
Opera Software



Re: Review of the template spec

2012-12-14 Thread Simon Pieters

On Fri, 14 Dec 2012 00:04:20 +0100, Jonas Sicking jo...@sicking.cc wrote:


On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen hsivo...@iki.fi wrote:
1. If DOCUMENT does not have a browsing context, Let TEMPLATE CONTENTS  
OWNER be DOCUMENT and abort these steps.
2. Otherwise, Let TEMPLATE CONTENTS OWNER be a new Document node that  
does not have a browsing context.


Is there a big win from this inconsistency? Why not always have a
separate doc as the template contents owner?


Or why not always use the owner document of the template element?


I think that would cause things like img elements to load.


Documents are fairly heavy-weight and introducing several documents
into the mix means that we have to deal with issues like making sure
that those documents have the same behavior (for example, if HTML
elements in those documents uppercase the nodeName or not)

/ Jonas



--
Simon Pieters
Opera Software



Re: [webcomponents] More backward-compatible templates

2012-11-02 Thread Simon Pieters

On Fri, 02 Nov 2012 22:41:22 +0200, Adam Barth w...@adambarth.com wrote:

I'm not sure offhand of the parsing behavior of xmp. Will it prevent  
the contents from being parsed as tags?


Yes.  xmp is basically ![CDATA[...]] for HTML.


There are differences, though:

* it closes p
* default style is display: block; margin-top: 1em; margin-bottom: 1em;  
font-family: monospace; white-space: pre; unicode-bidi: isolate;


--
Simon Pieters
Opera Software



Re: Scrolling when document.documentElement requests fullscreen

2012-09-07 Thread Simon Pieters
On Fri, 07 Sep 2012 01:32:07 +0200, Chris Pearce cpea...@mozilla.com  
wrote:


We've had a couple of bugs filed against Gecko recently about scrolling  
fullscreen content.


Currently behaviour differs between Chrome and Gecko when fullscreen is  
requested on document.documentElement. When this happens Chrome still  
shows the viewport/browser scrollbars, but Gecko does not show viewport  
scrollbars.


For example, compare the behaviour of  
http://robnyman.github.com/fullscreen/index-high-content.html in Chrome  
and Firefox.


Our developer evangelists tells us that authors intuitively expect  
scrollbars when requesting fullscreen on document.documentElement.  
Authors expect that since the document is scrollable (via the viewport  
scrollbars) before entering fullscreen it should remain scrollable after  
entering fullscreen.


Gecko does not show viewport scrollbars when requesting fullscreen on  
document.documentElement since the :fullscreen psuedoclass's  
position:fixed positioning styles cause it to be unscrollable. I don't  
know why Chrome shows scrollbars in this case.


We're proposing in the relevant Mozilla bug [1] to change our  
implementation so that the :fullscreen pseudoclass rule is :not(:root).  
This would mean that document.documentElement would still be scrollable  
after entering fullscreen, which would then match authors' expectations.


i.e.:

*|*:not(:root):fullscreen {
position: fixed;
top:0; right:0; bottom:0; left:0;
/* etc... */
}

Before I make this change in Gecko I'd like to get consensus from other  
implementers that we want this behaviour, and get the spec changed to  
reflect that.


Sounds good to me.



Regards,
Chris Pearce.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=779286#c18



--
Simon Pieters
Opera Software



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Simon Pieters
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



(12/06/18 22:45), Simon Pieters wrote:

I think we should instead either fix the old API (if it turns out to not
Break the Web) or live with past mistake (if it turns out it does). To
find out whether it Breaks the Web (and the breakage can't be evanged),
I suggest we ship the backwards-incompatible change to querySelector()
in nightly/aurora (or equivalent) in one or more browsers for some time.


I didn't read through all the QSA threads, but isn't the function name
itself a mistake that many people don't want to live with?


We have lots of shipped APIs with worse names. I think we should live with  
past mistakes, try not to make them again, and move on.


--
Simon Pieters
Opera Software



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-18 Thread Simon Pieters
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



1. Explicitly undefine this case.


That would not be my preference.



2. Spec IE9, Firefox13 and Opera12alpha's behavior

Roughly speaking, the choice is an invalid token or '|' whichever comes
first, but I'd note that in the corner case


These are valid:

|a
*|a


My proposed spec change:


  # If the group of selectors include namespace prefixes that need to
  # be resolved, the implementation must raise a NAMESPACE_ERR
  # exception.


s/NAMESPACE_ERR/SYNTAX_ERR/

--
Simon Pieters
Opera Software



[selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Simon Pieters
So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods  
find() and findAll() in addition to querySelector() and querySelectorAll()  
and changes the scoping behavior for the former methods to match what  
people expect them to do.


I'm not convinced that doubling the API surface is a good idea. If we were  
to do that every time we find that a shipped API has suboptimal behavior,  
the API surface on the Web would grow exponentially and we wouldn't make  
the overall situation any better. What if we find a new problem with  
find() after it has shipped? Do we introduce yet another method?


I think we should instead either fix the old API (if it turns out to not  
Break the Web) or live with past mistake (if it turns out it does). To  
find out whether it Breaks the Web (and the breakage can't be evanged), I  
suggest we ship the backwards-incompatible change to querySelector() in  
nightly/aurora (or equivalent) in one or more browsers for some time.


--
Simon Pieters
Opera Software



Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

2012-06-01 Thread Simon Pieters
On Fri, 01 Jun 2012 11:02:43 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



 | If its specified 'position' is 'static', it computes to 'absolute'.


What if position is not specified?


Everything's specified.

http://www.w3.org/TR/CSS21/cascade.html#specified-value



Other comments:

 #  *|*:fullscreen {
 #  position:fixed;
 #  top:0; right:0; bottom:0; left:0;
 #  margin:0;

Shouldn't that be margin: auto? I'd've assumed you'd want replaced  
elements

centered by default.


No because width/height are set as well. We should maybe set another
property for replaced elements. content-fit or some such.


Do you mean object-fit? I guess it would be nice for images to be  
object-fit:contain in fullscreen. (Videos already are.)


--
Simon Pieters
Opera Software



Re: Proposal: add websocket close codes for server not found and/or too many websockets open

2012-06-01 Thread Simon Pieters
On Fri, 01 Jun 2012 21:33:47 +0200, Jason Duell jduell.mcb...@gmail.com  
wrote:



On 05/28/2012 04:03 AM, Takeshi Yoshino wrote:
The protocol spec has defined 1015, but I think we should not pass  
through it to the WebSocket API.

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0437.html

I think 1006 is the right code for all of WebSocket handshake failure,  
TLS failure and TCP connection failure. If the language in  
http://tools.ietf.org/html/rfc6455#section-7.4.1 is not good, we can  
add cannot be opened or before closed abnormally for clarification.


I could certainly live with this.  It would be nice to have it clarified  
in the W3C websocket spec that we won't be delivering 1015 (I assume  
it's too late to take it out of RFC 6455).


You can submit errata, but should probably raise it on hybi first.

And to have the additional language you suggest for 1006 (connection  
could not be opened or something like that) added somewhere (again I  
assume RFC 6455 isn't possible, but the IANA database and/or the W3C  
spec).


As above.


best,

Jason
Mozilla



--
Simon Pieters
Opera Software



Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

2012-05-25 Thread Simon Pieters
On Fri, 25 May 2012 09:01:43 +0200, Rafael Weinstein rafa...@google.com  
wrote:


Ok, so from consensus on earlier threads, here's the full API   
semantics.


Now's the time to raise objections to UA's adding support for this  
feature.


-

1) The Document interface is extended to include a new method:

DocumentFragment parse (DOMString markup);

which:
-Invokes the fragment parsing algorithm with markup and an empty
context element,
-Unmarks all scripts in the returned fragment node as already started
-Returns the fragment node

2) The fragment parsing algorithm's context element is now optional.

It's behavior is similar to the case of a known context element, but
the tokenizer is simply set to the data state

3) Resetting the insertion appropriately now sets the mode to Implied
Context if parsing a fragment and no context element is set, and
aborts.

4) A new Implied Context insertion mode is defined which

-Ignores doctype, end tag tokens
-Handles comment  character tokens as if in body
-Handles the following start tags as if in body (which is as if in
head): style, script, link, meta
-Handles any other start tag by selecting a context element, resetting
the insertion mode appropriately and reprocessing the token.

5) A new selecting a context element algorithm is defined which
takes a start tag as input and outputs an element. The element's
identity is as follows:

-If start tag is tbody, thead, tfoot, caption or colgroup
  return table
-if start tag is tr,
  return tbody
-if start tag is col
  return colgroup
-if start tag is td or td
  return tr
-if start tag is head or body
  return html
-if start tag is rp or rt
  return ruby


I think ruby is better handled by always making rp and rt generate  
implied end tags in the fragment case (maybe even when parsing normally,  
too). Making the context element ruby still doesn't make rt parse  
right, because the spec currently looks for ruby on the *stack* (and the  
context element isn't on the stack).


Also, the ruby base is allowed to include markup, so this would fail:

ruby.appendChild(document.parse('spanfoo/spanrtbarrtbaz'));



-if start tag is a defined SVG localName (case insensitive)
  return svg


Except those that conflict with HTML?


-if start tag is a defined MathML localName (case insensitive)
  return math


(Making the context element svg or math doesn't do anything currently:  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 )



-otherwise, return body



--
Simon Pieters
Opera Software



Re: Proposal: add websocket close codes for server not found and/or too many websockets open

2012-05-23 Thread Simon Pieters
On Wed, 23 May 2012 06:21:21 +0200, Jason Duell jduell.mcb...@gmail.com  
wrote:


On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters sim...@opera.com  
wrote:



  4.  If the connection could not be opened, either because a direct
  connection failed or because any proxy used returned an error,
  then the client MUST _Fail the WebSocket Connection_ and abort
  the connection attempt.

  I'm also wondering if it would be useful to have a dedicated
error code for this case (server not available').


I believe it would be a security problem to expose to scripts detailed
reasons about how it failed to connect.


Could you say more about why a simple connection not available would
be a security problem, Simon?


Earlier drafts of the WebSocket Protocol had the following requirement (I  
don't know why it was removed; I stopped following hybi):


   User agents must not convey any failure information to scripts in a
   way that would allow a script to distinguish the following
   situations:

   o  A server whose host name could not be resolved.

   o  A server to which packets could not successfully be routed.

   o  A server that refused the connection on the specified port.

   o  A server that did not complete the opening handshake (e.g. because
  it was not a WebSocket server).

   o  A WebSocket server that sent a correct opening handshake, but that
  specified options that caused the client to drop the connection
  (e.g. the server specified an origin that differed from the
  script's).

   o  A WebSocket server that abruptly closed the connection after
  successfully completing the opening handshake.


I believe the problem is related to wanting to not expose information  
about stuff behind the user's firewall, more than can be exposed with  
other Web features already. Pre-WebSocket features don't expose  
connection not available vs other reasons for failure, if I'm not  
mistaken, so WebSocket shouldn't either to be on the safe side.



 We already have a code for the special
case of TLS handshake failing:


Maybe we shouldn't. (Same argument as above.)



a code that encompasses every other
reason why the connection wasn't made doesn't seem obviously risky to
me (but I'm no security expert)..


Also:  I expect every browser that implements web sockets will have
some limit on the number of websockets it allows to be open at once
(to prevent DoS attacks if nothing else).



The spec has a simple measure against DoS -- only allowing one socket in
the connecting state at a time per host (or some such). But there can be
platform-specific limitations.


True, but this doesn't protect against running out of file descriptors
for sockets, etc.


Indeed.


So while it's not an easy DoS vector, it's still a
possible scenario.  For now, Firefox is calling onerror and onclose
with 1011 in this case (internal error, though it's a loose
application of the code, since its intended to be sent by the remote
endpoint rather than used for internal errors in the client).  I could
probably be persuaded to throw an exception instead--in fact, I'm
almost convincing myself of it as I type :)(We made the decision
not to queue the connection, because WS's are long-lived and there's
thus no obvious wait time bounds).


OK. Exception works for me. It would be good if the WebSocket API spec  
said to throw (and what to throw) for this scenario.



Thanks for the feedback.

Jason Duell
Mozilla



--
Simon Pieters
Opera Software



Re: Proposal: add websocket close codes for server not found and/or too many websockets open

2012-05-21 Thread Simon Pieters
On Wed, 16 May 2012 02:17:45 +0200, Jason Duell jduell.mcb...@gmail.com  
wrote:



So the Web Socket spec is a little vague on how JS is notified when
the targeted web socket server is down/nonexistent/etc.

Firefox is firing an 'error' event when this happens, based on the
language here in the W3C spec:

  if the status code received from the server is not 101 (e.g. it is
a redirect), the user agent must fail the websocket connection

Chrome is not calling onerror for this, so we have a difference here.
 The language in the spec isn't really clear if this covers the
connection-never-happened case.

Both Chrome and Firefox (haven't tested other browsers/clients) are
then calling close with code=1006, which seems the best code available
in RFC 6455, but the language there isn't great either:

   to indicate that the connection was closed abnormally, e.g.,
without sending or receiving a Close control frame.

There's essentially no mention in either spec of what happens when
there never was any connection to the server..

It would be useful to be clear about whether onerror should be called
here.   I'm also wondering if it would be useful to have a dedicated
error code for this case (server not available').


I believe it would be a security problem to expose to scripts detailed  
reasons about how it failed to connect.




Also:  I expect every browser that implements web sockets will have
some limit on the number of websockets it allows to be open at once
(to prevent DoS attacks if nothing else).


The spec has a simple measure against DoS -- only allowing one socket in  
the connecting state at a time per host (or some such). But there can be  
platform-specific limitations.




  I'm not sure of what the
right close code for this is.  Ideas?  Perhaps we could also use a
dedicated code for this case too.


Or throw an exception? Or queue the connection? I've touched on this  
subject before, but we didn't reach any conclusion as to what the right  
thing to do is.




Jason Duell
Mozilla




--
Simon Pieters
Opera Software



Re: Proposal: add websocket close codes for server not found and/or too many websockets open

2012-05-21 Thread Simon Pieters

On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters sim...@opera.com wrote:

On Wed, 16 May 2012 02:17:45 +0200, Jason Duell  
jduell.mcb...@gmail.com wrote:



So the Web Socket spec is a little vague on how JS is notified when
the targeted web socket server is down/nonexistent/etc.

Firefox is firing an 'error' event when this happens, based on the
language here in the W3C spec:

  if the status code received from the server is not 101 (e.g. it is
a redirect), the user agent must fail the websocket connection

Chrome is not calling onerror for this, so we have a difference here.
 The language in the spec isn't really clear if this covers the
connection-never-happened case.

Both Chrome and Firefox (haven't tested other browsers/clients) are
then calling close with code=1006, which seems the best code available
in RFC 6455, but the language there isn't great either:

   to indicate that the connection was closed abnormally, e.g.,
without sending or receiving a Close control frame.

There's essentially no mention in either spec of what happens when
there never was any connection to the server..


   4.  If the connection could not be opened, either because a direct
   connection failed or because any proxy used returned an error,
   then the client MUST _Fail the WebSocket Connection_ and abort
   the connection attempt.

_Establish a WebSocket Connection_ in rfc6455



It would be useful to be clear about whether onerror should be called
here.   I'm also wondering if it would be useful to have a dedicated
error code for this case (server not available').


I believe it would be a security problem to expose to scripts detailed  
reasons about how it failed to connect.




Also:  I expect every browser that implements web sockets will have
some limit on the number of websockets it allows to be open at once
(to prevent DoS attacks if nothing else).


The spec has a simple measure against DoS -- only allowing one socket in  
the connecting state at a time per host (or some such). But there can be  
platform-specific limitations.




  I'm not sure of what the
right close code for this is.  Ideas?  Perhaps we could also use a
dedicated code for this case too.


Or throw an exception? Or queue the connection? I've touched on this  
subject before, but we didn't reach any conclusion as to what the right  
thing to do is.




Jason Duell
Mozilla







--
Simon Pieters
Opera Software



Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Simon Pieters
On Wed, 09 May 2012 22:32:08 +0200, Scott González  
scott.gonza...@gmail.com wrote:



Perhaps I'm missing something, but isn't foocaptionbar/caption an
invalid use case? Any top-level element that needs a context can't be  
mixed

with a text node. Are there cases where this isn't true?


foo tspanbar/tspan baz

--
Simon Pieters
Opera Software



Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-09 Thread Simon Pieters

On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:



Quick alternative proposal that might work for both template parsing  
and

DocumentFragment.innerHTML:

   Have createDocumentFragment() take as an argument a context element.
   Maybe also make it a mutable attribute of the object. Defaults to its
   owner document's body element or root element or some such. Null means
   no root element.

 var df = document.createDocumentFragment(document.body);
 df.contextElement = document.createElement('style');


Or just string with the tag name, so it works the same as template  
context?



   Have innerHTML use that as the context element to the fragment parsing
   algorithm.

 df.innerHTML = 'p::before { content: 'hello world'; }';

   Have template take an argument that's the element tag name for it to
   use to create its context element. Defaults to body.
template context=tr td /template
 template context=svg g/ /template

   Parse template by creating a new Document object that's like the  
ones

   you get from createDocument() (i.e. dead), and then creating a
   DocumentFragment owned by that Document, and then pushing that
   DocumentFragment onto the stack instead of the template element, but
   set up to act like the template element for the purposes of being
   popped off. (Except when parsing without a browsing context, then you
   just parse normally.)

Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)




--
Simon Pieters
Opera Software



Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-09 Thread Simon Pieters

On Wed, 09 May 2012 19:29:42 +0200, Ryosuke Niwa rn...@webkit.org wrote:


On May 9, 2012 10:26 AM, Simon Pieters sim...@opera.com wrote:


On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:



Quick alternative proposal that might work for both template parsing

and

DocumentFragment.innerHTML:

  Have createDocumentFragment() take as an argument a context element.
  Maybe also make it a mutable attribute of the object. Defaults to its
  owner document's body element or root element or some such. Null  
means

  no root element.

var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');



Or just string with the tag name, so it works the same as template

context?

What happens when I pass a?


I think that should get in body. Do we need to support anything more  
than svg and math to get foreign content parsing here?


--
Simon Pieters
Opera Software



Re: [IndexedDB] Checked in fix for ReSpec issue

2012-05-03 Thread Simon Pieters

On Thu, 03 May 2012 07:56:49 +0200, Jonas Sicking jo...@sicking.cc wrote:

On Wed, May 2, 2012 at 2:07 PM, Anne van Kesteren ann...@opera.com  
wrote:
On Wed, 02 May 2012 13:46:27 -0700, Jonas Sicking jo...@sicking.cc  
wrote:


I certainly agree that it would be better to move the definition of
when to throw exceptions into the prose for each function and
attribute, but that's a big change that I don't think we should block
on. (In fact, it might be big enough that we don't want to take it on
at all, but that's something we shouldn't decide on here).


Is the order of exceptions defined? E.g. if a method can throw two  
different
exceptions and you violate both requirements, which exception throws?  
That's

one of the minor problems this legacy DOM-style gives.


I suspect that's not always defined no. It doesn't seem like a huge
deal, but it's definitely another argument for moving away from
depending on the current style.


Yes, I would much prefer if specs currently using ReSpec moved towards  
using algorithms like the HTML spec. It's much clearer and is less likely  
to have gaping holes for edge cases.


--
Simon Pieters
Opera Software



Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-04-26 Thread Simon Pieters
On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com  
wrote:



Here's the approach for picking the implied context element:

Let the first start tag token imply the context element. The start tag
= implied context element is as follows:

caption, colgroup, thead, tbody, tfoot = HTMLTableElement
tr = HTMLTableBodyElement
col = HTMLColGroupElement
td, th = HTMLTableRowElement
head, body = HTMLHTMLElement
rp, rt = HTMLRubyElement
Any other HTML tagName = HTMLBodyElement


Isn't this one redundant with the last step?


Any other SVG tagName = SVGElement
Any other MathML tagName = MathElement


What are these two, exactly? The parser currently doesn't have a list of  
SVG/MathML tag names, and the SVG WG didn't like it when it was proposed  
to use a fixed list of SVG tag names for parsing SVG in text/html, IIRC.


Also note that innerHTML on non-HTML elements currently always parses in  
the in body insertion mode. I'd like to see that fixed before we try to  
support foreign content in contextless innerHTML.


https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635


Any other tagName = HTMLBodyElement


--
Simon Pieters
Opera Software



Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer

2012-04-13 Thread Simon Pieters

On Thu, 12 Apr 2012 22:11:38 +0200, Eric U er...@google.com wrote:

On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren ann...@opera.com  
wrote:
On Thu, 12 Apr 2012 21:48:12 +0200, Boris Zbarsky bzbar...@mit.edu  
wrote:


Because it's still in the current editor's draft and it's still in the
Gecko code and I was just reviewing a patch to it and saw the API?  ;)



Eric, the plan is to remove that from File Writer, no?


Yes.  The next draft I publish will mark it deprecated, and it will
eventually go away.


Please just remove it from the spec directly. If implementors feel they  
want to keep it around for a while longer, that's up to them, but the spec  
should describe the end goal.


As for implementations, it's usually simpler to remove features earlier  
than to wait a while and hope it will be possible to remove it later. The  
longer a feature is exposed on the Web, the more content will end up  
relying on it.



 However, currently at least Gecko and WebKit
support BlobBuilder, and WebKit doesn't yet have the Blob constructor,
so it'll be a little while before it actually fades away.

That being said, we should be talking about making this addition to
Blob, not to BlobBuilder.


I thought we discussed long ago it should be removed in favor of a
constructable(sp?) Blob?



Could be.  Like I said, it's still in the editor's draft.



Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/




Also, should it not accept just ArrayBufferView then as per
XMLHttpRequest?



Is there existing content depending on BlobBuilder and its  
ArrayBufferView

stuff?



I thought the idea was to not have BlobBuilder at all.



--
Anne van Kesteren
http://annevankesteren.nl/



--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Simon Pieters

On Wed, 11 Apr 2012 07:56:48 +0200, Jonas Sicking jo...@sicking.cc wrote:


On Tue, Apr 10, 2012 at 10:44 PM, David Levin le...@google.com wrote:

What is the backwards compatibility story for websites already using
SharedWorkers with the interface that has been in the spec for over a  
year

now?

There are sites using them. For example, Google Docs uses them and  
Google

Web Toolkit exposes them.


Either we get them updated to the new API or we keep ports[0] around for  
compat. If we can't get rid of ports[0], I see less value in making the  
change at all since some scripts will use .source and other will use  
.ports[0], which seems pretty confusing.


Google Docs can hopefully be updated before implementations ship with  
this, but GWT might be more problematic since there may be legacy apps  
around with unknown update shedule...



As far as I can see there are no backwards compat breaking changes
proposed. Are there any particular parts you are worried about?


I proposed setting ports to null.

--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Simon Pieters

On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking jo...@sicking.cc wrote:


I would prefer to expose the port through .source even if we can't get
rid of .ports[0] right now.


I think the longer we wait with removing it, the more legacy will be  
created that relies on its existence.



The ports property is basically useless
right now except for this one instance and so while I agree that there
might be some confusion in the short term, it doesn't seem like it
would be a compatibility problem, and long term it seems like a win
that authors wouldn't have to worry about the property at all. It
might continue to work if we decide that it's needed for back compat,
but it seems like we eventually would be able to get rid of it given
how new the property still is.

/ Jonas



--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Simon Pieters
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org  
wrote:



On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:


On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:

 Sounds great to me. The ports attribute is basically useless except in

this
one instance since ports are these days expose as part of structured
clones.

Avoiding using it in this arguably weird way in this one instance seems
like a win to me.



I'd like to have an opinion from WebKit and Microsoft about this  
proposal.

Can someone comment or cc relevant people, please?



FWIW this to me seems like a good improvement to the intuitiveness.


OK. To make things clear, are you OK with making this change in WebKit?


Since
a MessageEvent interface is being used, qualifying that *source*  
WindowProxy

is populated is all that's needed?


It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The  
IDL for MessageEvent's source member would need to change type from  
WindowProxy? to object?.






cheers


 / Jonas


On Wednesday, April 4, 2012, Simon Pieters wrote:

 Hi,


In Opera Extensions we use something that resembles shared workers.  
One

modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.

I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.

What do people think?

currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }

proposed change:
onconnect = function(e) { e.source.postMessage('pong') }

--
Simon Pieters
Opera Software





--
Simon Pieters
Opera Software





--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Simon Pieters
On Tue, 10 Apr 2012 20:26:04 +0200, Travis Leithead  
travis.leith...@microsoft.com wrote:


IE10 does not implement SharedWorkers at the present time. We also don’t  
yet implement the updated Transferrable notion for MessagePorts in the  
structured clone algorithm.


Ah, OK.

We do ship Workers now, and so my primary concern is that the spec  
doesn't remove the ports property of the MessageEvent.


Yep, I'm not suggesting to remove it.

I don't mind the proposal to re-use .source of MessageEvent for a  
connect event on a SharedWorker. I think it's a bit ugly to swap the  
WindowProxy type of .source to any just for this case.


Anne said the type could be (WindowProxy or MessagePort)?.

I am curious to see where this latest discussion on perhaps using a  
different Event interface for connect events will lead...


--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Simon Pieters
On Tue, 10 Apr 2012 19:33:55 +0200, Andrew Wilson atwil...@google.com  
wrote:



I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect  
event

to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).


I don't see the problem with using MessageEvent for connect.


I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event makes it closer to the [cross-document messaging] API -  
can

you clarify your reasoning here?


The code you write looks more like in cross-document messaging:

// cross-document messaging:
// I can get a message event from several places
onmessage = function(e) {
  // post a pong message back
  e.source.postMessage('pong', '*');
}

// shared workers:
// I can get a connect event from several places
onconnect = function(e) {
  // post a pong message back
  e.source.postMessage('pong');
}

The author doesn't need to care that e.source are different objects in the  
two cases, they only need to care that it exposes a postMessage method  
that they can use to communicate back.



Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them  
as
the same by putting them both as the |source| attribute in MessageEvents  
in
different contexts, especially since the postMessage() APIs don't  
precisely

match.


Hey, we use MessageEvent in lots of different contexts with different  
semantics -- cross-document messaging, workers, shared workers,  
EventSource, WebSocket... I don't think making this change to shared  
workers is going to invalidate the usage of MessageEvent.


On Tue, 10 Apr 2012 19:47:12 +0200, Andrew Wilson atwil...@google.com  
wrote:



To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
changed to support object transfers after we defined the connect event
structure, so it's not unreasonable that we should take another look at  
the

connect event to try to make it match the current definition of
postMessage().

I think the model of connect event we've used in the past
(pre-structure-clone-transfer) is as if the creator of the SharedWorker
were sending a message like so:

postMessage(, [newPort]);

The recipient then receives a MessageEvent with data= and  
ports=[newPort].


In the new world where postMessage() supports a transfer object, I think
the appropriate analogous connect event would be to result in a
MessageEvent with both the |data| and |ports| attributes pointing at an
array containing a single MessagePort. I don't think putting the
MessagePort as the source attribute is the right model.


I don't think authors think of it in this way.

--
Simon Pieters
Opera Software



Re: Shared workers - use .source instead of .ports[0] ?

2012-04-09 Thread Simon Pieters

On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc wrote:

Sounds great to me. The ports attribute is basically useless except in  
this
one instance since ports are these days expose as part of structured  
clones.


Avoiding using it in this arguably weird way in this one instance seems
like a win to me.


I'd like to have an opinion from WebKit and Microsoft about this proposal.  
Can someone comment or cc relevant people, please?


cheers


/ Jonas

On Wednesday, April 4, 2012, Simon Pieters wrote:


Hi,

In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.

I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.

What do people think?

currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }

proposed change:
onconnect = function(e) { e.source.postMessage('pong') }

--
Simon Pieters
Opera Software





--
Simon Pieters
Opera Software



Shared workers - use .source instead of .ports[0] ?

2012-04-04 Thread Simon Pieters

Hi,

In Opera Extensions we use something that resembles shared workers. One  
modification is that the 'connect' event's source port is exposed in  
.source instead of in .ports[0], to make it closer to the API for  
cross-document messaging. Maybe we should make this change to Shared  
Workers as well.


I think shared workers hasn't seen wide adoption yet, so maybe changes  
like this are still possible.


What do people think?

currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }

proposed change:
onconnect = function(e) { e.source.postMessage('pong') }

--
Simon Pieters
Opera Software



Re: [XHR] Constructor behavior seems to be underdefined

2012-04-02 Thread Simon Pieters

On Mon, 02 Apr 2012 07:50:21 +0200, Boris Zbarsky bzbar...@mit.edu wrote:


On 4/2/12 1:33 AM, Simon Pieters wrote:

Yes, but what do they use for the origin of the Worker object itself?


Run a worker for the resulting absolute URL, with the script's browsing
context of the script that invoked the method as the owner browsing
context, with the script's document of the script that invoked the
method as the owner document, with the origin of the entry script as the
owner origin, and with worker global scope as the global scope.
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-worker

Well, that's origin for the worker *script*.


Yes, that's not the same thing.


The Worker *object* doesn't have an origin, I think.


Well, what controls which scripts can touch the Worker object?  That  
should be controlled by the origin of the window or document it's  
associated with, but the spec doesn't define what that is.



I.e. if you create one and then one of the documents involved has
.domain set on it, what happens?


The document's effective script origin changes. The origin doesn't.


Sure.


Workers use origin, not effective script origin, so setting
document.domain should have no effect on workers even if you set it
before creating the worker.


I think you're missing my point.

Say I have two documents d1 and d2, in windows w1 and w2 respectively.  
These are same-effective-origin (whether because they started that way  
or because both set document.origin to the same thing doesn't matter).  
Assume script in w1 has a reference to w2 (e.g. w2 is in a subframe).


Script running in w1 does:

   var worker = new w2.Worker(some_url);

Then script in w2 changes d2.origin, which changes the effective origin  
of w2 and d2.  What happens to script that runs later on in w1 and tries  
to call a method on |worker|?


For comparison, if Worker is replaced with Image in the above scenario,  
the correct answer is a security exception is thrown because for  
purposes of touching the image object itself what matters is whether the  
effective origin of the script that's running matches the effective  
origin of the image's ownerDocument.  Not that the spec actually says  
this anywhere that I can tell...



http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0
has rules for specific things.


Yes, that's talking about a different thing entirely (e.g. for images  
this defines an origin for the image _data_, not for the image object  
itself; the two can obviously differ when the image load is not  
same-origin with the page the img tag is in).


Perhaps the spec terminology for the thing I'm after here is effective  
script origin?  That seems to be what it uses for Document.  But maybe  
it only does that so it can define it for scripts by reference to the  
document that loaded them?


In any case, the concept I'm after is the thing that determines whether  
script at a particular effective script origin can touch your  
properties.  The spec (_some_ spec, at least) needs to define the value  
of this concept for all objects.  The simplest thing is to piggyback on  
the existing all objects are associated with some global bit in WebIDL  
and say that for a given object this concept has the same value as the  
global it's associated with (which is what Gecko, say, does in  
practice).  But then you have to define what the value of this concept  
is for globals (for Windows it would be the effective script origin of  
the .document, I believe) and which global each object is associated  
with (the point of this thread).


-Boris

-Boris


Ah, I see what you're saying.

I can find:

User agents must throw a SecurityError exception whenever any properties  
of a Document object are accessed by scripts whose effective script origin  
is not the same as the Document's effective script origin.

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents

and window has some rules involving effective script origin.

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object

I don't know how well this matches reality though.

It seems the spec forbids access to iframe.contentWindow.document but  
allows iframe.contentDocument.


--
Simon Pieters
Opera Software



Re: [XHR] Constructor behavior seems to be underdefined

2012-04-01 Thread Simon Pieters

On Sat, 31 Mar 2012 13:09:40 +0200, Boris Zbarsky bzbar...@mit.edu wrote:


On 3/31/12 2:15 AM, Cameron McCormack wrote:

Boris Zbarsky:

What's the document associated with xhr? Is it w1.document,
w2.document, or window.document? The concept the Window object for
which the XMLHttpRequest interface object was created doesn't seem to
be defined anywhere


I don't have a dfn for it, but
http://dev.w3.org/2006/webapi/WebIDL/#dfn-initial-object says that each
global environment has a set of interface objects, and in
http://dev.w3.org/2006/webapi/WebIDL/#es-platform-objects I use the term
associated with, but again not wrapped in a dfn.


Sure.  And the latter section says:

   It is the responsibility of specifications using Web IDL to state
   which global environment (or, by proxy, which global object) each
   platform object is associated with.

And my point is that the XHR spec doesn't state that.  Stating that the  
return value is associated with the same global environment as the  
constructor that was used to create it would do the trick.


On the other hand, maybe that should just be in WebIDL?  Are there use  
cases for constructors which create platform objects associated with a  
different global than the constructor itself?


I believe some things in the HTML spec uses the entry script, at least for  
the purpose of choosing origin or base URL. For instance: WebSocket,  
Worker.


--
Simon Pieters
Opera Software



Re: [XHR] Constructor behavior seems to be underdefined

2012-04-01 Thread Simon Pieters

On Mon, 02 Apr 2012 07:20:27 +0200, Boris Zbarsky bzbar...@mit.edu wrote:


On 4/2/12 12:58 AM, Simon Pieters wrote:

I believe some things in the HTML spec uses the entry script, at least
for the purpose of choosing origin or base URL. For instance: WebSocket,
Worker.


Yes, but what do they use for the origin of the Worker object itself?


Run a worker for the resulting absolute URL, with the script's browsing  
context of the script that invoked the method as the owner browsing  
context, with the script's document of the script that invoked the method  
as the owner document, with the origin of the entry script as the owner  
origin, and with worker global scope as the global scope.

http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-worker

Well, that's origin for the worker *script*. The Worker *object* doesn't  
have an origin, I think. (SharedWorker also uses entry script.)


I.e. if you create one and then one of the documents involved has  
.domain set on it, what happens?


The document's effective script origin changes. The origin doesn't.  
Workers use origin, not effective script origin, so setting  
document.domain should have no effect on workers even if you set it before  
creating the worker.



As far as I can tell, the HTML spec doesn't actually define this  
behavior (and for that matter it doesn't seem to define the origin of  
most objects, unless I'm missing something...)


-Boris


http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0  
has rules for specific things.


--
Simon Pieters
Opera Software



Re: WebSockets -- only TCP?

2012-03-18 Thread Simon Pieters
On Thu, 15 Mar 2012 12:28:54 +0100, Rick van Rein r...@openfortress.nl  
wrote:



Hello,

I would like to comment on the current (20120313) WebSockets
specification.

The text sounds to me like it implicitly assumes that all
protocols are run over TCP.  It could be said that the choice
of URL makes it sufficiently general to include UDP (and
possibly SCTP), but the usage of terms like connecting sends
a hint to implementers that support of TCP would suffice.

If the intention is to create a TCP-only WebSocket, then I
think this should be made explicit.  And if UDP would also
be supported, then a remark around connection states that
some apply only to connection-oriented URL protocols would
send a clearer message to implementers.

I do think UDP is too important to discard from WebSockets;
among the things we can do with current technology (Flash or
Java) is a softphone running in a browser; in a TCP-only
HTML5 environment with deprecated support for these
technologies such options would have no standing ground.


See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html



I hope this is helpful feedback.


Best wishes,

Rick van Rein
OpenFortress




--
Simon Pieters
Opera Software



Re: [FileAPI, common] UTF-16 to UTF-8 conversion

2012-02-28 Thread Simon Pieters

On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote:

If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense  
to

U+FFFD them in APIs. If the only way to get them is a JS escape, then an
exception seems OK.


People use JS strings to handle binary data. This is something that
has worked since the dawn of JS and is something that I believe is
defined to work in recent ECMAScript specs.

I don't think that we can start restricting that and try to enforce
that JS-strings always contain valid UTF16.


Right.


So I think our only option is to make all APIs which does UTF16-UTF8
conversion explicitly define how to deal with invalid surrogates.


Sure, I don't suggest we leave it undefined.


My
preference would be to deal with them by encoding them to U+FFFD for
the same reason that we let the HTML parser do error recovery rather
than XML-style draconian error handling.


I'm not really opposed to making APIs use U+FFFD instead of exception, but  
I'm not entirely convinced, either. If people use binary data in strings  
and want to use them in these APIs, U+FFFDing lone surrogates is going to  
silently scramble their data. Why is this better than throwing an  
exception?


--
Simon Pieters
Opera Software



Re: [FileAPI, common] UTF-16 to UTF-8 conversion

2012-02-27 Thread Simon Pieters

On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote:


On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:


Simon,

Is the relevant part of HTML sufficient to refer to?
http://dev.w3.org/html5/spec/Overview.html#utf-8


I was thinking of If the data argument has any unpaired surrogates, then  
throw a SyntaxError exception..  
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket-send




That defines decoding UTF-8 to Unicode strings.  You need the reverse.

Using a replacement scheme like UTF-8 decoding, instead of a hard
exception, seems more consistent with how encodings in general are
handled.  Otherwise, you'll end up with bugs in code if, for example,
people paste in unpaired surrogates (Firefox allows this, last I  
checked),


Maybe unpaired surrogates should be converted to U+FFFD on paste. Are  
there other cases?



causing unexpected exceptions in code.  Instead, just convert them to
U+FFFD, which gives much more graceful error handling for such a rare  
case

that most people will never handle explicitly.


If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to  
U+FFFD them in APIs. If the only way to get them is a JS escape, then an  
exception seems OK.



I think WebSocket should do the same, for the same reason.


Have you filed a bug?

--
Simon Pieters
Opera Software



Re: [IndexedDB] Numeric constants vs enumerated strings

2012-02-23 Thread Simon Pieters
On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal odi...@opera.com  
wrote:


On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking jo...@sicking.cc  
wrote:

Yes! I would love to make this change.
This is my main peeve with the API as it stands.


Cool! :D


I even think that implementations could remove support for the numbers
by keeping the constants but have them defined to return string
values. I.e.
db.transaction([store], IDBTransaction.READ_WRITE);
would continue to work and is the usage pattern that I've seen in all
code that I've looked at.


Ah, that is a very smart idea.


We just had the break of open() with upgradeneeded instead of  
setVersion. That's a much bigger break, and if most of us get this in  
with the same change - it can just slip nicely in. The code would have  
to change anyway. So I think it's not too hard to remove the constants  
as well. It's obviously a bit different for Mozilla, since they've  
shipped their setVersion killer already, but generally Mozilla is not  
afraid of changing stuff if they want to (and it doesn't hurt too much,  
which IMHO it won't in this case, sync XHR + CORS is much more painful  
:P).


The few people who code directly to nightly versions will be used to  
changing their code anyway.



Keep supporting the numbers is OK, but a bit strange, given the above  
reasons.  As long as it's not possible to rely on the numbers, I hope  
that developers won't use it anyway, and it'll slowly become obsolete.  
Then it can be very easily removed again. Although skipping that dance  
is of course even better ;-)



To be honest, I think authors will use the enumerated strings - so if  
some implementations do some backwards compat stuff, it'll hopefully  
become obsolete.


I think if we want the end result to be strings only, the best way to get  
there is for everyone to remove support for constants and numbers at the  
same time as they implement support for strings.


--
Simon Pieters
Opera Software



Re: Pressing Enter in contenteditable: p or br or div?

2012-01-12 Thread Simon Pieters

On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor a...@aryeh.name wrote:


On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa rn...@webkit.org wrote:

p has default margins. That alone is enough for us not to adopt p as
the default paragraph separator.


On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters sim...@opera.com wrote:
Sure, but some apps like to send their stuff in HTML email to clients  
that

don't support styling, or some such.


I used to think that this was a strong argument, but then I realized
blockquote and ol and ul have default margins too.  So if you
want it to look right, you'll have to use a stylesheet.  Also, it's
worth pointing out that recent versions of Word have margins by
default when you hit Enter.

But Simon makes a good point: for the e-mail use-case, styling might
not be available.  So this is a decent reason to support div.


Also, unfortunately, there are many legacy
contents that rely on the fact webkit uses div as the paragraph  
separator so

we need a global or per editing-host switch regardless.


This is also a good reason -- it lets preexisting apps that expect
div opt into that behavior in new browsers, instead of being
rewritten to support p.

Okay, so what API should we use?  I'd really prefer this be
per-editing host.  In which case, how about we make it a content
attribute on the editing host?  It can be a DOMSettableTokenList.
Maybe something like

  div editoptions=tab-indent

where the attribute is a whitespace-separated list of tokens.  To
start with, we can maybe have tab-indent (hitting Tab indents) and
div-separator (hitting Enter produces div).  Does this sound like a
good approach?  If so, what should we call the attribute?


Currently the editing options available, other than enabling and disabling  
contenteditable, use the execCommand API. I don't see why we should switch  
to attributes for new editing options. To make editing options per editing  
host, I prefer this proposal:


[[

Ojan suggested in the other thread that we instead allow calling
execCommand() on Element, and have the result restricted to that
Element.  That solves the global-flags problem too, and doesn't
require new attributes.  So you'd do

 div.execCommand(tabindent, false, true);

or whatever.  Someone could still call
document.execCommand(tabindent, false, false), but that would be
overridden if it was called on the editing host.  I filed a bug on it:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522

Does that sound good too?

]]


 And should
it imply contenteditable=true, or should the author have to specify
that separately?


The latter IMHO.


Also: are there any good use-cases for br?


I still haven't seen any.


Allowing div instead
of p adds basically no extra complexity, but allowing br would
make things significantly more complicated.



On Wed, 11 Jan 2012 21:15:18 +0100, Ryosuke Niwa rn...@webkit.org wrote:


 Should enter behave like shift+enter when br is the default
 paragraph separator?

Default paragraph separators are used in a couple of other places too,
so it would be a little more work than that.


Indeed, e.g. shift+enter doesn't break out of lists, so it's not  
equivalent. Making it equivalent would be adding some complexity.



But I just looked, and
it wouldn't be as bad as I thought.  So this is doable if people have
any good use-cases.



Great.


So what's the use case? :-) If none are presented, I object to adding it  
based on the Avoid Needless Complexity and Solve Real Problems design  
principles.


--
Simon Pieters
Opera Software



Re: Selection of a document that doesn't have a window

2012-01-12 Thread Simon Pieters

On Thu, 12 Jan 2012 16:58:58 +0100, Aryeh Gregor a...@aryeh.name wrote:

What does document.implementation.createHTMLDocument().getSelection()  
return?


* IE9 returns a Selection object unique to that document.
* Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
document.getSelection().
* Chrome 17 dev returns null.

I prefer IE's behavior just for the sake of simplicity.  If we go with
Gecko/WebKit/Opera, we have to decide how to identify which documents
get their own selections and which don't.  The definition should
probably be something like documents that are returned by the
.document property of some window, but I have no idea if that's a
sane way to phrase it.


HTML uses this concept in lots of places, e.g.
http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object

A Document that has no browsing context.


So should the spec follow IE?  If not, what definition should we use
to determine which documents get selections?



--
Simon Pieters
Opera Software



Re: Pressing Enter in contenteditable: p or br or div?

2012-01-11 Thread Simon Pieters

On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org wrote:


On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote:


 On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Single br tag is shorter than pairs of div tags when serialized.

True, but only slightly, and the difference is even smaller if you use
p instead of div.  This isn't enough of a reason by itself to
justify the extra complexity of another mode.  Are there other
reasons?



p has default margins.


This is why we implemented opera-defaultblock. Apps were manually  
converting our output to use divs because they didn't want margins, which  
is non-trivial to do and often leaves bugs in edge cases.



That alone is enough for us not to adopt p as
the default paragraph separator. Also, unfortunately, there are many  
legacy

contents that rely on the fact webkit uses div as the paragraph separator
so we need a global or per editing-host switch regardless.


Do you suggest that all browsers adopt div as default separator by  
default? Or that it will be impossible to reach interop? Or something  
else? :-)


I almost want a global switch to toggle between legacy UA-specific  
behavior

and new spec-compliant behavior.


That would rather miss the point of having the spec IMHO. If we all  
implement a global switch to opt in to a different behavior, let's design  
a new, sane editing API instead. But I think the editing spec should try  
to reach interop for the legacy feature first.



- Ryosuke



--
Simon Pieters
Opera Software



Re: Pressing Enter in contenteditable: p or br or div?

2012-01-11 Thread Simon Pieters

On Wed, 11 Jan 2012 10:43:24 +0100, Markus Ernst derer...@gmx.ch wrote:


p has default margins.


This is why we implemented opera-defaultblock. Apps were manually
converting our output to use divs because they didn't want margins,
which is non-trivial to do and often leaves bugs in edge cases.


Actually, applying p {margin:0} looks quite trivial.


Sure, but some apps like to send their stuff in HTML email to clients that  
don't support styling, or some such.



That would rather miss the point of having the spec IMHO. If we all
implement a global switch to opt in to a different behavior, let's
design a new, sane editing API instead. But I think the editing spec
should try to reach interop for the legacy feature first.


IMO the ability to create clean, state-of-the-art HTML code should be  
one of the main goals of a new spec. That means: Editor implementations  
should be able to get p on Enter, and br on Shift-Enter (as people  
are used to from commonly used word processors) without additional  
scripting.


That's nice but it's not clear how to go from here to there. There is web  
content that relies on quirks of each browser and might stop working  
completely if we change things. I value interop higher than clean code,  
so if, for instance, we can converge on div but not on p, then that's  
what we should spec, IMHO. (However I'm not convinced yet that it's easier  
to converge on div rather than p, which is why Opera still uses p by  
default. We have generally aimed for matching IE for contenteditable.)


I don't know the use cases Ryosuke mentions, where apps rely on  
webkit-specific behavior (or other ua-specific behaviors), and I don't  
know how harmful a change could be for them (paragraph margins appearing  
in a forum I would not consider very harmful).


It's more that a subtle change can break functionality completely in  
some apps. Even if it's just margins appearing where they didn't before,  
it might still not be accepted by many users and web developers.


On the long term, from a developer's and client supporter's POV I'd  
prefer to have a standard behavior that works the same in all UAs, and  
all common editor applications, by default.


I agree.

Offering a default paragraph separator setting means, that editor  
behaviors will remain different across applications,


It already is different across applications, because they implement the  
default paragraph separator setting themselves.



which is confusing for many users.

It might be less a hassle to have maintainers of existing applications  
insert a line of code that triggers legacy behavior, if this is crucial  
for their application.


--
Simon Pieters
Opera Software



Re: Pressing Enter in contenteditable: p or br or div?

2012-01-09 Thread Simon Pieters

On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote:


BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved

I'm OK with this conclusion, but I still strongly prefer div to be the
default single-line container name.


Why?


Also, I'd really like the default
single-line container name to be configurable in some way.


I agree.


Different apps
have different needs and it's crappy for them to have to handle enter
themselves just to get a different block type on enter.

Something like document.execCommand(DefaultBlock, false, tagName). What
values are valid for tagName are open to discussion. At a minimum, I'd  
want

to see div, p and br.


What is the use case for br that div doesn't cover?


As one proof that this is valuable, the Closure
editor supports these three with custom code and they are all used in
different apps.


Which apps use br? Could they switch to div without losing some  
functionality?



I'm tempted to say that any block type should be allowed,


I strongly disagree. Supporting any block type opens up for lots of bugs  
and weird cases. We should only support the types necessary to cover  
presented use cases.


but I'd be OK with starting with the tree above. For example, I could  
see a

use-case for li if you wanted an editable widget that only contained a
single list.


Just use ul contenteditableli|/li/ul. li as defaultblock would  
result in invalid markup if there's no list (and when breaking out of a  
list, etc).



Ojan

On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor  
simetrical+...@gmail.comwrote:



On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
 Behavior for Enter in contenteditable in current browsers seems to be
 as follows:

 * IE9 wraps all lines in p (including if you start typing in an
 empty text box).  If you hit Enter multiple times, it inserts empty
 ps.  Shift-Enter inserts br.
 * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
 always.  (What's _moz_dirty for?)
 * Chrome 12 dev doesn't wrap a line when you start typing, but when
 you hit Enter it wraps the new line in a div.  Hitting Enter
 multiple times outputs divbr/div, and Shift-Enter always inserts
 br.
 * Opera 11.10 wraps in p like IE, but for blank lines it uses
 pbr/p instead of just p/p (they render the same).

 What behavior do we want?

I ended up going with the general approach of IE/Opera:


http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements

It turns out WebKit and Opera make the insertParagraph command behave
essentially like hitting Enter, so I actually wrote all the
requirements there (IE's and Firefox's behavior for insertParagraph
was very different and didn't seem useful):


http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command

The basic idea is that if the cursor isn't wrapped in a single-line
container (address, dd, div, dt, h*, li, p, pre) then the current line
gets wrapped in a p.  Then the current single-line container is
split in two, mostly.  Exceptions are roughly:

* For pre and address, insert a br instead of splitting the element.
 (This matches Firefox for pre and address, and Opera for pre but not
address.  IE/Chrome make multiple pres/addresses.)
* For an empty li/dt/dd, destroy it and break out of its container, so
hitting Enter twice in a list breaks out of the list.  (Everyone does
this for li, only Firefox does for dt/dd.)
* If the cursor is at the end of an h* element, make the new element a
p instead of a header.  (Everyone does this.)
* If the cursor is at the end of a dd/dt element, it switches to dt/dd
respectively.  (Only Firefox does this, but it makes sense.)

Like the rest of the spec, this is still a rough draft and I haven't
tried to pin corner cases down yet, so it's probably not advisable to
try implementing it yet as written.  As always, you can see how the
spec implementation behaves for various input by looking at
autoimplementation.html:

http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph




--
Simon Pieters
Opera Software



Re: Barewords in on* attributes, redux (also, find() and company)

2011-12-14 Thread Simon Pieters

On Wed, 14 Dec 2011 08:36:44 +0100, Boris Zbarsky bzbar...@mit.edu wrote:

John Jensen here at Mozilla has been doing some web crawling trying to  
find what barewords are used in on* attributes.


Awesome!

What I have so far as a result is a list of about 1.7 million barewords  
used across several tens of thousands of pages.


Do you have a more accurate figure for the number of pages?

If people are interested in the exact methodology, I can probably get a  
description.


I'm interested. It's hard to make conclusions from data without knowing  
what the data is, how it is biased, what false positives it might have,  
etc.


I'm working on making sure that it's ok for me to post the data in its  
entirety so you can all look as well.  Assuming it is (very likely),  
where's a good place to stick a 7MB compressed file?


In any case, for this particular data set there are no hits on findAll  
or matches (good!), but there are two hits on find as a bareword in  
an on* attribute.  Specifically:


1)  http://otc-pif.rbc.ru/pif_calculator/calculator.jsp has  
onclick=find(document.getElementById(current + 'List').children,  
searchString.value)


2)  http://bookmark.people.com.cn/index.html has onclick=find()

These would both obviously get broken by the proposed find() API, unless  
we actually do some sort of workaround for this problem...


-Boris




--
Simon Pieters
Opera Software



Re: Barewords in on* attributes, redux (also, find() and company)

2011-12-14 Thread Simon Pieters

On Wed, 14 Dec 2011 09:15:12 +0100, Boris Zbarsky bzbar...@mit.edu wrote:


On 12/14/11 3:01 AM, Simon Pieters wrote:

What I have so far as a result is a list of about 1.7 million
barewords used across several tens of thousands of pages.


Do you have a more accurate figure for the number of pages?


57,444 unique urls, all taken from the top 21,000 domains is all the  
information I have there so far.


Thanks!


If people are interested in the exact methodology, I can probably get
a description.


I'm interested. It's hard to make conclusions from data without knowing
what the data is, how it is biased, what false positives it might have,
etc.


Yeah, understood.  Working on getting that description.

-Boris


cheers
--
Simon Pieters
Opera Software



Re: [FileAPI] createObjectURL isReusable proposal

2011-12-13 Thread Simon Pieters
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman  
adria...@microsoft.com wrote:



At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a blob URL
for a single use (for example, loading into an img element) and then
revoking the URL. This requires a fair amount of boilerplate code to
handle the load/error events.

createObjectURL is modified as follows:

static DOMString createObjectURL(Blob blob, [optional] bool isReusable);

The value of isReusable defaults to true if it is not supplied and this
results in the behaviour documented for File API today. However, if you
supply false for the flag then the first dereference of the URL revokes  
it.


Could the argument have inverted semantics? Optional arguments that  
default to true are a bit confusing. Usually omitted boolean arguments  
default to false.




This means that you can do something like:

imgElement.src = URL.createObjectURL(blob,false)

and not worry about having to call URL.revokeObjectURL to release the  
Blob.


We have implemented this in experimental form in IE10 preview builds and
it works well. There seemed to be a fair amount of support at TPAC and  
we're

hoping this will be adopted in the File API spec.

Thanks,

Adrian.

[1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02
[2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf





--
Simon Pieters
Opera Software



Re: XPath and find/findAll methods

2011-11-22 Thread Simon Pieters
On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com  
wrote:



Hello everyone,
I've noticed that the find/findAll methods are currently being discussed  
and there is one thing that might be a good idea to consider.


Currently, it's quite uncomfortable to use XPath in javascript. The  
document.evalute method has lots of arguments and we have to remember  
plenty of constants to make it work. IE and Opera support selectNodes  
method on NodePrototype, which is really useful, but what's the point in  
using it when it doesn't work in FF/Chrome/Safari.


Maybe FF/Chrome/Safari should add support for selectNodes?

--
Simon Pieters
Opera Software



window.find already exists

2011-11-21 Thread Simon Pieters
There's discussion about introducing find and findAll as an alternative to  
querySelector[All]. However, window.find exists already in Firefox and  
WebKit, and is for in-page text search. There's a placeholder for it in  
the spec.  
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find


Are Firefox and WebKit going to drop the old find()? Is there legacy  
content that feature detects for find() and would break if it changed  
semantics?


--
Simon Pieters
Opera Software



Re: Firefox bug: Worker load ignores Content-Type version parameter

2011-11-18 Thread Simon Pieters
On Fri, 18 Nov 2011 12:52:36 +0100, Julian Reschke julian.resc...@gmx.de  
wrote:



If Gecko does that for Workers, that would be a bug. Workers are UTF-8
only.


If you are saying that

Content-Type: application/javascript;charset=iso-8859-1

... 0xC3 0xB6 ...

should have U+00C3 U+00B6 when used viascript and an U+00F6 when used
via `new Worker` then I will stand ready to roll over the floor  
laughing
when Firefox and Chrome are changed so they conform to this bizarre  
idea

instead of doing the right thing and treating the two cases the same.


+1

The only alternative would be to *reject* the script.
...


But it seems that this is what  
http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says.


Please consider this a bug report.


UTF-8-only for workers is deliberate. I don't see any reason to reject  
scripts that have other charset. Rejecting the script would mean that some  
authors can't use workers at all because their server uses charset and  
they can't change it.


--
Simon Pieters
Opera Software



Re: Firefox bug: Worker load ignores Content-Type version parameter

2011-11-18 Thread Simon Pieters

On Fri, 18 Nov 2011 13:03:03 +0100, Boris Zbarsky bzbar...@mit.edu wrote:


On 11/19/11 12:52 AM, Julian Reschke wrote:

http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says.


For what it's worth, Gecko's worker loading code runs the same algorithm  
to determine the charset as the algorithm used for script src (except  
of course it does not have access to any charset attributes on an  
element).


And by same algorithm I mean they call the same function in our code  
which takes the HTTP headers, document object, value of @charset, and  
bytes and returns a Unicode string.


If we have UA compat on that behavior, it makes more sense to  
standardize it than to standardize the UTF-8-only thing, perhaps


Opera conforms to the spec and always decodes worker scripts as UTF-8.

--
Simon Pieters
Opera Software



Re: Firefox bug: Worker load ignores Content-Type version parameter

2011-11-18 Thread Simon Pieters
On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke julian.resc...@gmx.de  
wrote:



On 2011-11-18 13:03, Simon Pieters wrote:

UTF-8-only for workers is deliberate. I don't see any reason to reject
scripts that have other charset. Rejecting the script would mean that
some authors can't use workers at all because their server uses charset
and they can't change it.


What kind of server sets a charset on JS *and* cannot be configured not  
to?


I don't know. I know we changed appcache to not do MIME type checking of  
the cache manifest because authors had trouble changing it. I know we  
sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and  
text/plain; charset=UTF-8 because it's the default in some servers.


And, if this is the case, isn't this a good reason to actually require  
that the charset is handled correctly?


For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT,  
workers).


I really believe that piling up workarounds and inconsistencies like  
these makes the whole platform much harder to use than necessary.


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and  
character escapes. AFAIK there's have been no requests to support legacy  
encodings in workers in Opera.


--
Simon Pieters
Opera Software



Re: Firefox bug: Worker load ignores Content-Type version parameter

2011-11-18 Thread Simon Pieters
On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke julian.resc...@gmx.de  
wrote:



That's fine if you use a new type, or profile an existing one.

But claiming that charset=... means something else before depending on  
the context it's used in is asking for trouble.


What kind of trouble?


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and
character escapes. AFAIK there's have been no requests to support legacy
encodings in workers in Opera.


I'm ok with that. I'm not ok with treating something that has a charset  
of ISO-8859-1 silently as UTF-8, in particular when other parts of the  
platform disagree.


Why not? We have context-dependent treatment of MIME types already (e.g. a  
text/html resource can be treated as a script).


--
Simon Pieters
Opera Software



Re: Firefox bug: Worker load ignores Content-Type version parameter

2011-11-18 Thread Simon Pieters
On Fri, 18 Nov 2011 14:10:36 +0100, Julian Reschke julian.resc...@gmx.de  
wrote:



Why not? We have context-dependent treatment of MIME types already (e.g.
a text/html resource can be treated as a script).


These are workarounds because of legacy, I assume. Workers are a new  
feature.


Workers ignore the MIME type.

--
Simon Pieters
Opera Software



Re: innerHTML in DocumentFragment

2011-11-11 Thread Simon Pieters

On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking jo...@sicking.cc wrote:


And yes, this does create a lot of edge cases which needs to be
defined. But the goal should be to make sane calls sane, that seems
imminently possible. So

frag.innerHTML = g/g;
someSVGElement.appendChild(frag);

seems very possible to make work.


How?

--
Simon Pieters
Opera Software



Re: AW: WebSocket API: close and error events

2011-10-25 Thread Simon Pieters
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein  
tobias.oberst...@tavendo.de wrote:


 Is executing step 2 above (fire error) meant to cancel execution of  
step 3

(fire close)?

No, it would say ...and abort these steps if it did.


Just to be sure I get that right:

If step 2 is executed, that is error is fired, then abort and do not  
continue with step 3, that is do not fire close
If step 2 is not executed, continue and execute step 3, that is fire  
close


?


No.



 Specifically, which events should be fired when WS(S) connection
establishment fails due to:

 a) host unreachable (TCP could not even be established)
 b) TLS handshake failed (thus TCP was there, but no TLS handshake, and
 thus no WS handshake also)
 c) TLS handshake failed due to invalid server certificate
 d) TLS handshake failed for other reasons (invalid client cert,
 non-acceptable ciphers, ..)

All of these should be handled identically (for security reasons -- if  
we treat

them differently you could use it to probe non-WebSocket servers on an
intranet, for instance).


Ok, I see. Thats a good reason.


 Practically, I am mostly interested in:

 How can I detect TLS failed due to invalid server cert from
 JavaScript in the context of WSS.

You cannot, by design. If we allowed JS to detect this it would enable
attackers to do network topology scans of restricted networks.


Ok.

Would the following then be appropriate behavior for browsers?

User loads https://somehost.com:9000/index.html

UA presents cert for somehost:9000 not trusted .. accept .. continue?  
dialog.

= That dialog is builtin, no JS involved. As today.

If user continues, then index.html loads, contains JS.

The JS then opens wss://somehost.com:9090

UA present cert for somehost:9090 not trusted .. accept .. continue?
[*] = Builtin dialog, no JS involved. Not available in browsers today.


I believe Opera does this (if you enable websockets). We might change this  
to reject untrusted certs for websocket, though.



If user continues, then the WSS connection succeeds. WS onopen() handler  
fires.


If user does not continue, then WSS connection fails. WS onerror()  
handler fires - the latter does not give reason for failure.


The JS will get onerror() fired for all reasons a) - d) above.

Thus, there would be not only needed new dialog [*] for invalid server  
cert, but also for the other reasons a) - d).


In no case JS involved .. dialogs are browser builtin.

Does above make sense?


No, both error and close fire.

--
Simon Pieters
Opera Software



Re: AW: AW: WebSocket API: close and error events

2011-10-25 Thread Simon Pieters
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein  
tobias.oberst...@tavendo.de wrote:



 Would the following then be appropriate behavior for browsers?

 User loads https://somehost.com:9000/index.html

 UA presents cert for somehost:9000 not trusted .. accept ..  
continue?

 dialog.
 = That dialog is builtin, no JS involved. As today.

 If user continues, then index.html loads, contains JS.

 The JS then opens wss://somehost.com:9090

 UA present cert for somehost:9090 not trusted .. accept .. continue?
 [*] = Builtin dialog, no JS involved. Not available in browsers  
today.


I believe Opera does this (if you enable websockets). We might change  
this

to reject untrusted certs for websocket, though.


Does that mean Opera might just _silently_ reject untrusted certs without
giving the user a dialog to accept the cert?


Right.


That would be unfortunate IMHO. Since then there is no way to get an
acceptable user experience any longer.

I can't present a JS created notification and act accordingly, since JS  
won't

be allowed to detect invalid cert.

I can't rely on the browser rendering a builtin dialog for the user to
accept the cert.

WSS just fails silently.

How is a JS app using WSS supposed to create an acceptable user  
experience?


By using a cert that isn't rejected.


btw: does Opera support =Hybi-10,


No. -00.


and if so, how do I activate it?


Enable WebSockets in opera:config.


 If user continues, then the WSS connection succeeds. WS onopen()
 handler fires.

 If user does not continue, then WSS connection fails. WS onerror()
 handler fires - the latter does not give reason for failure.

 The JS will get onerror() fired for all reasons a) - d) above.

 Thus, there would be not only needed new dialog [*] for invalid
 server cert, but also for the other reasons a) - d).

 In no case JS involved .. dialogs are browser builtin.

 Does above make sense?

No, both error and close fire.


Ok. There are different views on that I guess

http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html


Seems Richard is misreading the spec.


but I - given the comment by Ian, that JS should in no case get detailed
error feedback on invalid cert, whether onclose fires or not - honestly
do not care any longer .. it won't solve my problem anyway.


OK.


On the other hand, I think it should be decided which is the desired
behavior: fire onerror only, or fire both.


The spec clearly requires both.

--
Simon Pieters
Opera Software



Re: [DOM3 Events] Some comments on Basic Event Interfaces

2011-10-13 Thread Simon Pieters
On Thu, 13 Oct 2011 03:19:26 +0200, Jacob Rossi  
jacob.ro...@microsoft.com wrote:



Note: For programming languages which do not allow optional method



parameters, such as Java, the implementation may provide two



EventTarget.addEventListener methods, one with 2 parameters, and one



with 3 parameters.







Is this a note or is it normative? You can't have both.


This is a note that suggests a workaround for implementations in  
languages that don't support optional arguments. It's not normative. An  
implementation may do this, or it may not-up to the implementer (since  
optional useCapture isn't required).


'may' is an RFC2119 term. Don't use it in notes.




If a listener was registered twice, once for the capture and target



phases and once for the target and bubbling phases, each must be



removed separately.







It's not clear if this is a UA requirement.




This is intended for authors:



target.addEventListener(foo,bar,false);

target.addEventListener(foo,bar,true);

target.removeEventListener(foo,bar,false);



This only removes the first of the two listeners.


It doesn't look like a note to me. It looks like a conformance requirement  
(since it contains the word 'must'). If it's targeting authors, it means  
they're being non-conforming if they don't remove their event listeners  
any time they register a listener twice (one capture and one bubbling). If  
you intend it to be a note, clearly mark it as a note and don't use  
RFC2119 terms.






The content authors should also remove their EventListener from its



EventTarget after they have completed using the listener.







I wonder why this is a should.




It's a coding best practices suggestion towards authors.


'should' is not a suggestion, it's a conformance requirement.

...

It seems to me you need to be more careful in your usage of RFC2119  
keywords. Also see http://ln.hixie.ch/?start=1140242962count=1


--
Simon Pieters
Opera Software



Re: [FileAPI, common] UTF-16 to UTF-8 conversion

2011-09-23 Thread Simon Pieters

On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard gl...@zewt.org wrote:


BlobBuilder.append(text) says:


Appends the supplied text to the current contents of the BlobBuilder,

writing it as UTF-8, converting newlines as specified in endings.

It doesn't elaborate any further.  The conversion from UTF-16 to UTF-8  
needs

to be defined, in particular for the edge case of invalid UTF-16
surrogates.  If this is already defined somewhere, it isn't referenced.

I suppose this would belong in Common infrastructure, next to the  
existing

section on UTF-8, not in FileAPI itself.


WebSocket send() throws SYNTAX_ERR if its argument contains unpaired  
surrogates. It would be nice to be consistent.


--
Simon Pieters
Opera Software



Re: [FileAPI] BlobBuilder.append(native)

2011-09-23 Thread Simon Pieters

On Fri, 23 Sep 2011 01:47:15 +0200, Glenn Maynard gl...@zewt.org wrote:


native Newlines must be transformed to the default line-ending

representation of the underlying host filesystem. For example, if the
underlying filesystem is FAT32, newlines would be transformed into \r\n
pairs as the text was appended to the state of the BlobBuilder.

This is a bit odd: most programs write newlines according to the  
convention
of the host system, not based on peeking at the underlying filesystem.   
You

won't even know the filesystem if you're writing to a network drive.  I'd
suggest must be transformed according to the conventions of the local
system, and let implementations decide what that is.  It should  
probably be
explicit that the only valid options are \r\n and \n, or reading files  
back

in which were transformed in this way will be difficult.

Also, in the Issue above that, it seems to mean native where it says
transparent.


Can we get away with always using \n?

--
Simon Pieters
Opera Software



  1   2   >