ere, but considering
that the crossdomain.xml design was knowingly rejected, it's probably
worthwhile to pay attention to why.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
On Wed, Dec 4, 2013 at 8:16 AM, Jonas Sicking wrote:
> On Dec 3, 2013 9:25 PM, "Marcos Caceres" wrote:
>> On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
>> > We currently have both ... and
ous
behavior of said legacy code to the Web using the default settings of
Firefox, so I'm hoping to remove the big chunk of legacy code instead
of fixing it properly.)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
https://mxr.mozilla.org/chromium/source/src/third_party/WebKit/Source/WebCore/fileapi/FileReaderLoader.cpp#282
right, WebKit doesn't. I didn't actually *test* either.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
really want to make the bet?)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ing compatible with IE7 a
few years ago, why isn't there now similar concern that applying ARIA
by a new mechanism would leave behind IE10 and earlier, which,
presumably, currently have the same sort of expected enterprise
lifespan as IE7 had when aria was introduced?
--
Henri Sivo
27;re supposed to clone the template and then
mutate the clone.
> That's unfortunate. I guess that means CSS styles will get applied to them
> as well, which wouldn't be what authors would want.
That's not really a problem as long as subtrees with elements in the
template namespaces are rooted at a display: none; element.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Tue, Jun 12, 2012 at 12:14 AM, Rafael Weinstein wrote:
> On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen wrote:
>> On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. wrote:
>>> Just saying that querySelector/All doesn't match elements in a
>>> template (unless
a fragment that belongs to a different owner
document.
(My non-objection to creating normal children in the DOM should not be
read as a commitment to support templates Gecko.)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ill open the floodgates for
all sorts of arguments that we can make the parser generate whatever
data structures regardless of what the input looks like and we'll end
up in a world of pain. It's bad enough that isindex is a parser macro.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
sistency principle and features that don't work with the XHTML
serialization should be considered huge red flags indicating faulty
design.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
s don't matter, except insofar as the history of their
> effects on the specs persists.
The reason why I care about correcting recounts of past SVG working
group opinion on this topic is that I think it's better for learning
from mistakes if the learning is based on the truth of what happened.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ta is gone and doesn't fill up buffer space.
(Some of my remarks on IRC were confused, because I mistook the
Worker-specific API for the API proposed for the main thread.)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
tops.
> Even though it'll technically work, it might look ugly due to scaling.
Shouldn't it be up to the user to refrain from using ugly apps instead
of the developer preventing them?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
walking the parent chain
(which normally won't be excessively long) as opposed to checking a
flag on the owner document?
I strongly believe that this template contents should be children of
the template element in the DOM instead of being behind a special
wormhole to another document while parsing and serializing as if the
special wormhole wasn't there.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
over time what's
> best for authors.
At this point, what's best for authors includes considerations of
consistent behavior across already-deployed browsers (including IE9,
soon IE10 and the Android stock browser) and future browsers.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
we should try to change the order in which
the scripts run. I definitely don't want that to be changed. I'm
suggesting that working with markup literals shouldn't be advertised
as a good way to insert scripts into a document.
I see the value of being consistent with jQuery, thou
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein wrote:
> Issue 1: How to handle tokens which precede the first start tag
>
> Options:
> a) Queue them, and then later run them through tree construction once
> the implied context element has been picked
>
> b) Create a new insertion like "waiting
On Fri, May 11, 2012 at 12:59 PM, Ryosuke Niwa wrote:
> Yes! Can we re-use createDocumentFragment and add an optional argument
> instead though?
I think that makes sense in principle, but I worried that the name
createDocumentFragment is the kind of name that's works OK if you're
writing Java int
On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein wrote:
> I'm very much of a like mike with Henri here, in that I'm frustrated
> with the situation we're currently in WRT SVG & MathML & parsing
> foreign content in HTML, etc... In particular, I'm tempted to feel
> like SVG and MathML made this bed
G working group is on board and henceforth avoids local name
collisions with HTML and MathML.
If the API required the caller to request SVG explicitly, would it be
a sure thing that jQuery would build magic heuristics on the library
side?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
XML experiences from non-browser contexts.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ting inertness from the ancestor chain ( ancestor or
DocumentFragment marked as inert as an ancestor). It's unclear to me
what the performance impact will be.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
and semantics can overlay
> the HTML5 and/or the RDFA can relate elements to referenced external
> resources.
What kind of software do expect to consume of this kind of data?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ser spec open right when everybody converged on the spec worry me,
though. I'm still hoping for a design that doesn't require parser
changes at all and that doesn't blow up in legacy browsers (even
better if the results in legacy browsers were sane enough to serve as
input for a polyfill).
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
certification
> processes and regulations.
I think proliferating obsolete stuff is harmful.
Which laws or regulations require compliance with some of the
above-mentioned specs? Have bugs been filed on those laws and
regulations?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ST support and
supporting other encodings should be a "MUST NOT".
What's the motivation for supporting encodings other than UTF-8 and BINARY?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
SON parser
> in our first iteration of implementing the "json" responseType.
FWIW, Gecko parses XML and HTML in a streaming way as data arrives
from the network. When readyState changes to DONE, the document has
already been parsed.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ns in
the future, I think we shouldn't expose responseText for JSON.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
7;t support UTF-32. It has no use cases as an interchange
encoding beyond writing evil test cases. Defining it as a valid
encoding is reprehensible.
Does anyone actually transfer JSON as UTF-16?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
hen
tested against attributes. And that trick only works with (X)HTML
nodes.
Selectors have the advantage that they wildcard the namespace by
default, so it's feasible to define APIs that don't even have
namespace binding mechanisms.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
to use XSLT2 in browsers to license Saxon-CE (XSLT2
implemented in JavaScript) from Saxonica instead of expecting native
implementations in browsers.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ense to spec what
they already support instead inventing a new API.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ot;compatibility mode" for interpreting existing XPath 1.0 queries, but
it seems like a bad idea to build on a spec whose authors have put
compatibility into a side mode and what's considered the main thing
isn't fully compatible with existing queries.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Mon, Nov 21, 2011 at 8:26 PM, Jonas Sicking wrote:
> On Wed, Nov 16, 2011 at 2:40 AM, Henri Sivonen wrote:
>> * For text/html responses for response type "" and "document", the
>> character encoding is established by taking the first match from this
>>
leave a wide safety margin around optional features. Otherwise,
there's a risk of getting sucked into implementing bad optional
features anyway.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Wed, Nov 16, 2011 at 12:40 PM, Henri Sivonen wrote:
> * Making XHR not support HTML parsing in the synchronous mode.
In reference to the other thread about discouraging synchronous XHR
(outside Workers), this change ended up being made in Gecko. (HTML
parsing in XHR still hasn't made
the description of what
needs to be implemented in order to successfully render the Web.
By all means put some kind of Surgeon General's warning about race
conditions on localStorage but, please, let's not hide the description
of the feature from specs.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
making yet but might make in near future:
* Making responseType == "" not support HTML parsing at all and to
treat text/html as an unknown type for the purpose of character
encoding.
* Making XHR not support HTML parsing in the synchronous mode.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Fri, Nov 11, 2011 at 1:42 PM, Henri Sivonen wrote:
> As a bonus, developers would need to call createDocumentFragement() first.
Doh. Would *not* need to call createDocumentFragement() first.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ergonomics go.
> someTableElement.innerHTML = "...";
>
> will just drop the div on the floor.
By what mechanism? (It didn't implement and run Yehuda's suggestion,
but I'm pretty sure it wouldn't drop the div. Why would we put
additional effort into dropping the div?)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ier and why doing something different would be bad.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren wrote:
>> Unfortunately
rt for HTML parsing. No need
to first get responseText and then pass it to something else.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
IM for all elements?
I don't want to add DWIM to support , , etc., but I'd
like to have good confidence that the selection of elements that we
add DWIM support for is the right set (neither too broad to drive up
implementation cost without use cases nor too narrow to end up needing
wha
he sanitizer does.
Stuff to debate includes what to do about Content MathML, what to do
about elements that appear to reference SVG and what to do
about elements that bear Microdata attributes.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
is a problem with , but developing
a complete solution that works sensibly even when you do stuff like
frag.innerHTML = ""
frag.innerHTML = ""
frag.innerHTML = "a"
frag.innerHTML = "foobar"
frag.innerHTML = "foo"
frag.innerHTML = ""
frag.innerHTML
e parts of the world from
> transitioning to developing "AJAX" based websites if we drop all of
> these things, however I have not yet gathered that data.
I think we shouldn't take the encoding of the invoking page into
account. We have an excellent opportunity to avoid propagating that
kind of legacy badness. I think we should take the opportunity to make
a new feature less crazy.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
d in Firefox Aurora by adding chunked text
and chunked ArrayBuffer response types:
https://bugzilla.mozilla.org/show_bug.cgi?id=687087
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Fri, Sep 30, 2011 at 8:05 PM, Jonas Sicking wrote:
> Unless responseType=="" or responseType=="document" I don't think we
> should do *any* HTML or XML parsing. Even the minimal amount needed to
> do charset detection.
I'd be happy to implement it that way.
> For responseType=="text" we curre
On Fri, Sep 30, 2011 at 3:35 PM, Anne van Kesteren wrote:
> On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen wrote:
>>
>> On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren
>> wrote:
>>>
>>> I do not see why "text" and "moz-chunked-te
Seems reasonable for the modes that have a non-null responseXML for text/html.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
I think we should design new features to make
authors everywhere get their act together and declare their encodings.
(Note that this position is much less extreme than the more
enlightened position e.g. HTML5 App Cache manifests take: Requiring
everyone to use UTF-8 for a new feature so that declarations aren't
needed.)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ules.
* "text" and "moz-chunked-text" use the same encoding detection rules.
* "moz-chunked-text" uses the same encoding for all chunks.
* All imaginable badly written comet apps are guaranteed to continue working.
* responseXML considers in a deterministic way (no timer for
bailing out before 1024 bytes if the network stalls).
Which property do we give up?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
onseText using the same encoding that's used for
responseXML? If yes, that would mean changing the way responseText
decodes in Gecko when there's no declaration.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
loaded from after the fact, so debugging doesn't seem any
> harder.
If that counts as "not harder", I concede this point.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Mon, Sep 26, 2011 at 12:46 PM, Jonas Sicking wrote:
> On Fri, Sep 23, 2011 at 1:26 AM, Henri Sivonen wrote:
>> On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking wrote:
>>> I agree that there are no legacy requirements on XHR here, however I
>>> don't think tha
On Fri, Sep 23, 2011 at 11:26 AM, Henri Sivonen wrote:
> Applying all the legacy text/html craziness
Furthermore, applying full legacy text/html craziness involves parser
restarts for GET requests. With a browsing context, that means
renavigation, but I really don't want to suppor
n the XHR data loading
machinery of an app, it's much harder to figure out what part of the
system the problem should be attributed to.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
back for responseText and
responseText is already used with text/html.
As it stands, the XHR2 spec defers to a part of HTML that has
legacy-oriented optional features. It seems that it makes sense to
clamp down those options for XHR.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
m space without a new HTML element:
https://github.com/mozilla/openwebapps/blob/master/docs/ACTIVITIES.md
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Adding [XHR2] to the subject to comply with the instructions. Sorry
about the noise.
On Tue, 2011-04-19 at 12:04 +0300, Henri Sivonen wrote:
> In reference to
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-overridemimetype
>
> It seems to me that
? I assume that typically one would use
overrideMimeType() when knowing ahead of time that the config of the
server responding to XHR is bogus.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
already started' flag set, so the
script behaves like a script created with document.createElement("script") when
inserted into a document.
I'd be interested in use cases around createContextualFragment in order to get
a better idea of which behavior should be the correct beh
an
identifiable context element node even after walking the parent chain, the
context passed to the HTML fragment parsing algorithm should be "body" in the
XHTML namespace. I don't know DOM Range well enough to say how this situation
can arise.)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
the call that widget signing is flawed. And it's
> important to note that no one that has implemented has come back to the WG
> raising any concerns or screaming bloody murder.
It could be that people don't sign widgets very often. I don't recall ever
seeing a signed Firefox extension or a signed Eclipse plug-in.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
API to the least common
> denominator for a small fraction of users? Especially when there's no
> technical reason why these providers could not be made more advanced (for
> example, embed webkit to display fully functional notifications)?
It's not a given that it's an advancement in user experience terms not to force
all ambient notifications into a consistent form.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ing to keep a browsing context or a worker active at
the notification time.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
s like XHR in
browsers--the system as a whole still doesn't interoperate with Web browsers.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
ses that hard-wiring IDness to
id doesn't address.
> Having said all that, I'm not very keen on adding native support for xml:id.
> I'd
> rather just make 'id' in the null namespace "special" if at all possible.
> KISS,
> right?
Indeed. Works for everything I've seen so far, except Chemical Markup Language.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
element doesn't have a single attribute that has
IDness. Instead, it has to have two (the natural choice flowing from XML specs)
or the IDness of attributes has to depend on the presence of other attributes
(the choice taken by SVG 1.2 Tiny).
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Jul 2, 2009, at 12:11, Giovanni Campagna wrote:
2009/7/2 Cameron McCormack :
Henri Sivonen:
Gecko bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=500937
The proposed patch there and (based on black-box testing) WebKit
solve
the issue by running the HTML serialization algorithm when
somewhere.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Jun 2, 2009, at 16:02, Robin Berjon wrote:
On Jun 2, 2009, at 14:57 , Henri Sivonen wrote:
Please include a corresponding UA requirement to obtain
authorization from the user for the features imported with
. (It seems that the security aspect requires an
authorization and doesn't
make it quite clear.
I notice that now the definition of what a feature is includes a video
codec in addition to APIs. Does BONDI expect video codecs to be
sensitive to security policies? Do you envision undeclared video
codecs to be withheld from the HTML5 fallback and
canPlayTy
ity aspect requires an authorization and doesn't make sense
if the dangerous feature are simply imported silently.) As far as I
can tell, the spec doesn't currently explain what the UA is supposed
to do with the 'feature list' once built.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
activated with .
If a widget UA has an implementation for window.frob() and frob()
requires activation, what should happen when frob() hasn't
been activated with ? Should there be no function object for
frob()? Or should it be there but throw upon calling? Or something else.
Please spe
d of being presumptively required for new features in general.
I'll start new threads for additional comments
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Jun 1, 2009, at 16:44, Marcos Caceres wrote:
On Mon, Jun 1, 2009 at 1:25 PM, Henri Sivonen wrote:
Using a feature element denotes that, at runtime, a widget may
attempt to
access the feature identified by the feature element's name
attribute.
Why is this useful to denote?
If there are two such engines, how do they converge on the same
feature name string of the specifiers of the feature itself just meant
it to be available to Web content unconditionally and didn't bother to
mint a widget feature string?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
isolate even different instances
of the same widget.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
since it's neither in the title nor in the actual
URI scheme.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
d epoch seconds?)
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
aries
that browsers use for their existing crypto operations.
And again, XML security solves a more complex problem than the
smallest problem that really needs solving for zip archive signing.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Apr 15, 2009, at 15:00, Marcos Caceres wrote:
On Tue, Apr 14, 2009 at 4:19 PM, Henri Sivonen
wrote:
On Apr 14, 2009, at 14:38, Marcos Caceres wrote:
I think it would be more productive to help us address the issues
that you
mentioned, instead of asking us to dump everything and start
traditional way,
you are a step away from using jar-compatible manifests. :-) This
would address issue #3.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
On Apr 14, 2009, at 13:01, Thomas Roessler wrote:
On 14 Apr 2009, at 11:42, Henri Sivonen wrote:
XSD datatypes are too vague, allow whitespace where the spec writer
didn't mean to allow whitespace or allow surprising values (like
"0" and "1" when the spec writer t
On Apr 14, 2009, at 11:57, Thomas Roessler wrote:
On 14 Apr 2009, at 10:27, Henri Sivonen wrote:
Wouldn't it be simpler to use jar signing instead of inventing a
new way of signing zip files with implementation dependencies on
XML signatures and spec dependencies on XSD? (Why does the
but unsigned widgets could omit it,
and it isn't much uglier than an XML signature file on the top level
of the zip archive.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
defined by RFC 3236. As implemented, the
media type isn't restricted to a particular point version of XHTML and
browsers don't implement 1.1.
(In fact, the media types in the table aren't defined by the specs in
the "Defined by" column in general, but are defined by
between an
ancestor svg element and the selector subject would be good enough.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
form
any trimming.
Note that in XML this is specified in terms of DTD datatypes, but
the config document is described in RELAX NG.
So as far as the XML processor is concerned, all the attributes are
CDATA. RELAX NG does not feed back to AVNormalize.
--
Henri Sivonen
[EMAIL PROTE
, implementors don't always do it. My conclusion is that it's
better to specify that keyword attribute values are compared without
trimming. (Unless, of course, the attribute in question takes a
whitespace-separated list of tokens.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
he principle of least surprise with an old scheme? Aren't
URIs extensible at the scheme point in order to avoid forcing
implementors to give special contextual meaning to existing schemes?
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
27;s Draft link points to the Editor's Draft of another spec.
The processing model should probably say that non-DOM implementations
are allowed if the result isn't black-box-distinguishable.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
he requests and can update the JS program immediately.
(Validator.nu also advertises Accept-Encoding: gzip via OPTIONS, but
I'm not aware of any client automatically picking it up from there.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
96 matches
Mail list logo
