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
Ian Hickson wrote:
On Mon, 28 Nov 2005, Lachlan Hunt wrote:
How about this, or some variation of:
Foo
...
...
Interesting idea. I like the non-JS fallback potential. Pity about the
being necessary to get the to disappear, but I guess
we need that...
I o
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 Mon, 28 Nov 2005, Justin Kirby wrote:
>
> XUL is not proprietary. It is limited to a single implementation, but
> that does not mean it is exclusive. The word proprietary indicates that
> it is under exclusive control of an company. While this is true of Flash
> and Macromedia, it is not true
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
XUL is not proprietary. It is limited to a single implementation, but
that does not mean it is exclusive. The word proprietary indicates that
it is under exclusive control of an company. While this is true of
Flash and Macromedia, it is not true of XUL and Mozilla.
Justin
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 Tue, 29 Nov 2005, anko wrote:
>
> Basically it's a request that the throbber (loading symbol up the top
> right of most modern browsers) should be active when XMLHTTPRequest is
> receiving data. The idea is that the user stays informed when the
> browser is waiting on network activity.
As L
anko wrote:
Hi,
It was suggested that someone email this list to see what you think
about this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312418.
...
Currently XMLHTTPRequest does not change the throbbers state and it is
hard to know if an AJAX enabled website is doing anything.
That
Hi,
It was suggested that someone email this list to see what you think
about this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312418.
Basically it's a request that the throbber (loading symbol up the top
right of most modern browsers) should be active when XMLHTTPRequest is
receiving d
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
Ian Hickson wrote:
The reason I suggested that we should allow for easy fallback onto
is that for the menu-button use case, it's very easy to implement
that kind of menu using (and is done often today), and so it
would allow for a seamless fallback (if we do it right).
But if you fall back
On Mon, 28 Nov 2005, Lachlan Hunt wrote:
>
> > 4. Replacing ad-hoc DHTML context menus with something more accessible,
> >that doesn't necessarily replace the UA's own context menus.
>
> If the spec were to address this kind of menu, then it must not
> completely override the UAs own context
On Mon, 28 Nov 2005, Ian Bicking wrote:
>
> I think isn't a very good basis for menus. Current (good)
> DHTML menus are richer than selects allow for, with things like nested
> menus. That can't be simulated with selects.
Sure. As you point out, though, if the author is willing to do the leg
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
Ian Hickson wrote:
I'd really like to be able to fall back on the abuse,
since it is easy to define how to make a menu from that, but I don't want
to just put an attribute on the element to change its behaviour
-- it's got to still be a , just one that happens to not be
visible in new UAs, w
Hello,
On 11/27/05, ROBO Design <[EMAIL PROTECTED]> wrote:
> On Sun, 27 Nov 2005 00:28:49 +0200, Charles Iliya Krempeaux
> <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > This is kind of a follow up to a previous post of mine:
> >
> > rel/rev for ?
> > http://listserver.dreamhost.com/pipermail/wh
26 matches
Mail list logo
