Sucking mozillas...

[Guest]

http://physics.nist.gov/cuu/Units/checklist.html (#15)
http://en.wikipedia.org/wiki/SI (SI Writing Style, point 5)
http://www.bipm.fr/en/si/si_brochure/chapter5/5-4.html (All the examples)
http://www.ukma.org.uk/why/system.htm (All the examples)
http://lamar.colostate.edu/~hillger/numbers.htm (All the examples)

Ha, so I am not crazy

But what is most weird is that, you can write "width: 3%", "width:
3%", "width: 3px" and you cannot "width: 3 px". Where's the logic? Out of
standard?:>

Regards,
Talthen

==
Mozilla should change its name to Mosquito

 

[Marc]

Anyway, as for hierarchical lists vs. accurate font sizes, the popular
vote goes one way: Mozilla rules!

I agree. Mozilla Rules! *stands in Neredbojias' camp*

Marc

 

[Marc]

http://physics.nist.gov/cuu/Units/checklist.html (#15)
http://en.wikipedia.org/wiki/SI (SI Writing Style, point 5)
http://www.bipm.fr/en/si/si_brochure/chapter5/5-4.html (All the examples)
http://www.ukma.org.uk/why/system.htm (All the examples)
http://lamar.colostate.edu/~hillger/numbers.htm (All the examples)

I stand corrected.

Marc

 

[Marc]

But what is most weird is that, you can write "width: 3%", "width:
3%", "width: 3px" and you cannot "width: 3 px". Where's the logic? Out of
standard?:>

Where is the logic in your argument?

'you can write "width: 3%"' - no space between 3 and %
'"width: 3%"' - no space between 3 and %
'"width: 3px"' - no space between 3 and px
'and you cannot "width: 3 px"' - space between 3 and px - doesn't work.

Other examples include:

3em
3pt
3ex

and so on... all of which have no space.

Marc

 

[Guest]

Where is the logic in your argument?

'you can write "width: 3%"' - no space between 3 and %
'"width: 3%"' - no space between 3 and %
'"width: 3px"' - no space between 3 and px
'and you cannot "width: 3 px"' - space between 3 and px - doesn't work.

I mean- the number of spaces differ between : and 3, I also can write
"width:3" and it will work.
So where's the logic- sometimes spaces are ingored, sometimes not?

And why in this:

<hr width="80 %">
<hr style="position: absolute; width: 80 %">
The first line's width is 80 %, and the second is just few pixels?

Regards,
Talthen

 

[Marc]

And why in this:

<hr width="80 %">
<hr style="position: absolute; width: 80 %">
The first line's width is 80 %, and the second is just few pixels?

I presume you're looking at this in IE? In which case, the invalid HTML
is taken as you intended it - an <hr> which is 80% the width of it's
parent tag, and the invalid CSS is taken to mean 80px, which is
obviously wrong.

I'm not sure about the first example, but certainly with the second, if
complying with the standards, the width styling should be ignored by the
browser, as the CSS is invalid.

This exactly proves the point as to why invalid CSS should be ignored -
where here you intended IE to display an <hr> of width 80% of it's
parent, you in fact got an <hr> of width 80px.

Clever IE. *pets*

Marc

 

[Guest]

This exactly proves the point as to why invalid CSS should be ignored -
where here you intended IE to display an <hr> of width 80% of it's parent,
you in fact got an <hr> of width 80px.

MSIE shows both lines as 80 % long. Mozilla and Opera show only first line
as 80 % long. The second is about 2 or 3 pixels long. And the question is:
why in pure html the space between 80 and % doesn't make a difference and in
CSS it does?

Regards,
Talthen

 

[Jonathan N. Little]

Toby Inkster wrote:

Bah! Now I'll have to make a page demonstrating:

<textarea rows=4 cols=40 style="visibility:hidden">
a
b
c
d
e
f
</textarea>

Why? Is FF and Moz supposed to incorrectly display the textarea, because
it doesn't...FF1.0.7 or Moz1.7.12 or am I missing something. Only
failure I found was NN4.6 but that goes without saying!

 

[Jim Higson]

MSIE shows both lines as 80 % long. Mozilla and Opera show only first line
as 80 % long. The second is about 2 or 3 pixels long. And the question is:
why in pure html the space between 80 and % doesn't make a difference and
in CSS it does?

Browsers tend to compensate for bad HTML more than bad CSS because the de
facto rules on what bad HTML to accept were created in the 'wild west'
early days of the web, when browser makers regularly disregarded the specs.

CSS support was added later, when the browser makers had learned from the
mistakes of the past to stick more closely to the spec. Today even IE7
looks like it will be pretty standards compliant.

Specifically, disregarding invalid CSS rules is good because it makes future
compatability easier. A CSS2 browser should still be able to make a good go
at rendering most of a CSS3 styled documents, even though it won't
recognise all the rules. If the CSS2 browser started trying to guess what
all the unrecognised rules meant there'd be chaos.

 

[Jonathan N. Little]

I mean- the number of spaces differ between : and 3, I also can write
"width:3" and it will work.
So where's the logic- sometimes spaces are ingored, sometimes not?

And why in this:

<hr width="80 %">
<hr style="position: absolute; width: 80 %">
The first line's width is 80 %, and the second is just few pixels?

Regards,
Talthen

Because as I wrote elsewhere inthis thread:

Remember this is a property value, not a description, the property like
the values are one word entities: it's 'background-color' not
'background color', right? This is a 'script' to be evaluated by a
program, your browser, not a human.

I gather regular expressions are used to parse the properties and values.

':' separates the property for the value or values
'whitespace' separates the property values
';' separates the properties and values pairs

If you put a whitespace between the value’s value and the value’s units
specifier the parser would be confused as two as separate property values

read the spec:
http://www.w3.org/TR/CSS21/syndata.html

To understand this you have to think like software not as a human.
Humans can usually makes sense out of with ambiguous, incomplete or
erroneous data, computers do not. When a program tries to out-guess the
data, well MS keeps trying ;-) Try entering a list of names in a Excel
SS column in this order "Mary Jane", "Mary Jo", "Mary"...

 

[Toby Inkster]

"width: 3px" and you cannot "width: 3 px". Where's the logic? Out of
standard?

CSS isn't an SI standard.

 

[Alan J. Flavell]

Browsers tend to compensate for bad HTML more than bad CSS because the de
facto rules on what bad HTML to accept were created in the 'wild west'
early days of the web, when browser makers regularly disregarded the specs.

There's something in what you say, but CSS is older than you seem to
be making out...

CSS support was added later,

Well, yes, to the popular browsers: but there had been experimental
implementations of an early version for quite some time already
(overshadowed by the unfortunate stampede to Netscape's presentational
quasi-HTML from which we're now suffering the legacy); the CSS mandate
to ignore constructions which the client does not understand, goes
back to the early days of the CSS language - and you already know what
motivated it, because you mention it below.

MSIE 3.x, as usual for MS, happily disregarded the mandate, and (IIRC)
interpreted em units (which it did not understand) as px units (which
it thought it did), with the obvious consequences.

Specifically, disregarding invalid CSS rules is good because it makes future
compatability easier.

Just so!

If the CSS2 browser started trying to guess what
all the unrecognised rules meant there'd be chaos.

Indeed there was!

cheers

 

[Jim Higson]

There's something in what you say, but CSS is older than you seem to
be making out...

I didn't realise how old CSS was!

{snip}

Just so!

Another neat benefit is it allows vendor-specific CSS 'extentions' to be
added without causing too many problems.

In the content layer (HTML etc) this would be a bad thing, but if browsers
that don't recognise proprietary style rules ignore them, the degrading can
be pretty graceful. For example, recent Gecko builds (FF1.5 etc) provide an
early draft of css3 column support (try -moz-column-width etc) while the
W3C are still working on the spec. This way they clearly mark their
implementation as experimental and subject to change without notice but can
still put it in official builds for testing and not interfere with other
browsers.

It also allows some very ugly stuff to be added, for example the filter
property in MSIE that never really took off (I'd bet they drop support
after IE7). But at ignoring what you don't recognise isolates other
browsers from trying to interpret hacks to force IE to show transparent
PNGs.