On Mon, 21 May 2007, Hallvord R M Steen wrote:
>
> if you set the src property of a SCRIPT element in the DOM, IE will load
> the new script and run it. Firefox doesn't seem to do anything (perhaps
> a more seasoned bugzilla searcher can tell me if it is considered a
> known bug?).
>
> I think
Bumping this in hopes of a response.
Thanks.
On 3/29/07, Brad Fults <[EMAIL PROTECTED]> wrote:
In section 7.1 of the WA 1.0 draft [1], there is the following text:
The reset() method resets the form, then fires a a formchange
event on all the form controls of the form.
In the case of a fo
On Mon, 21 May 2007, Anne van Kesteren wrote:
>
> If we simply ignore there's no longer a need to append elements
> to the head element pointer. In fact, we can remove it. I'm not sure how
> much this would complicate conformance checking, but it would certainly
> be very nice not to have such
On Mon, 21 May 2007, Anne van Kesteren wrote:
>
> Internet Explorer 7 and Opera 9 don't move and to the
> element during parsing (much like they don't do that for
>
(Thanks for forwarding forum feedback to the list. Feel free to forward my
reply back to the forums, and please do continue to forward feedback from
the forums, or blogs, or anywhere else, to the list!)
On Mon, 30 Apr 2007, Simon Pieters wrote:
> >
> > From http://forums.whatwg.org/viewtopic.p
On Wed, 25 Apr 2007, Simon Pieters wrote:
>
> The parsing section says that < in an unquoted attribute value
> terminates the tag. However, according to my testing[1], IE7, Gecko,
> Opera and Webkit don't do this -- they append the < to the attribute
> value. So I think the parsing section is wr
I have a friend who has implemented a fast tokenizer in C. I asked
him to send me any feedback he might have, and so what follows are his
words. This is from about a month ago, so I apologize if any of this
is old ground.
-Ben
-
When the tokenization state machine is defined, every
On Fri, 20 Apr 2007, Philip Taylor wrote:
>
> Section 8.2.3.1:
> "U+0061 LATIN SMALL LETTER A through to U+0078 LATIN SMALL LETTER F,
> and U+0041 LATIN CAPITAL LETTER A, through to U+0058 LATIN CAPITAL
> LETTER F"
> Should say:
> "U+0061 LATIN SMALL LETTER A through to U+0066 LATIN SMALL LETTER F,
On Fri, 20 Apr 2007, Simon Pieters wrote:
>
> I sent a bug report to Opera saying that given the markup
> "X", X should be a sibling to FOO instead of a child of
> DD. According to Anne the bug report was invalid per the current spec:
>
> On Fri, 20 Apr 2007 09:03:29 +0200, <[EMAIL PROTECTED]> w
A void element cannot have any content because there is no way to specify it
in the source. Such a relation is called entailment.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Wednesday, June 20, 2007 12:29 AM
To: ryan
Cc: [EMAIL
On Wed, 18 Apr 2007, ryan wrote:
>
> So, I was just trying to check my blog for HTML5 conformance [1] and ran
> into a conformance problem that I had trouble sorting out.
>
> The conformance checker said:
>
> > 1. Fatal Error: End tag param seen even though the element is an empty
> > ele
On Tue, 17 Apr 2007, Sam Ruby wrote:
>
> Step 25
>
> If sign is "negative", then shouldn't timezoneminutes also be negated?
Fixed.
> Step 27
>
> Shouldn't that be "SUBTRACTING timezonehours hours and timezoneminutes
> minutes"?
>
> My current time is "2007-04-17T05:28:33-04:00" The timezone
On Sat, 14 Apr 2007, Simon Pieters wrote:
>
> For compatibility with IE the parsing algorithm should probably ignore
> tags.
>
> Test case for the above proposal:
>
>
>
> * { margin:0; padding:0; }
> ul { background:red; }
> li { background:lime; }
>
> This line should be green
Lines are great fun.
See http://canvex.lazyilluminati.com/misc/lines.html for a random
collection of demonstrations relating to the stuff below.
For lineJoin, the term "joins" is used but not properly defined
(except indirectly as "where two lines meet"). Given the
implementations, this should
On 19/06/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Ian Hickson wrote:
> On Sat, 24 Feb 2007, Keryx Web wrote:
>> - A table within a table cell (Has this ever been used for anything but
>> layout?)
>
> There are valid uses of that, though they are rare.
Really? What are they?
I'm not sure of
The statements about comments can be both true in the following way: the
modern user agents may accept invalid comments while the ancient ones did
not do it, perhaps (correctly) treating
If the next input character is not a U+002F SOLIDUS (/) character,
emit a U+003C LESS-THAN SIGN character token and switch to the data
state to process the next input character.
This would be clearer if it used the usual wording "consume the next
input character" and "reconsume the current
Ian Hickson wrote:
On Sat, 24 Feb 2007, Keryx Web wrote:
- A table within a table cell (Has this ever been used for anything but
layout?)
There are valid uses of that, though they are rare.
Really? What are they?
--
Lachlan Hunt
http://lachy.id.au/
On Sat, 7 Apr 2007, Anne van Kesteren wrote:
>
> The tokenization section should also handle:
>
>
>
> as "correct" comments for compat with the web. This means that
>
>
>
> shows "-->" and that
>
>
>
> shows "-->".
These comments are not handled (though not conformant).
On Sat, 7 Apr
On Mon, 18 Jun 2007 22:25:46 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Sun, 10 Dec 2006, Anne van Kesteren wrote:
The "Anything else" case should probably trigger a parse error before
reprocessing the current token.
Why? Could you show a sample of markup that would go through this path
Once upon a time Ian Hickson shaped the electrons to say...
> Frames are out (except , which I don't really see as being a
> problem, though let me know if I'm wrong on this). Tables for layout are
I think iframe is required simply by weight of use. It seems like
most web-based advertising uses
21 matches
Mail list logo
