On Wed, 10 Oct 2012, Cameron Zemek wrote:
>
> On Wed, Oct 10, 2012 at 4:47 AM, Ian Hickson wrote:
> > I could add a note... based on what Boris described, what would you want
> > the note to say and where would you want it placed, such that you would
> > have seen it when your original reading cau
On Wed, Oct 10, 2012 at 4:47 AM, Ian Hickson wrote:
> I could add a note... based on what Boris described, what would you want
> the note to say and where would you want it placed, such that you would
> have seen it when your original reading caused you to e-mail the list?
>
> (This part of the sp
On Tue, 9 Oct 2012, Cameron Zemek wrote:
> On Tue, Oct 9, 2012 at 1:36 PM, Ian Hickson wrote:
> > On Tue, 9 Oct 2012, Cameron Zemek wrote:
> >>
> >> I noticed the specification usually treats null characters U+ by
> >> replacing them with the replacement character U+FFFD . The other
> >> cas
On 10/9/12 12:09 AM, Cameron Zemek wrote:
How is it not web-compatible?
Because shipping it "breaks" sites. As in, makes them render
differently than they do in current browsers, sufficiently so that it's
a problem.
Yeah I don't have any numbers to see if this is the case or not.
As Ann
On Tue, Oct 9, 2012 at 6:09 AM, Cameron Zemek wrote:
> I assume I'm probably missing some historical reason for this, its
> just struck me as needless complexity. In other words, what good
> reasons exist for ignoring null characters in certain portions of the
> HTML specification?
As Ian said th
On Tue, Oct 9, 2012 at 1:36 PM, Ian Hickson wrote:
> On Tue, 9 Oct 2012, Cameron Zemek wrote:
>>
>> I noticed the specification usually treats null characters U+ by
>> replacing them with the replacement character U+FFFD . The other cases
>> it will be ignored by the tree construction stage wh
On Tue, 9 Oct 2012, Cameron Zemek wrote:
>
> I noticed the specification usually treats null characters U+ by
> replacing them with the replacement character U+FFFD . The other cases
> it will be ignored by the tree construction stage when the mode is 'in
> body', 'in table text', 'in select
I noticed the specification usually treats null characters U+ by
replacing them with the replacement character U+FFFD . The other cases
it will be ignored by the tree construction stage when the mode is 'in
body', 'in table text', 'in select'.
Would it not be simpler and more consistent to jus
The user agent must decode the bytestream corresponding with the
manifest to be parsed, treating it as UTF-8. Bytes or sequences of
bytes that are not valid UTF-8 sequences must be interpreted as a U
+FFFD REPLACEMENT CHARACTER. All U+ NULL characters must be
replaced by U+FFFD REPLACE
