On 6/13/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 26 Jul 2006, Shadow2531 wrote:
So, ?xml-stylesheet type=text/css href=? is a bogus comment.
I *was* 100% sure that the PI should be parsed into:
!--?xml-stylesheet type=text/css href=?--
Correct.
Thanks Ian. Can you
As written, the charset sniffing algorithm doesn't trim space
characters from around the tentative encoding name. html5lib test
case expect the space characters to be trimmed.
I suggest trimming space characters (or anything = 0x20 depending on
which approach is the right for compat).
--
On Thu, 14 Jun 2007 03:17:16 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
I haven't looked at the parsing of comments in PCDATA mode yet but I'm
guessing we'll have to support !-- there too.
Yeah, and !--- too iirc. There's some other e-mail dealing with that.
And maybe also !-- --! given the
Hi,
I was wondering how you mitigate the persistent connection
limitations described in RFCs 2068 and 2616 vs server-sent events. It
seems the former limits the laters usability.
Thanks,
Reed
On Mon, 14 Aug 2006, Anne van Kesteren wrote:
Just a FYI. You have to deal with the edge case that the root element
might be html:script. Non conforming obviously, but what's supposed to
happen should still be defined. I guess you would ignore calls to
document.write() in such cases or
On Tue, 3 Oct 2006, Simon Pieters wrote:
On getting .innerHTML the spec says that the tag name is used to
serialize tags. However, Opera and Firefox use the local name. Also, it
isn't certain that element names and attribute names will be all
lower-case.
Fixed, as per our discussion on
On Mon, 9 Oct 2006, Robert wrote:
In browsers today, the following:
a href=test xmlns= ... /a
...is just a link. If we start supporting xmlns= as it works in XML, but
in HTML, then literally millions of pages are going to suddenly have their
links stop working, because a in the
On Sun, 15 Oct 2006, Simon Pieters wrote:
When parsing HTML and serializing as XML you normally want to change the
lang attribute to xml:lang. But why not put it in the XML namespace at
the parser level? Then when you serialize the DOM as XML it becomes
xml:lang automatically.
The
On Fri, 27 Oct 2006, Anne van Kesteren wrote:
foo
bar/
bar/
/foo
How can foo.innerHTML be well-formed here?
On Sat, 28 Oct 2006, Lachlan Hunt wrote:
Anne van Kesteren wrote:
foo
bar/
bar/
/foo
How can foo.innerHTML be well-formed here?
It could be if it
Your hypothetical author is unable to insert an embed element because embed
is all English to him. Being able to use a Mandarin attribute name will not
help him much because he cannot produce the element to use it with.
Considering Arabic script and the like, the time is probably near when we
On Thu, 2 Nov 2006, Henri Sivonen wrote:
The spec says:
The rules for parsing XML documents (and thus XHTML documents) into DOM
trees are covered by the XML and Namespaces in XML specifications, and are
out of scope of this specification.
However, the spec says the following about the id
On Fri, 3 Nov 2006, Elliotte Harold wrote:
Section 9.2.2 of the current Web Apps 1.0 draft states:
Bytes or sequences of bytes in the original byte stream that could not
be converted to Unicode characters must be converted to U+FFFD
REPLACEMENT CHARACTER code points.
I'm concerned
On Sun, 5 Nov 2006, Elliotte Harold wrote:
Otherwise if the next seven chacacters are a case-insensitive match for the
word DOCTYPE, then consume those characters and switch to the DOCTYPE state.
chacacters -- characters
Fixed.
--
Ian Hickson U+1047E
I've looked at how Safari renders shadows - the spec should probably
define something similar, since it works and it's not insane or
anything.
Just before a shape/image is drawn, a shadow image is created (based
on the original shape/image's alpha values (ignoring the RGB entirely)
and the
On Sun, 5 Nov 2006, �istein E. Andersen wrote:
From section 9.2.3.1. Tokenising entities:
For some entities, UAs require a semicolon, for others they don't.
This applies to IE.
FWIW, the entities not requiring a semicolon are the ones encoding
Latin-1 characters, the other HTML 3.2
On Mon, 6 Nov 2006, Henri Sivonen wrote:
On Nov 6, 2006, at 07:34, Ian Hickson wrote:
On Sun, 5 Nov 2006, Henri Sivonen wrote:
Is there a reason why the definition of space characters does not
match the XML 1.0 and RELAX NG definition of white space (space,
tab, CR, LF) but also
On Fri, 24 Nov 2006, �istein E. Andersen wrote:
Section 8.1.4:
Bytes that are not valid UTF-8 sequences must be interpreted as [...] U+FFFD
Section 9.2.2:
Bytes or sequences of bytes [...] that could not be converted to Unicode
characters
must be converted to U+FFFD
If I read this
On Tue, 28 Nov 2006, Simon Pieters wrote:
The HTML syntax requires space characters between attributes, but the
lack of space characters between attributes does not cause a parse error
according to the parsing section.
Attributes must be separated from each other and from the
tag
On Wed, 29 Nov 2006, Simon Pieters wrote:
The parsing section says that in unquoted attribute values are a parse
error and that it causes the tag token to be emitted. As far as I can
tell does not emit the tag token in at least Firefox, IE6 or Safari.
Is it intentional to emit the tag
Le 2007-06-14 à 21:05, Ian Hickson a écrit :
I've defined the parsing and conformance requirements in a way that
matches IE. As a side-effect, this has made things like naiumlve
actually conforming. I don't know if we want this.
I'd make it non-conforming for the sake of readability.
On
20 matches
Mail list logo
