HTML Query

[William Gill]

This expression is a little too babyish for grown ups around here.

What if neither of them are paying attention <g>?

 

[dorayme]

What if neither of them are paying attention <g>?

You mean for ever (remember, there are archives)? In that case, he could
get away with it.

 

[Jani]

<NOFORUM>

^^^^^^
Stop putting HTML within STYLE elements. They are *not* required as so
many erroneously believe.

Where do you find HTML here? "<!--" ... only this?

Having an empty HREF is not a good idea, can have unwanted side effects.
Far better to attach an onclick handler directly to the element, in your
  example it would be the SPAN, however I would think DIV of would be
more appropriate.

An onclick handler can change the color of (or hide/show) text?

2. Put all your JavaScript in an *external* file.

In this case it is allowed to use document.writeln?
</NOFORUM>

 

[rf]

<NOFORUM>


Where do you find HTML here? "<!--" ... only this?

That is HTML. It's an HTML comment.

 

[Jani]

That is HTML. It's an HTML comment.

Oh this. But here they explain something: http://www.w3.org/TR/REC-CSS1/#containment-in-html

<quote>

Traditionally, UAs have silently ignored unknown tags. As a result,
old UAs will ignore the 'STYLE' element, but its content will be
treated as part of the document body, and rendered as such. During a
transition phase, 'STYLE' element content may be hidden using SGML
comments:

<STYLE TYPE="text/css"><!--
H1 { color: green }
--></STYLE>

Since the 'STYLE' element is declared as "CDATA" in the DTD (as
defined in [2]), conforming SGML parsers will not consider the above
style sheet to be a comment that is to be removed.

</quote [2] http://www.w3.org/TR/REC-CSS1/#ref2>

Why they don't write "<!-- in STYLE-tags is depricated"?

 

[Jonathan N. Little]

<NOFORUM>


Where do you find HTML here? "<!--" ... only this?

I inadvertently omitted the word "comments", but essentially yes an HTML
comment is HTML. Between the opening and closing STYLE tags can only
contain stylesheet rules and hence stylesheet syntax comments

/* ... */

Anyway the commenting was a "fix" for old Netscape V2 as I recall, since
Netscape went the way of the Dodo and Netscape V2 is long
dead-dead-dead, don't bother commenting out your style. Ditto for
JavaScript as well.

An onclick handler can change the color of (or hide/show) text?

Yes? But it is JavaScript doing it, not HTML. If JavaScript is disable
then no color change or hide/show...

One side effect that I was referring to having empty HREF to just
accommodate some onclick handler, if the link is a ways down the page
when clicked it will reload the document making it "jump" to the top of
the page. Most likely not the desired effect if all you wanted to do was
to "expand" a block of text.

In this case it is allowed to use document.writeln?

Not if you are using XHTML!

Boy I wish this persistent notion that "XHTML is the future", "XHTML is
the better", "XHTML is the required for that silly buzz word 'Web2.0'"
would also go extinct as LAYERS!

</NOFORUM>

The meaning of the NOFORUM escapes me, guess I'm being a little dense.

 

[Andy Dingley]

Oh this. But here they explain something:
http://www.w3.org/TR/REC-CSS1/#containment-in-html

conforming SGML parsers will not consider the above
style sheet to be a comment that is to be removed.

This "comment in a style" is NOT well-formed SGML, thus not well-
formed HTML, so a "correct" interpretation is to not treat it as a
comment, i.e. to process it as content to the <style> element, i.e. as
CSS. In a convoluted sense, "We ignore it, so as to not ignore it".

Older commonplace browsers (those that fail to recognise the CSS
content as CSS) will generally have an error in their parsing
behaviour such that they regard the comment (incorrectly) as a
comment, thus ignore this content. That has the side-effect of causing
them to ignore it and not render it, which is a behaviour we'd not
want to see. A correct SGML parser would still recognise this content
as some form of text and may choose to render it. I suspect that the
ancient (but correct) browser embedded in emacs might be the only
thing to ever demonstrate this problem - it's also the only one that
causes problems with <br /> in HTML. Although this text is inside
the <head> element and so clearly "shouldn't be displayed as part of
the page", this isn't (AFAIK) a compliance requirement on user agents
(it's certainly not required by SGML), so it's not an error for a
browser to have done so, unhelpful though such behaviour would now
appear.

 

[Jani]

Yes? But it is JavaScript doing it, not HTML. If JavaScript is disable
then no color change or hide/show...
One side effect that I was referring to having empty HREF to just
accommodate some onclick handler, if the link is a ways down the page
when clicked it will reload the document making it "jump" to the top of
the page. Most likely not the desired effect if all you wanted to do was
to "expand" a block of text.

On cnn.com I found now a very, very nice gif, that rotates from [-] to
[+].
It has only 649 bytes - when you change the transparent background to
black in Fireworks the size gets 204 kb!!!
Maybe here lies a secret - use as often "transparent" in your gifs as
possible. I will check this next time!
Forget about any white background e.g. and make it transperent.

http://i.cdn.turner.com/cnn/.element/img/1.3/misc/opinionWhite.gif
on the left bottom of http://edition.cnn.com/video/flashLive/live.html?stream=stream1
Here they only have a plain link and this animated gif. No show/hide -
but it is the derivation.

 

[Jonathan N. Little]

Yes? But it is JavaScript doing it, not HTML. If JavaScript is disable
then no color change or hide/show...
One side effect that I was referring to having empty HREF to just
accommodate some onclick handler, if the link is a ways down the page
when clicked it will reload the document making it "jump" to the top of
the page. Most likely not the desired effect if all you wanted to do was
to "expand" a block of text.

On cnn.com I found now a very, very nice gif, that rotates from [-] to
[+].
It has only 649 bytes - when you change the transparent background to
black in Fireworks the size gets 204 kb!!!

More likely the reason is they in the transformation you went from a
1-bit (2-color) palette to a full 8-bit (256 color) palette on the GIF

 

[Bergamot]

On cnn.com I found now a very, very nice gif, that rotates from [-] to
[+].
It has only 649 bytes - when you change the transparent background to
black in Fireworks the size gets 204 kb!!!

You must be doing something weird. I loaded it into Fireworks, changed
the background to black and exported it.
Gif is 636 bytes. An 8-bit png is 235 bytes, 32-bit png is 240 bytes.

Maybe you just saved it as png instead of exporting it. It is an
animated gif so all the frames are left intact. That bumps it up
considerably.

 

[Jani]

You must be doing something weird. I loaded it into Fireworks, changed
the background to black and exported it.

Ah - yes - thanxlot! I did not know I have to export it.