On Tue, 29 Nov 2005, Lachlan Hunt wrote:
> >
> > At least in Gecko, we parse the contents of , ,
> > , and 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 directives, handlin
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
> >
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
On Mon, 28 Nov 2005, Simon Pieters wrote:
>
> I've created a test suite for , , / and
> 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 t
Christian Biesinger wrote:
How can you drop 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
, just as they are with etc.
--
Jasper Bryant-Greene
General Manag
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
> > beca
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 because
at one point they were plugin-only in IE and so people would us
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 , ,
, and as CDATA wh
On Tue, 29 Nov 2005, Lachlan Hunt wrote:
> >
> > ..
>
> 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
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, Simon Pieters wrote:
> > > >
> > > > ( 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
On Tue, 29 Nov 2005, Lachlan Hunt wrote:
>
> Simon Pieters wrote:
> > Opera:
> > If plugins are enabled, render all s and hide all s, and
> > parse as CDATA. If plugins are disabled, hide all s and
> > display all s, and parse as #PCDATA.
>
> Why does it need to parse it differently depending on
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
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.
I just observated what browsers do now. Perha
Simon Pieters wrote:
Opera:
If plugins are enabled, render all s and hide all s, and
parse as CDATA. If plugins are disabled, hide all s and
display all s, and parse as #PCDATA.
Why does it need to parse it differently depending on the mode? Since
noembed is just hidden anyway, it really
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
> > ( 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 hint is only for
On Mon, 28 Nov 2005, Simon Pieters wrote:
> >
> > Maybe, yeah, but I don't like having something that is -only;
> > the idea is that , , and are case-specific
> > versions of , so that you use , , or when
> > you know what you want, and when you don't.
>
> (Although is different from in t
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
> What about only supporting raster images? If authors want vector
> images then they could use instead.
Maybe, yeah, but I don't like having something that is -only; the
idea is that , , and are case-specific versions of
, so that you use , , or wh
On Mon, 28 Nov 2005, Simon Pieters wrote:
>
> What about only supporting raster images? If authors want vector
> images then they could use instead.
Maybe, yeah, but I don't like having something that is -only; the
idea is that , , and are case-specific versions of
, so that you use , , or
Hi,
From: Ian Hickson <[EMAIL PROTECTED]>
I think for you want to only support image/* types (e.g. not
text/plain or text/html, not sure about image/svg+xml either, since there
is no difference between that and application/xhtml+xml); and you want to
only show them for 200 (or 301-200).
What
On Mon, 28 Nov 2005, Anne van Kesteren wrote:
> >
> > For you want to support all types, and you want to show the
> > contents for all the response codes, but they should show inside the
> > frame regardless of the type.
>
> Really? Wouldn't it be better to show the fallback content of the
> e
Quoting Ian Hickson <[EMAIL PROTECTED]>:
http://zcorpan.1go.dk/test/html/embedded/
Are the pass conditions correct?
Not sure, I haven't really worked out what that section should say yet.
I think for you want to only support image/* types (e.g. not
text/plain or text/html, not sure about i
On Mon, 28 Nov 2005, Simon Pieters wrote:
>
> I've created a test suite for , , / and
> 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.
>
> http://zcorp
Hi,
I've created a test suite for , , / and
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.
http://zcorpan.1go.dk/test/html/embedded/
Are the pass condit
22 matches
Mail list logo
