On Fri, May 26, 2017 at 1:18 AM, Eric Rahm wrote:
> Limiting to modifying nsScanner might be an option, but probably not
> changing all callers that use the nsAString interface. I guess we can just
> UTF-16 => UTF-8 those and file a bunch of follow ups?
Yeah. The main
Thanks Henri, I think we can find a middle ground so as to avoid a ton of
scope creep but leave the door open to a better iterative solution. See
notes inline.
-e
On Wed, May 24, 2017 at 11:18 PM, Henri Sivonen
wrote:
> On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen
On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen wrote:
>> Our current interface is UTF-16, so that's my target for now. I think
>> whatever cache-friendliness would be lost converting from UTF-16 -> UTF-8 ->
>> UTF-16.
>
> I hope this can be reconsidered, because the
Am 24.05.17 um 09:34 schrieb Anne van Kesteren:
On Tue, May 23, 2017 at 8:23 PM, Eric Rahm wrote:
I was hoping to write a more thorough blog post about this proposal (I have
some notes in a gist), but for now I've added comments inline. The main
takeaway here is that I want
On Wed, May 24, 2017 at 10:34 AM, Anne van Kesteren wrote:
> Contrary to Henri, I think XML 1.0 edition 5 (which isn't "XML5") is
> worth considering given
> https://bugzilla.mozilla.org/show_bug.cgi?id=501837. It's what Chrome
> ships and our current implementation doesn't seem
On Tue, May 23, 2017 at 8:23 PM, Eric Rahm wrote:
> I was hoping to write a more thorough blog post about this proposal (I have
> some notes in a gist), but for now I've added comments inline. The main
> takeaway here is that I want to do a bare-bones replacement of just the
>
On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen wrote:
> It seems to me that attribute values would be the only case where a
> conversion from UTF-8 to UTF-16 would be needed all the time, and that
> conversion can be fast for ASCII, which is what attribute values
> mostly
On Tue, May 23, 2017 at 5:01 PM, Daniel Fath wrote:
> So, if I understand this correctly - We'll first need to land this component
> in Firefox, right? And if it proves itself fine, then formalize it.
No, both the implementation and the spec would have to be pretty solid
I was hoping to write a more thorough blog post about this proposal (I have
some notes in a gist [1]), but for now I've added comments inline. The main
takeaway here is that I want to do a bare-bones replacement of just the
parts of expat we currently use. It needs to support DTD entities, have a
Am 23.05.17 um 16:01 schrieb Daniel Fath:
So, if I understand this correctly - We'll first need to land this
component in Firefox, right? And if it proves itself fine, then formalize
it.
I was thinking of having resolutions for the issues that are currently
warnings in red and multi-vendor
So, if I understand this correctly - We'll first need to land this
component in Firefox, right? And if it proves itself fine, then formalize
it.
> I was thinking of having resolutions for the issues that are currently
> warnings in red and multi-vendor buy-in. (Previously, Tab from Google
> was
On Tue, May 23, 2017 at 12:44 PM, Daniel Fath wrote:
>> (If the outcome here is to do XML5, we should make sure the spec is
>> polished enough at the WHATWG in order not to a unilateral thing in
>> relative secret.)
>
> What does it mean to be polished enough at the
> (If the outcome here is to do XML5, we should make sure the spec is
> polished enough at the WHATWG in order not to a unilateral thing in
> relative secret.)
What does it mean to be polished enough at the WHATWG?
Also how far reaching should spec be? Include Namespaces?
On Tue, May 23, 2017
Figured out the email address of the XML5 editor / xml5ever developer,
so adding to CC.
On Tue, May 23, 2017 at 9:43 AM, Henri Sivonen wrote:
> In reference to: https://twitter.com/nnethercote/status/866792097101238272
>
> Is the rewrite meant to replace expat only or also
14 matches
Mail list logo