Closed Bug 97522 Opened 23 years ago Closed 23 years ago

font-size: <LENGTH> without unit got ignore.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 92623
Milestone:
mozilla0.9.4

People

(Reporter: ftang, Assigned: pierre)

Details

(Keywords: topembed)

Attachments

(3 files)

test page
182 bytes, text/html
Details
testcase in quirks mode
292 bytes, text/html
Details
testcase in strict mode
382 bytes, text/html
Details 
this is blocking bugscape bug 6440
What happen is the following, the style sheet size 
font-size:12
instead of font-size: 12px or font-size:12pt
and mozilla ignore it (try 48 and you well see it better)
It seems while the unit is absent, IE use px and mozilla totally ignore it. This
happen not only the form <SELECT> but also normal text.
Attached file test page — 

    
    

    
  
try the test page with both IE and N6.1 (or Mozilla)
as you can see, in IE the first and third line display in 48 pixel and the 2nd
line display as 48 point font
in Mozilla, we display the first line  in 48 pixel , 2nd line as 48 point and
the problem is in the third line we display as default font size. 
Expect behavior- the third line display as the size size of 48 pixel.

I look into CSS2
15.2.4 Font size: the 'font-size' and 'font-size-adjust' properties

'font-size'
    Value:   <absolute-size> | <relative-size> | <length> | <percentage> | inherit
    Initial:   medium
    Applies to:   all elements
    Inherited:   yes, the computed value is inherited
    Percentages:   refer to parent element's font size
    Media:   visual

and 
<length>
A length value specifies an absolute font size (that is independent of the user
agent's font table). Negative lengths are illegal.

4.3.2 Lengths
...
 The format of a length value (denoted by <length> in this specification) 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 (e.g., px, deg, etc.). After the '0' length, the unit
identifier is optional.

notice it said "the unit identifier is optional."

I see no wording of default unit. Therefore, if we use "px" as default unit
while unit identifier is absent, it won't violate the standard. Since the unit
identifier is optional, the current behavior is violate the standard. 
Assignee: dbaron → pierre

    
    

    
  
mark as topembed since it block bugscape 5640 and therefore block bugscape 7970
Keywords: topembed

    
    

    
  
sorry, last commt should be
"mark as topembed since it block bugscape 6440 and therefore block bugscape 7970"

    
    

    
  
Treating numbers without units as pixel length is explicitly contrary to the
standard.  (See section 7.1 of CSS1, and the equivalent part of chapter 4 of
CSS2.)

    
    

    
  
Mozilla displays the test case as you suggest it ought to (since the testcase is
in quirks mode).  We follow the standard in strict mode.

    
    

    
  
Frank, 

"After the '0' length, the unit identifier is optional" != 
  "the unit identifier is optional"



    
    

    
  
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fbugzilla.mozilla.org%2Fshowattachment.cgi%3Fattach_id%3D47559&warning=1&profile=css2

    * Line: 3

      Invalid number : font-size only 0 can be a length. You must put an unit
after your number : 48
-------------------
Marking INVALID.  Quirks mode works as you expect it to, but standards mode will
rightly ignore it because of the error confirmed by the CSS Validator.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID

    
    

    
  
Reopening.  We made it clear to Franck in Bugscape 7970 that lengths need units 
in strict mode. The real problem is the following...


------- Additional Comments From Marc Attinasi 2001-08-29 12:49 -------

In NS6.1, the testcase shows that no default unit was applied. In the most
recent branch (0.9.2) build, I see what Pierre saw - we default to the 'px'
unit. Anybody know when this was fixed, or a bug number? My testing shows that
we apply the default unit in Standard and Quirks mode (so we are disobeying
CSS2's error handling requirements in standard mode).

------- Additional Comments From Pierre Saslawsky 2001-08-29 13:42 -------

I confirm what Marc saw: the quirk is not applied in Nav6.1 and apparently 
neither in builds that go pretty far back in time.  The *really* suprising thing 
is that the other old quirk which interprets colors in XXYYZZ format without a 
leading '#' does work in all these builds. Both these quirks (missing 'px' and 
missing '#') are applied at the same place and rely on the same boolean 
'mNavQuirkMode'.  Maybe the problem is in the scanner, or in error reporting 
between scanner and parser.  

Marc or someone else: could you please try to pinpoint the date where the quirk 
worked again?  It is sometime between 08/09 and 08/27.  I have another urgent bug 
to look at today. Thanks.

03/26 moz 0.8.1: BAD
05/07 moz 0.9.0: BAD
06/07 moz 0.9.1: BAD
06/08 moz trunk: BAD
06/26 moz trunk: BAD
06/29 moz trunk: BAD
07/17 moz trunk: BAD
07/31 NS6 trunk: BAD
08/01 moz trunk: BAD
08/09 moz trunk: BAD
08/27 moz trunk: good
current moz debug build: good

Status: RESOLVED → REOPENED
Resolution: INVALID → ---

    
    

    
  
In fact, what I'm seeing is that during several months the quirk was gone, and it 
came back sometime between 08/09 and 08/27.

Unlike Marc, however, I don't see the quirks applied in strict mode.  Marc: could 
you please test with the two testcase that I'm going to attach? Thanks.

Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.4

    
    

    
  


  

    
    

    
  


  

    
    

    
  
CCd folks who are CCd on Bugscape #7970


    
    

    
  
The quirk did not work in the following builds:
    Mac 2001-08-13-16 moz trunk
    Win 2001-08-13-15 moz trunk

It started to work again in the following builds:
    Mac 2001-08-14-04 moz trunk
    Win 2001-08-14-06 moz trunk

The strict mode was always fine.

I looked at the checkins between 08-13-12 and 08-14-06 but there was nothing 
really suspicious.

Do we need to find a fix for the 0.9.2 branch, or can we consider the matter 
closed because it is going to work on the 0.9.4 branch?


    
    

    
  
Speaking of the devil, this message appeared _today_ on CSS WG mailing list...
Guessing it closes the debate !-)

From Håkon Lie <howcome@opera.com> :
------------------------------------

Also sprach Chris Lilley:

 > font="900 900 900"
 > > does that mean a weight of 900, a size of 900 and the font family is
 > called "900" or does it mean the default weight, a size of 900 and the
 > font family is called "900 900"
 > > This is ambiguous without a unit identifier. 

Right. But the unit identifier is required on the 'font-size' value,
so the declaration should be thrown out before the question of
ambiguousness arises.

(BTW, I assume you mean: "font: 900 900 900")

-h&kon

    
    

    
  
On Linux, both the 2001-08-13-08-trunk and 2001-08-13-21-trunk builds had the
quirk working correctly.

    
    

    
  
On Linux, the quirk seems to have been fixed between 2001-08-10-08-trunk and
2001-08-11-06-trunk.

    
    

    
  

*** This bug has been marked as a duplicate of 92623 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE

    
    

    
  
I am sorry, I am so stupid that I didn't see the "if the length is 0" part. I
definitely out of my mind yesterday afternoon. 

    
    

    
  
Pierre, I know whtat it is now. I tested Quirks vs. Standard mode using the
switch in Viewer that forces the mode (menu item: Style | Compatability Mode
Pref), but that only changes the layout-mode in the *presentation*, and from
what I recall, the CSSParser uses the DTD mode from the document. I remember you
and I discussing the two flags and concluding that they are equivalent, but in
this case they are not! 

Using your testcase, with the strict doctype, the quirk is not invoked, as
expected. I am still a tiny bit leary about the discrepancy between the
presContext's layout-mode and the document's DTD-Mode, mostly because the
mechanism in Viewer is so convenient and only tweaks the presentation's mode
flag, not the document's.

    
    

    
  
verified duplicate of a bug that i personally fixed before this bug was opened.
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: