On Tue, 29 Nov 2005, Lachlan Hunt wrote:
At least in Gecko, we parse the contents of noembed, noscript,
noframes, and iframe as CDATA when we're not going to be using
their contents because in the past, we've had lots of problems with
authors treating these tags like C's preprocessor
On Tue, 29 Nov 2005, Christian Biesinger wrote:
Ian Hickson wrote:
Yeah, what's a plugin and what isn't is a UA thing, so if the UA
decides that its PNG and SVG plugins happen to be native support,
well, that's what it is. (Both PNG and SVG are recognised by Mozilla's
embed because
Hi,
From: Ian Hickson [EMAIL PROTECTED]
On Mon, 28 Nov 2005, Simon Pieters wrote:
I've created a test suite for img, iframe, embed/noembed and
object with the data types image/png, text/plain, text/html,
application/xml and application/x-shockwave-flash, with the HTTP
responces 200, 404,
On Tue, 29 Nov 2005, Christian Biesinger wrote:
Ian Hickson wrote:
Yeah, what's a plugin and what isn't is a UA thing, so if the UA
decides that its PNG and SVG plugins happen to be native support,
well, that's what it is. (Both PNG and SVG are recognised by Mozilla's
embed because at
Christian Biesinger wrote:
How can you drop applet if you want to be compatible with the current
web?
We're writing a specification here, not an implementation.
Implementations will likely continue to be backwards compatible with
applet, just as they are with font etc.
--
Jasper
Simon Pieters wrote:
Opera:
If plugins are enabled, render all embeds and hide all noembeds, and
parse noembed as CDATA. If plugins are disabled, hide all embeds and
display all noembeds, and parse noembed as #PCDATA.
Why does it need to parse it differently depending on the mode? Since
On Tue, 29 Nov 2005, Simon Pieters wrote:
(object is less efficient to implement because the UA has to
wait til it knows what the content type is before it can know how
to render the element.)
Also when there's a type attribute?
The attribute is only a hint.
So the
Blake Kaplan wrote:
Lachlan Hunt wrote:
Why does it need to parse it differently depending on the mode? Since
noembed is just hidden anyway, it really shouldn't matter how its
content is parsed and parsing it like #PCDATA makes the most sense.
At least in Gecko, we parse the contents of
On Tue, 29 Nov 2005, Lachlan Hunt wrote:
headnoscriptbody.../noscriptscript.../scriptbody
Ok, but how is equivalent markup handled in XHTML, where parsing
obviously can't switch to CDATA?
It's a parse error (parse errors are fatal in XML).
As to how the script problem is handled in
Lachlan Hunt wrote:
Why does it need to parse it differently depending on the mode? Since
noembed is just hidden anyway, it really shouldn't matter how its
content is parsed and parsing it like #PCDATA makes the most sense.
At least in Gecko, we parse the contents of noembed, noscript,
Hi,
I've created a test suite for img, iframe, embed/noembed and
object with the data types image/png, text/plain, text/html,
application/xml and application/x-shockwave-flash, with the HTTP responces
200, 404, 410, 301 to 200, 301 to 404 and 301 to 410.
11 matches
Mail list logo
