Newbie question: Exceptions

[Florian Schaetz]

Hi,

I just "inherited" a style sheet and, honestly, never have been good at
them. There's one little question I have:

My predecessor made an interesting construct, by defining a div with id
"navigation". Inside this div, there are many lists. The "navigation" id
defines a certain background-color for the list elements when hovering.
But, unfortunately, he also defined a separating line inside the lists -
using a div-tag.

But, in XTHML 1.0 Transitional, a div tag is not allowed inside an <ul>,
so I had to switch it to a <li> element. And now, guess what, the
separating line also changes its background color when hovering which
looks a little bit strange :-)

So, my big question would be: How do I define the separator-<li> in a
way, that there's no background-color when hovering? In other words, how
can I make one element the exception from a rule inherited from a
bounding element?

Regards,

Flo

[Thomas 'PointedEars' Lahn]

Florian Schaetz wrote:

> My predecessor made an interesting construct, by defining a div with id
> "navigation". Inside this div, there are many lists. The "navigation" id
> defines a certain background-color for the list elements when hovering.

Talk is cheap. Show me the code.
-- Linus Torvalds

> But, unfortunately, he also defined a separating line inside the lists -
> using a div-tag.
>
> But, in XTHML 1.0 Transitional, a div tag is not allowed inside an <ul>,

^^^^^ _XHTML_ (eXtensible HyperText Markup Language)

A `DIV' *child* _element_ is not allowed (read: not valid) there in *any*
version or formulation of HTML.

> so I had to switch it to a <li> element. And now, guess what, the
> separating line also changes its background color when hovering which
> looks a little bit strange :-)

You should not be using "empty" `li' elements to make space between other
`li' elements; use the `margin' and/or `border` properties instead.

> So, my big question would be: How do I define the separator-<li> in a
> way, that there's no background-color when hovering? In other words, how
> can I make one element the exception from a rule inherited from a
> bounding element?

ISTM you are asking the wrong question.

<http://www.catb.org/~esr/faqs/smart-questions.html>


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

[dorayme]

In article <4fa8eb71$0$9518$9b4e...@newsspool1.arcor-online.net>,

Florian Schaetz <ir...@gmx.de> wrote:

> Hi,
>
> I just "inherited" a style sheet and, honestly, never have been good at
> them. There's one little question I have:
>
> My predecessor made an interesting construct, by defining a div with id
> "navigation". Inside this div, there are many lists. The "navigation" id
> defines a certain background-color for the list elements when hovering.

Like how?

#navigation li a:hover {...; background: red; ...}

?

> But, unfortunately, he also defined a separating line inside the lists -
> using a div-tag.
>

Just to have a line appear to separate the list items? Would not a
bottom border with suitable padding or a top border do the job and not
need an extra element which then has to be styled anyway?

> But, in XTHML 1.0 Transitional, a div tag is not allowed inside an <ul>,
> so I had to switch it to a <li> element.

Not really, it is not good idea at all to use a LI for a non-list
purpose. Style the lists that are doing the job they are meant to do,
namely contain real list items.

> And now, guess what, the
> separating line also changes its background color when hovering which
> looks a little bit strange :-)
>

Give a URL so we can actually see this instead of guessing the
different things your description fits.

> So, my big question would be: How do I define the separator-<li> in a
> way, that there's no background-color when hovering? In other words, how
> can I make one element the exception from a rule inherited from a
> bounding element?
>

First, of course, don't have the separator as a list item. Second, if
you do, you can style the particular item that hovers to override any
inherited styles. Give us some markup or better the URL and it should
be simple enough to show you how to commit this crime.

--
dorayme

[Florian Schaetz]

And thus, dorayme wrote...

> Give a URL so we can actually see this instead of guessing the
> different things your description fits.

I prepared a SSCCE at http://www.irian.de/test/test.html

When hovering over "Something", a submenu appears, which is all fine,
just the separator-line-hovering issue is annoying.

And, yes, I do plan to rewrite the whole thing, learning CSS (again) as
I go. I just don't have the time atm, just want the thing to work :-)

Thanks in advance.

Flo

[Thomas 'PointedEars' Lahn]

Florian Schaetz wrote:

> And thus, dorayme wrote...
>> Give a URL so we can actually see this instead of guessing the
>> different things your description fits.
>
> I prepared a SSCCE at http://www.irian.de/test/test.html
>
> When hovering over "Something", a submenu appears, which is all fine,
> just the separator-line-hovering issue is annoying.

AISB, do not use "empty" elements for spacers unless you have to.
li#navtrenn in your SSCCE is such an element. Replace it with something
that (literally) makes sense instead.

And please do not post Subjects containing "newbie". Either you are smart
enough to learn more or you are not. If not, posting here will not help.

BTW, there is de.comm.infosystems.www.authoring.misc.


HTH

[David Stone]

In article <4fa93069$0$6633$9b4e...@newsspool2.arcor-online.net>,

Florian Schaetz <ir...@gmx.de> wrote:

> And thus, dorayme wrote...
>
> > Give a URL so we can actually see this instead of guessing the
> > different things your description fits.
>
> I prepared a SSCCE at http://www.irian.de/test/test.html
>
> When hovering over "Something", a submenu appears, which is all fine,
> just the separator-line-hovering issue is annoying.

The original author added a final, empty list item to the submenu:

<li id="navtrenn"> </li>

Deleting this makes the "line" down the left-hand side of the
submenu disappear. (I found this out using Firefox with the
FireBug extension - a very useful tool for figuring out what
styles are being applied to which elements.)

Note that there may be side-effects in your actual page
from deleting this, so check first; however, it seems fine
in your specimen page.

[Florian Schaetz]

And thus, David Stone wrote...

> The original author added a final, empty list item to the submenu:
>
> <li id="navtrenn"> </li>

To be more exact, the original author added a <div class="navtrenn"/>
element there, which seems to do the job without problems, but still
isn't valid XHTML :-) When I replaced it with an element that is
actually allowed there, I noticed that now the navtrenn (nav separator)
element is of course affected by the hover parameters of the navigation
class.

> Deleting this makes the "line" down the left-hand side of the
> submenu disappear. (I found this out using Firefox with the
> FireBug extension - a very useful tool for figuring out what
> styles are being applied to which elements.)

Erm... The problem is not, that the line is there (it is supposed to
be), just that the line gets bolder (because the background color is
changed) when hovering it :-)

Flo

[Philip Herlihy]

In article <4fa93dad$0$6638$9b4e...@newsspool2.arcor-online.net>,
ir...@gmx.de says...

Having drunk deep at the trough here myself over the last couple of days
I did try to get to the bottom of this, but I'm pretty stumped. I have
established that you are using :hover to make visible a UL which has a
background-image, but that image isn't loading from the server. I
figured this much out using Firebug in Firefox (still learning to use
this well).

See line 9 of the HTML file:

#maintrunk, #navigation ul li ul {
background-image: url(resources/bg/neworder2003.jpg);

--

Phil, London

[Florian Schaetz]

And thus, Philip Herlihy wrote...

> Having drunk deep at the trough here myself over the last couple of days
> I did try to get to the bottom of this, but I'm pretty stumped. I have
> established that you are using :hover to make visible a UL which has a
> background-image, but that image isn't loading from the server.

Oh, sorry, didn't shorten the example enough, it seems. Uploaded it
again (still http://www.irian.de/test/test.html ), hopefully only with
the important parts now. The background image thingy is not part of the
problem.

What you see, when loading the page, is an <ul> list inside a div
element (with class "navigation"). This list is the top level menu.

Some of the top level menu entries have a 2nd-level menu (a submenu, if
you want). This is the case for the "Something" menu entry. When
hovering the mouse pointer over this top level menu entry, the 2nd level
menu appears to the right of it.

In the 2nd level menu, entries are highlighted when hovering over them,
which is great.

Additionally, the 2nd level menu (when visible) is separated from the
top level menu by a vertical line, which is done by the "navtrenn" class.

But, as you surely noticed, when hovering over this navtrenn-line, it
gets bold - because it's inside the navigation div-element and thus the
hover rule that changes its background applies. And this is what I want
to change but, atm, don't have a real clue how.

I simply need something that says "when hovering over an element with
the navtrenn class, don't change the background".

I am aware that the whole thing is very likely a criminal abuse of a
poor, innocent <li> element and I'll surely burn in hell for it, but
until I find the time to relearn CSS and build the whole thing from
scratch, I just want it to stop reacting to hover :-)

Regards,

Flo

[Denis McMahon]

On Tue, 08 May 2012 16:40:38 +0200, Florian Schaetz wrote:

> I prepared a SSCCE at http://www.irian.de/test/test.html

1) Declare your css for #navtrenn:

#navtrenn, #navtrenn:hover

2) In the css for #navtrenn, #navtrenn:hover, include color and
background-color to match the document body (or whatever else it is meant
to match).

Rgds

Denis McMahon

[David Stone]

In article <4fa93dad$0$6638$9b4e...@newsspool2.arcor-online.net>,

Florian Schaetz <ir...@gmx.de> wrote:

> And thus, David Stone wrote...
>
> > The original author added a final, empty list item to the submenu:
> >
> > <li id="navtrenn"> </li>
>
> To be more exact, the original author added a <div class="navtrenn"/>
> element there, which seems to do the job without problems, but still
> isn't valid XHTML :-) When I replaced it with an element that is
> actually allowed there, I noticed that now the navtrenn (nav separator)
> element is of course affected by the hover parameters of the navigation
> class.

Ok, but when I view the source in FireBug, there is no div, only an
extra li - perhaps this is part of the browser's error handling,
since a div is not allowed here but an li is? Makes debugging
interesting!

> > Deleting this makes the "line" down the left-hand side of the
> > submenu disappear. (I found this out using Firefox with the
> > FireBug extension - a very useful tool for figuring out what
> > styles are being applied to which elements.)
>
> Erm... The problem is not, that the line is there (it is supposed to
> be), just that the line gets bolder (because the background color is
> changed) when hovering it :-)

Ah! So, if you need a line down the side of the submenu whenever it
appears, why not apply it by styling the ul for the submenu, rather
than adding a phantom element that has all sorts of unwanted side
effects and is not valid markup anyway?

I use css submenus on one site that I derived from the Ruthsarian
menus:
<http://www.chem.utoronto.ca/coursenotes/analsci/stats/>
<http://webhost.bridgew.edu/etribou/layouts/rmenu/>

There's some explanation at the second site about how the whole
thing works, which might help with learning some CSS in general.

If you need a quick fix, perhaps do something with the selector
#navtrenn a:hover { ... } to overide the current (mis)behaviour?

[Florian Schaetz]

And thus, Denis McMahon wrote...

I tried (honestly said, it was one of the first things I tried, two days
ago), by writing this instead of the old code:

#navtrenn, #navtrenn:hover {
position: absolute;
left: 0px;
top: 4px;
background-image: url(./trennstrich-gr.png);
background-repeat: no-repeat;
background-color: none;
width: 9px;
height: 396px;
display: block;
}

Doesn't work. The background-color is still set to #21361A when
hovering. I can't use a specific background-color anyway, as there's an
image below, so one color won't cut it.

Anyway, I also tried this, just to test it:

#navtrenn {
...as above
}

#navtrenn:hover {
background-color: red;
}

Even this doesn't work. When hovering, the separator line still becomes
bold #21361A, not even red...

Regards,

Flo

[Gus Richter]

On 5/8/2012 11:37 AM, Florian Schaetz wrote:
> Erm... The problem is not, that the line is there (it is supposed to
> be), just that the line gets bolder (because the background color is
> changed) when hovering it :-)

Remove <li id="navtrenn"> in your markup.
Remove #navtrenn completely in your CSS.

In your CSS replace like so:

#navigation ul li:hover ul {
border-left:2px solid; /* this is added */
visibility: visible;
z-index: 100;
}

--
Gus

[Thomas 'PointedEars' Lahn]

Florian Schaetz wrote:

> I am aware that the whole thing is very likely a criminal abuse of a
> poor, innocent <li> element and I'll surely burn in hell for it, but
> until I find the time to relearn CSS and build the whole thing from
> scratch, I just want it to stop reacting to hover :-)

FWIW: *Without* changing the underlying markup and the rest of the
stylesheet (*strongly* recommended *against*), you need either

#navtrenn:hover {
background-color: transparent !important;
background-image: url(./trennstrich-gr.png) !important;
}

or

#navigation ul li ul li#navtrenn:hover
{
background-color: transparent;
background-image: url(./trennstrich-gr.png);
}

because of

#navigation ul li ul li:hover A,
#navigation ul li ul li:hover,
/*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/
#navigation ul li ul li A:hover
{
color: #ffffff;
text-decoration: none;
background-color: #21361A;
/* ^^^^^^^^^^^^^^^^^^^^^^^^^^ */
background-image: none;
/* ^^^^^^^^^^^^^^^^^^^^^^^ */
}

#navtrenn {

position: absolute;
left: 0px;
top: 4px;
background-image: url(./trennstrich-gr.png);

/* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */
background-repeat: no-repeat;

width: 9px;
height: 396px;
display: block;
}

starting in line 70 of test.css (`./' is superfluous, of course).

A `#navtrenn:hover' selector without `!important' will not suffice because
the original selector has greater specificity [1]:

#navigation ul li ul li:hover

has specificity 0,1,1,4. By contrast,

#navtrenn:hover

has only specificity 0,1,1,0. But

#navigation ul li ul li#navtrenn:hover

has specificity 0,2,1,4 which is greater than 0,1,1,4.

In general, to make exceptions for a specific element, you can either append
`!important' to a declaration or use a selector with greater specificity for
the exception. However, if the relevant original declarations already are
`!important', you have to use a selector with greater specificity *and* to
put `!important' in the declarations for the exception. So use `!important'
sparingly in your stylesheets.

As for asemantic markup, you have been warned. Next time, use a CSS
inspector-editor (every major browser has one *built-in*, try the <F12> key
in most), RTFM, STFW, and try something by yourself first.


PointedEars
___________
[1] <http://www.w3.org/TR/CSS2/cascade.html#specificity>
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[Florian Schaetz]

And thus, David Stone wrote...

> Ok, but when I view the source in FireBug, there is no div, only an
> extra li - perhaps this is part of the browser's error handling,
> since a div is not allowed here but an li is? Makes debugging
> interesting!

Sorry, I was a little bit unclear obviously: When I got the code for the
page, there was a <div> element. My first action when getting it, was
making sure, that it was at least XHTML valid (as I think it's a good
place to start). Therefor I removed the <div> element (as it's not
allowed there) and replaced it with an element allowed there, a <li>.

With the <div> element, the browser obviously had no problem (which I
would prefer it had, as then the guy before me would have had to clean
it up :-). But, with the <li> element, now the hover-rule applies, thus
creating a problem that didn't exist before.

> Ah! So, if you need a line down the side of the submenu whenever it
> appears, why not apply it by styling the ul for the submenu, rather
> than adding a phantom element that has all sorts of unwanted side
> effects and is not valid markup anyway?

You, as well the other people saying that, are, of course, right,
probably the correct way to go would be to add the line to the <ul>.
Unfortunately, this requires some other changes, to make it look like
now, as, for example, in the real page, there's a little green line
connection the top level menu entry (an image) which is currently
selected to the sub menu separator, etc. (just as an example). This
would require some playing around to make it look like it does now, so I
hoped for a quick fix.

There's no doubt that I have to rework the whole thing from scratch one
day, but I hoped that this day would be later, not sooner...

> There's some explanation at the second site about how the whole
> thing works, which might help with learning some CSS in general.

Thanks, I'll have a look at it as soon as I start relearning CSS again
and fixing the page.

> If you need a quick fix, perhaps do something with the selector
> #navtrenn a:hover { ... } to overide the current (mis)behaviour?

The funny thing is, that I tried that and it doesn't seem to work. I
tried to set background-color:red in #navtrenn:hover and #navtrenn
a:hover, but it never becomes red, always green :-/

Flo

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> In general, to make exceptions for a specific element, you can either
> append `!important' to a declaration or use a selector with greater

> specificity for the exception. […]

And because of that,

#navtrenn {
/* … */

background-color: transparent !important;
background-image: url(./trennstrich-gr.png) !important;

/* … */
}

suffices here :)


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[David Stone]

In article <4fa962eb$0$6643$9b4e...@newsspool2.arcor-online.net>,

Florian Schaetz <ir...@gmx.de> wrote:
> And thus, David Stone wrote...

[snip]

> > If you need a quick fix, perhaps do something with the selector
> > #navtrenn a:hover { ... } to overide the current (mis)behaviour?
>
> The funny thing is, that I tried that and it doesn't seem to work. I
> tried to set background-color:red in #navtrenn:hover and #navtrenn
> a:hover, but it never becomes red, always green :-/

Take a careful look at the order of the different rules, as you have
to be concerned with specificity and precedence. You can find the
technical details here:
<http://www.w3.org/TR/CSS21/cascade.html#cascade>

Note the use of !important in section 6.4.2. Hope that helps...

[Florian Schaetz]

And thus, Thomas 'PointedEars' Lahn wrote...

> FWIW: *Without* changing the underlying markup and the rest of the
> stylesheet (*strongly* recommended *against*), you need either

Thank you very much, this really circumvents (not solves, of course) the
problem. And yes, I agree with your recommondation.

> In general, to make exceptions for a specific element, you can either append
> `!important' to a declaration or use a selector with greater specificity for
> the exception. However, if the relevant original declarations already are
> `!important', you have to use a selector with greater specificity *and* to
> put `!important' in the declarations for the exception. So use `!important'
> sparingly in your stylesheets.

Sounds logically not to use what seems to be the equivalent of brute
force, thanks. I see that specificity will be one of the first parts I
have to read about when working on my CSS.

> As for asemantic markup, you have been warned. Next time, use a CSS
> inspector-editor (every major browser has one *built-in*, try the<F12> key
> in most), RTFM, STFW, and try something by yourself first.

Of course I tried something first (the same things already mentioned
here, minus the !important), but without the correct term a search can
be quite difficult. If you know your problem is specificity, then
searching for it and even finding the brute force !important option is
easy, but without knowing that...

Thanks anyway,

Flo

[Florian Schaetz]

And thus, David Stone wrote...

> Note the use of !important in section 6.4.2. Hope that helps...

Thanks, that's at least a workaround. It doesn't "solve" the real
problem (a poorly designed CSS, it seems), but without having to work
through the whole CSS and rewrite it, it's the best thing (or, the
lesser evil) for me at the moment.

Regards,

Flo

[tlvp]

On Tue, 08 May 2012 16:40:38 +0200, Florian Schaetz wrote:

> I prepared a SSCCE at http://www.irian.de/test/test.html
>
> When hovering over "Something", a submenu appears, which is all fine,
> just the separator-line-hovering issue is annoying.

And how is the hapless internaut who comes upon that page to realize that,
by hovering a mouse pointer over one particular, but
not-particularly-special, point in the viewport, a menu will spring out?

Why play such a childish game of HideAndGoSeek with your visitors?
Must every visitor sweep your whole viewport with a cursor, as troops in
Afghanistan swept terrain with minesweepers, to find objects of interest?

Else: "You win, there's nothing here for me to see, Tschüss."

Or is that the response you're after? Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[tlvp]

On Tue, 08 May 2012 20:15:56 +0200, Florian Schaetz wrote:

> There's no doubt that I have to rework the whole thing from scratch one
> day, but I hoped that this day would be later, not sooner...

"Why is there never time now to do it right, but always time later to fix
everything that got done wrong the first time(s) around?" :-)

[Florian Schaetz]

And thus, tlvp wrote...

> And how is the hapless internaut who comes upon that page to realize that,
> by hovering a mouse pointer over one particular, but
> not-particularly-special, point in the viewport, a menu will spring out?

Technically, the sub menu also appears when clicking on the menu entry
and thus loading the sub-page.

So, for example, you can either hover over "Galleries" to get the
Galleries sub menu or simply click on Galleries, thus loading the
gallery main page and the sub menu will be there without hovering. The
hovering is - probably, as I can only guess - just meant as a shortcut,
to be able to go to a sub-page without having to load its parent.

As I said: I didn't design it, but as a user I never had any problems
using the page before. But I'll take it as advise for when the page gets
re-designed.

Flo

[tlvp]

On Wed, 09 May 2012 07:04:16 +0200, Florian Schaetz wrote:

> And thus, tlvp wrote...
>
>> And how is the hapless internaut who comes upon that page to realize that,
>> by hovering a mouse pointer over one particular, but
>> not-particularly-special, point in the viewport, a menu will spring out?
>
> Technically, the sub menu also appears when clicking on the menu entry
> and thus loading the sub-page.

But how is one to know that a broken 1px x 1px image (that the source
reveals to be called "1x1.png") is functioning as a link? ...

> So, for example, you can either hover over "Galleries" to get the

... that you think of as named "Galleries"?

> Galleries sub menu or simply click on Galleries, thus loading the

Why would anyone care to hover over or click on a browser's icon for a
broken image? Visiting internauts shouldn't have to consult the HTML source
to learn how the page should work -- can't they just expect it to work :-)?

> gallery main page and the sub menu will be there without hovering. The
> hovering is - probably, as I can only guess - just meant as a shortcut,
> to be able to go to a sub-page without having to load its parent.
>
> As I said: I didn't design it, but as a user I never had any problems
> using the page before. But I'll take it as advise for when the page gets
> re-designed.

Suit yourself :-) .

> Flo

[Florian Schaetz]

And thus, tlvp wrote...

> But how is one to know that a broken 1px x 1px image (that the source
> reveals to be called "1x1.png") is functioning as a link? ...

That's just because I cut most of it away. In the complete file, there
are background-images defined for the #navX classes, don't worry :-) But
I assume that using a file called 1x1.png is a bad idea anyway, probably
something else I have to get rid of as soon as I have the time.

> Why would anyone care to hover over or click on a browser's icon for a
> broken image?

You do understand that the example was reduced to the code that was
needed to show the "vertical line hover" problem? In the original code
there are no broken images (as far as I'm aware of).

> Visiting internauts shouldn't have to consult the HTML source
> to learn how the page should work -- can't they just expect it to work :-)?

But where's the fun in that? Where's your sense for adventure? If every
webpage simply gave you access to all its content, where would be the
exploring, the rush of adrenalin when finding another hidden gem of
information hidden behind css-traps and walls of broken XHTML code? :-)

Flo

[Jonathan N. Little]

Well if you MUST have the silly notion of using XHTML, your markup us
way over complicated and convoluted...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml;
charset=UTF-8" />
<title>XHTML 1.0 Example</title>
<style type="text/css">
div#navigation ul {padding: 0; list-style: none; width: 10em;
background: #efe; position: relative; }

div#navigation ul a { display: block; padding: .2em .5em; }
div#navigation ul a:hover { background: #050; color: #fff; }

div#navigation ul li ul { position: absolute; left: 10em; top: 0;
background: #eef; border-left: 2px ridge #050; display: none; }
div#navigation ul li:hover ul { display: block; }
</style>
</head>
<body>
<div id="navigation">
<ul>
<li id="nav1">
<a href="test.html" class="nava">Startseite</a>
</li>
<li id="nav2">
<a href="test.html" class="nava">Something</a>
<ul>
<li>
<a href="test.html">A subpoint</a>
</li>
<li>
<a href="test.html">A subpoint</a>
</li>
<li>
<a href="test.html">A subpoint</a>
</li>
<li>
<a href="test.html">A subpoint</a>
</li>
<li>
<a href="test.html">A subpoint</a>
</li>
</ul>
</li>
</ul>
</div>
</body>
</html>


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Florian Schaetz]

And thus, Jonathan N. Little wrote...

> Well if you MUST have the silly notion of using XHTML, your markup us
> way over complicated and convoluted...

a) No, I must not. I just don't see any advantage in changing it. But I
really would like to hear, why you think that using XHTML is silly?

b) No, it it not (mine :-P). But yes, the markup is all you say. And
honestly, before I got it to be at least valid, it was worse (not much,
though).

Flo

[tlvp]

If, on a page, I don't see immediately what the link that led me there
promised, I'll just assume I got misled and navigate away. I haven't the
inclination to assume it'd hiding there somewhere -- even if I did have, I
haven't the self-confidence to think I'd easily find what the designer must
have gone to great pains to hide away.

In a nutshell my sense of adventure is reserved for Bergwanderungen :-) .

Cheers, -- tlvp

[Jonathan N. Little]

Florian Schaetz wrote:
> And thus, Jonathan N. Little wrote...
>
>> Well if you MUST have the silly notion of using XHTML, your markup us
>> way over complicated and convoluted...
>
> a) No, I must not. I just don't see any advantage in changing it. But I
> really would like to hear, why you think that using XHTML is silly?
>

Because like it or not Microsoft whose browser market share is not
insignificant has never really supported XHTML.

> b) No, it it not (mine :-P). But yes, the markup is all you say. And
> honestly, before I got it to be at least valid, it was worse (not much,
> though).

So why perpetuate the mess?

[David Stone]

In article <joedh1$ph6$1...@dont-email.me>,

"Jonathan N. Little" <lws...@gmail.com> wrote:

> Florian Schaetz wrote:
> > And thus, Jonathan N. Little wrote...
> >
> >> Well if you MUST have the silly notion of using XHTML, your markup us
> >> way over complicated and convoluted...
> >
> > a) No, I must not. I just don't see any advantage in changing it. But I
> > really would like to hear, why you think that using XHTML is silly?
> >
>
> Because like it or not Microsoft whose browser market share is not
> insignificant has never really supported XHTML.

Not to mention that Apple, Google, and Microsoft are all backing html5,
which seems to be the successor to both html4 and xhtml...
<http://www.whatwg.org/specs/web-apps/current-work/multipage/>

> > b) No, it it not (mine :-P). But yes, the markup is all you say. And
> > honestly, before I got it to be at least valid, it was worse (not much,
> > though).
>
> So why perpetuate the mess?

And why paint yourself into a corner as far as future features
are concerned?

A bit of a fluff piece, and I'm sure folks here can poke holes in it,
but there's this: <http://www.bbc.co.uk/news/business-17931814>

[Osmo Saarikumpu]

David Stone kirjoitti:

> A bit of a fluff piece, and I'm sure folks here can poke holes in it,
> but there's this: <http://www.bbc.co.uk/news/business-17931814>

Yes, nice. First it says:

"HTML5 takes the internet by storm"

and a few lines afterward:

"Cannot play media. You do not have the correct version of the flash
player. Download the correct version" (Full stop missing in the original.)

Wait, I'm having a flashback... (pun intended) did we not experience
this with DHTML?

--
Best wishes,
Osmo

[Thomas 'PointedEars' Lahn]

The funny thing there is that they are not even using the HTML5 `video'
element when they could; Flash content could serve as fallback if neither of
the video formats specified by `source' elements were supported (and a
hyperlink could/should be provided as last fallback).

It should also be noted that the BBC way of embedding Flash content breaks
when you use the FlashBlock (1.2.11.10) extension (in "Chromium 8.0.1025.151
[Developer Build 130497 Linux] built on Debian wheezy/sid, running on Debian
6.0.4"). Usually in that case, Flash content is blocked and you can click
the box (or the Flash icon in the box) to enable it. In this case, there is
no such icon and clicking the empty space that the image is replaced by does
nothing. This is probably cause by FlashBlock only registering the Flash
content when the document is loaded: Since there is no Flash content in the
original document, it cannot be found by FlashBlock afterwards.


X-Post & F'up2 .html; this is off-topic here.

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[David Stone]

In article <joh1i0$82o$1...@speranza.aioe.org>,

Osmo Saarikumpu <os...@weppipakki.com> wrote:

> David Stone kirjoitti:
>
> > A bit of a fluff piece, and I'm sure folks here can poke holes in it,
> > but there's this: <http://www.bbc.co.uk/news/business-17931814>
>
> Yes, nice. First it says:
>
> "HTML5 takes the internet by storm"
>
> and a few lines afterward:
>
> "Cannot play media. You do not have the correct version of the flash
> player. Download the correct version" (Full stop missing in the original.)

Hey, the BBC just reports the news. By policy, they try very hard to
avoid _making_ it!

> Wait, I'm having a flashback... (pun intended)

Groan!

> did we not experience this with DHTML?

Joking aside:

I don't think DHTML ever had any features which allowed a measure of
DRM? That's why the BBC's iPlayer uses Flash for embedding video
segments. I don't know if html5's audio and video objects allow for
that sort of thing or not, but that's a discussion for a different
group... (follow-ups set accordingly!)