CSS strict implementation (Quick Check)

[Bob90]

Hi all,

Any help would be great. It's hard to find good info on strict css; well for me anyway :confused:

Whats wrong with the below code? Anything?


.skin0{
position: absolute;
cursor: default;
z-index: 50;
visibility: hidden;
}

[Twey]

No, nothing, although you might want to insert a space before the {: I think there's a bug that occasionally affects one of the earlier versions of IE if you don't.

[Bob90]

How the hell do you know stuff like that! :)
Thanks anyway.

[Bob90]

Its actually part of a bigger problem, but I didn't want to bog anyone down with my stupidity.

I just changed to a strict web page and I'm having problems.

Any help as to why my right-click menu doesn't work?

Does strict also apply to javascript? :eek:

Know any decent references for strict authoring?

Thanks

[jscheuer1]

Changed to strict from what? Transitional or quirks? DOCTYPE does affect javascript. One of the two most common ways is that you may be required to specify units for pixels in about any DOCTYPE, also the way IE gets the body element in certain scripting situations changes when changing from quirks to a valid DOCTYPE.

Differing DOCTYPE's will cause markup to render differently in many cases. Where javascript is dependant upon markup, this can mess up a script.

Additionally, anything that is invalid in a given DOCTYPE, whether it is hard coded or created by a script can cause problems.

[Bob90]

Thanks for the pixek thing. As fir the rest i will work through my code and sort it out (I went from transitional)

[mburt]

If you use a DOCTYPE, use the w3c validator to check it. It will tell (mostly) what's wrong and about where to find it on your page:
http://validator.w3.org/

[jscheuer1]

If you use a DOCTYPE, use the w3c validator to check it. It will tell (mostly) what's wrong and about where to find it on your page:
http://validator.w3.org/

Generally that will only help to fix hard coded HTML and can often generate erroneous error reports for on page scripts as well as miss errors in any script generated HTML.

It is still a good idea but, best to know its limitations.

[Twey]

can often generate erroneous error reports for on page scriptsNot erroneous. The things the validator reports are indeed invalid.

[jscheuer1]

Not erroneous. The things the validator reports are indeed invalid.

Not for on page scripts. It will erroneously report that tags which are 'not open' are being closed. However, since these tags are themselves within script tags, they are not tags, they are code. Or, if looked at as the strings that they are, usually do have opening tags that the validator is ignoring. Either way it is a goof of the validator.

This is why scripts generally should be made external for validation.

[Twey]

However, since these tags are themselves within script tags, they are not tags, they are code.The code within <script> elements still has to be parsed so that the parser knows where to find the </script>. Thus, some of the same rules apply to the code that apply to HTML, and the things it's complaining about are invalid.

[jscheuer1]

The code within <script> elements still has to be parsed so that the parser knows where to find the </script>. Thus, some of the same rules apply to the code that apply to HTML, and the things it's complaining about are invalid.

Oh, right but that is a technicality. All parsers I know of ignore / in a script block as far as ending the block goes unless it appears at least like so:


</script

perhaps as:


</script>

for your case, if you are lucky/unlucky (pov), as:


</s

If you have (in a script):


var txt='<div>Hello</div>'

What browser will barf on that?

And, how is this (in a script) in any way shape or form invalid?


//</div>

The validator is only a program . . . only a program . . .

[Twey]

Oh, right but that is a technicality. All parsers I know of ignore / in a script block as far as ending the block goes unless...Yes, but that's error-correction. The specification says it shouldn't be ignored, and it's the specification that the validator checks the page against, not how it's parsed by the major browsers of the time.

[jscheuer1]

That still doesn't get how:


// </div>

is invalid. It only is if the specification is being applied too narrowly and/or in a vacuum. The error is totally erroneous. I think the other may be as well if you think about it but, I admit it (the other case) is more open to debate.

[Twey]

Not at all. What you're talking about here is the classical difficulty of embedding: the embedded content must be valid when parsed as part of the containing content. Special rules shouldn't be necessary.

[jscheuer1]

I guess we just disagree. Script tags are valid in HTML. Scripts have syntax. The validator should take this syntax into account for the valid tag when evaluating its content or be occasionally in error. The validator does take into account, for example, the syntax of an image, division or span tag when validating its content. What is allowed in the tag as content and what is allowed for the tag as an attribute is what should and does matter in most cases, with scripts receiving harsher treatment due to a lack of programming on the part of those who wrote the validator.

[Twey]

The validator does take into account, for example, the syntax of an image, division or span tag when validating its content.No, it takes into account the list of elements allowed inside such an element. No exceptions for syntax are made. If someone nests a <br> inside a <div>, it's invalid, but the HTML is still well-formed.

[jscheuer1]

Now, you've lost me. I'm sure you don't mean that this:


<div><br></div>

is invalid but, it looks to me like you are saying that it is.

[Twey]

Er, sorry, I meant inside a <body>.

[jscheuer1]

Either get some rest or stop yanking my chain. :rolleyes: