Closed Bug 839443 Opened 12 years ago Closed 12 years ago

API for helping get all CSS property names

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla22

People

(Reporter: miker, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

At the moment in our computed style view (DevTools) we currently iterate the computed styled of document.body in order to get the list of possible property names. An API to get this list would be much tidier than using this hack, an array would be fine. I would suggest domUtils.getCSSPropertyNames()
So the API I'm thinking of looks something like this: const unsigned long EXCLUDE_SHORTHANDS = (1<<0); const unsigned long INCLUDE_ALIASES = (1<<1); void getCSSPropertyNames([optional] in unsigned long aFlags, [optional] out unsigned long aCount, [retval, array, size_is(aCount)] out wstring aProps); One question: For properties that are controlled by a pref, should the API return them always, or only when enabled? Or should it be possible to use another flag to control that behavior (and if so, what should the default be)?
Flags: needinfo?(mratcliffe)
(In reply to Boris Zbarsky (:bz) from comment #1) > One question: For properties that are controlled by a pref, should the API > return them always, or only when enabled? I think that only when enabled makes the most sense.
Flags: needinfo?(mratcliffe)
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Attachment #724759 - Attachment is obsolete: true
Attachment #724759 - Flags: review?(dbaron)
Attachment #724762 - Flags: review?(dbaron)
Comment on attachment 724762 [details] [diff] [review] Add an API for getting our supported CSS property names in inspector code. >+#define DO_PROP(_prop) \ >+ PR_BEGIN_MACRO \ >+ nsCSSProperty cssProp = nsCSSProperty(_prop); \ >+ if (nsCSSProps::IsEnabled(cssProp)) { \ >+ props[propCount] = \ >+ ToNewUnicode(nsDependentCString(kCSSRawProperties[_prop])); \ >+ if (!props[propCount]) { \ >+ NS_FREE_XPCOM_ALLOCATED_POINTER_ARRAY(propCount, props); \ >+ return NS_ERROR_OUT_OF_MEMORY; \ >+ } \ You don't need to handle OOM here; it's ToNewUnicode (which has a null check that's no longer needed) -> AllocateStringCopy -> nsMemory::Alloc -> NS_Alloc >+ ++propCount; \ >+ } \ >+ PR_END_MACRO >+ >+ // prop is the property id we're considering; propCount is how many properties >+ // we've put into props so far. >+ uint32_t prop = 0, propCount = 0; >+ for ( ; prop < eCSSProperty_COUNT_no_shorthands; ++prop) { >+ if (!nsCSSProps::PropHasFlags(nsCSSProperty(prop), >+ CSS_PROPERTY_PARSE_INACCESSIBLE)) { I tend to think inspector might want these, in some cases at least. (Though perhaps not; it would be nice if not.) r=dbaron
Attachment #724762 - Flags: review?(dbaron) → review+
> You don't need to handle OOM here Ah, excellent.
Flags: in-testsuite?
Whiteboard: [need review]
Target Milestone: --- → mozilla22
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Keywords: dev-doc-needed
Blocks: 893965
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: