Closed Bug 24055 Opened 25 years ago Closed 25 years ago

{compat} CSSParser should allow space between value and unit

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: Scott.Springer, Assigned: pierre)

Details

Attachments

(1 file)

Captures of screen shots of code rendered in mozilla and in IE
48.29 KB, image/jpeg
Details 
The following piece of code is not rendering as it should in mozilla:

----------
<head>
  <title>positioning test</title>
</head>
<body>
    <div style="text-align: center; position: relative; left: 21.3 pc; width:
12pc;">/<SMALL>S</SMALL>/ M<SMALL>ICHAEL </SMALL>A. M<SMALL>ICHAEL</SMALL></div>
    <div style="align: left; position: relative; left: 19.8 pc;">By:</div>
    <div style="position: relative; left: 21.3 pc; width: 12pc;">
        <HR SIZE=1 NOSHADE style="width: 12pc;">
    </div>
    <div style="text-align: center; position: relative; left: 21.3 pc; width:
12pc;"><span style="font-weight: bold;">Michael A. Michael</span></div>
    <div style="text-align: center; position: relative; left: 21.3 pc; width:
12pc;"><span style="font-weight: bold;">Chief Executive Officer</span></div>
</body>
----------

What occurs is the text and rule, which should appear about 21 picas indented
on the page, render flush left.  They render properly in IE 5.x.  I hope the
attached image I'm sending along helps demonstrate the issue better.

BTW, this happens in Mozilla for Windows NT as well.
The style is specified with a space in the length unit.

       <div style=" ... left: 21.3 pc; ... ">
                                 ^^^

Technically, that's incorrect:
  http://www.w3.org/TR/REC-CSS1#length-units
    "The format of a length value is an optional sign character ('+' or
     '-', with '+' being the default) immediately followed by a number
     (with or without a decimal point) immediately followed by a unit
     identifier (a two-letter abbreviation). After the '0' length, the
     unit identifier is optional."
  and repeated in the CSS2 spec.

Specifying 'left: 21.3pc;' works correctly, but the length unit with a
space works in Nav4.6.
While I understand that the W3 spec states that there should not be whitespace
between the value and the unit specifier, the fact is that IE 5.x does allow
that space to be there.  Designers are going to be sitting around scratching
their heads, wondering why their stylesheets don't work in Netscape while they
do work in IE.

Here at Donnelley, we have a large group of production workers, some of whom
only see a computer at work, who have the potential to be doing QTA (Quick Turn
Around) adjustments to documents that need to be filed within a matter of
minutes with the SEC.  They don't need to be worrying about an extra space
between the value and the units, and to be honest, they probably wouldn't
figure it out in time.

This is a trivial issue to some - I'll admit that.  However, IMHO I feel that
the CSS parser should be as user friendly as possible.  It's not uncommon for
people to put spaces between values and units, and the parser should probably
be adjusted to read until it reaches a semicolon or a closing quote before
throwing the property and value combination away as invalid.  I hate to throw
in the fact that IE does it, but it does and in all honesty it makes sense.
Status: NEW → ASSIGNED
Target Milestone: M14
It sucks but you're right. It's a common mistake to put a space between the value
and the unit and especially it's supported by the other browsers.

Question: should we support this only in NavQuirks mode?

Note: That will require changes in nsCSSScanner::Next() and maybe ParseNumber().
Summary: Problem with positoning algorithms for CSS → [4.xP]CSSScanner should allow space between value and unit
Changing the Summary to "[4.xP]CSSScanner should allow space between value and
unit" from "Problem with positoning algorithms for CSS"
Yes, I have mixed feelings about this: the average user goes by what
works and would typically view this as a bug since Nav4.x and IE
(unfortunately) allow this.

On the other hand, while 'width: 10 px;' is simple, stuff like
'border-width: thin 0 px medium;' becomes messy: Is that a
"top/(left+right)/bottom" triple, or is it "top/left/right/bottom" with an
error for the right value. Do you only forgive the space in an unambiguous
context, or is that too inconsistent. Sigh.

> Question: should we support this only in NavQuirks mode?

 cc: dbaron, the master of CSS. I guess the real issue is whether this has
any implications for CSS3 compatibility. (Otherwise, yet another quirks
option seems overkill). [Perhaps, CSS3 or CSS2 errata may choose to
grandfather this behaviour). dbaron?
IMO, this is a bad idea.  I think there are serious forward compatibility issues
here, but I don't have time to think it through thoroughly right now.  For a
start, how would you handle shorthand properties (margin, padding, border-width)
and clip rect() without commas (which was an error in the spec that probably
should be supported).  What would happen if some properties start allowing
unitless numbers that do not do so now?  What about some new syntax for min/max
constraints on length values?

IE5 pretty much tries to handle anything, and therefore it destroys forward
compatibility even with many parts of CSS2 (which was released well *before*
IE5).  It's not a good idea to emulate it.
In a separate mail, I asked Ian to give his opinion on this. I think that there
is a consensus to not allow this syntax in strict mode. The question is: do we
allow it in NavQuirks mode when there is no possible confusion (ie. in the case
where we have |value|<space>|unit|<semicolon>)?
I would strongly prefer not having to do that, but I guess you might have to.

Is it easy to make such a change to the parser for only some cases without
messing other things up?
Summary: [4.xP]CSSScanner should allow space between value and unit → [4.xP]CSSParser should allow space between value and unit
I wish... The CSS language was designed with a simple, elegant and very square
syntax and Peter implemented it in an equally simple and elegant way. We have a
very small number of tokens (identifier, @keyword, #id, number/dimension and
"string": that's it). The scanner really expects the length value and the length
unit to be part of the same token and it passes them together as part of the same
structure (nsCSSValue) to the parser.

Basically the problem is that if we allow a space between the two tokens
representing the value and the unit, we end up with the second token changing in
a certain way the properties of the first token. It's quite foreign to the way
the language was designed.

To support this quirk, we would have to implement a fairly generic mechanism that
does the following:
- check that the current property accepts lengths values,
- if so, check that the current token is a value without a unit,
- if so, scan the next token,
- if the next token is a unit, modify the first token (and if not, put it back in
the stream to be read later).

This quirk would apply to *all* the properties that accept one or more length
values... definitely not something that would be good for only some cases as you
could have hoped. Still, I think it's safe to implement it in compat mode only
because I can't see a case where it could create a conflict but since I don't
have your expertise in actually using the language, David & Ian, your comments
are most welcome.
Severity: normal → trivial
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → INVALID
Summary: [4.xP]CSSParser should allow space between value and unit → {compat} CSSParser should allow space between value and unit
NO! NO! We do _not_ want to be doing this!

The only reason to do this is to cope with *mistakes* that authors have made.
Passing a stylesheet through the W3C validator:
   http://jigsaw.w3.org/css-validator/
...will *immediately* flag this error. Therefore there is no excuse for authors
to not find it! And it is a three second fix!

There are already dozens and dozens and dozens of CSS bugs in IE5 that we do not
reproduce (i.e., that we do correctly). Authors are bound to *easily* come
across these -- and getting them to blame IE5 and not us is something for
marketing and evangelisation to deal with.

WE ARE CORRECT. Let's concentrate our efforts on genuine bugs rather than try
to emulate previously broken behaviour.

Marking INVALID. Changing [4.XP] to {compat}. Reducing severity. Marking XP.
I certainly trust your experience on that matter.
Thanks for helping us to do the right thing.
Verified invalid.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: