Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 289378

Summary: [parser] CSSTokenizer should allow asterisk preceding property
Product: [WebTools] WTP Source Editing Reporter: Ian Tewksbury <itewksbu>
Component: wst.cssAssignee: Ian Tewksbury <itewksbu>
Status: CLOSED FIXED QA Contact: Nick Sandonato <nsand.dev>
Severity: normal    
Priority: P2 CC: nsand.dev
Version: 3.2Flags: nsand.dev: review+
Target Milestone: 3.2 M3   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Suggested Patch
none
Fix Patch none

Description Ian Tewksbury CLA 2009-09-14 13:32:03 EDT 
Created attachment 147122 [details]
Suggested Patch

There is a "CSS hack" that uses the asterisk character preceding a property.
http://www.webdevout.net/css-hacks#unrecommended-asterisk_prefix

EX:
body {
    font: 13px Myriad,Arial,Helvetica,clean,sans-serif;
    *font: x-small;
}

The current problem is that the asterisk character gets marked as an UNKNOWN
region and then the following property, in this case "font" gets tokinzed as a
property.  This causes there to be two "font" properties in the style
definition and when requesting the value of the "font" property the value for
the "*font" property would be returned and the value for "font" would be
ignored (if you switched their order in the style the result would be
opposite).  Essentially this means the "*font" and "font" are the same property
but when browsers go to read the css they are considered as two different
properties (some see *font as invalid and ignore others process it).

While I do not think our tooling needs to or should tool around CSS hacks, in
this case I think there is a safe compromise.  If we allow for the asterisk to
precede a property then "font" and "*font" will be considered two different
properties.  In this way when requesting the value for "font" the correct value
would be returned.

I have run all SSE JUnits with the attached patch with no errors.

Comments, questions, suggestions, etc are appreciated on this matter.
Comment 1 Nick Sandonato CLA 2009-09-28 17:44:56 EDT 
Hey Ian, one of the changes I would make to this is instead of making * a valid part of any identifier, since the ident macro is used in numerous places, I would restrict it to being used in the state ST_DECLARATION.

This scenario may also be worth a unit test.
Comment 2 Ian Tewksbury CLA 2009-10-02 14:34:35 EDT 
Created attachment 148676 [details]
Fix Patch

(In reply to comment #1)
> Hey Ian, one of the changes I would make to this is instead of making * a valid
> part of any identifier, since the ident macro is used in numerous places, I
> would restrict it to being used in the state ST_DECLARATION.
> 
> This scenario may also be worth a unit test.

done.
Comment 3 Nick Sandonato CLA 2009-10-05 11:24:13 EDT 
Thanks, Ian. Patch looks good.
Comment 4 Ian Tewksbury CLA 2009-10-19 11:49:41 EDT 
Verified in I-3.2.0-20091017071807