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)
Core
CSS Parsing and Computation
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)
6.26 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
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()
Assignee | ||
Comment 1•12 years ago
|
||
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)?
Assignee | ||
Updated•12 years ago
|
Flags: needinfo?(mratcliffe)
Reporter | ||
Comment 2•12 years ago
|
||
(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 | ||
Comment 3•12 years ago
|
||
Attachment #724759 -
Flags: review?(dbaron)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → bzbarsky
Assignee | ||
Updated•12 years ago
|
Whiteboard: [need review]
Assignee | ||
Comment 4•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #724759 -
Attachment is obsolete: true
Attachment #724759 -
Flags: review?(dbaron)
Assignee | ||
Updated•12 years ago
|
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+
Assignee | ||
Comment 6•12 years ago
|
||
> You don't need to handle OOM here
Ah, excellent.
Assignee | ||
Comment 7•12 years ago
|
||
Flags: in-testsuite?
Whiteboard: [need review]
Target Milestone: --- → mozilla22
Comment 8•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 9•12 years ago
|
||
This should be documented at https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/inIDOMUtils.
Sebastian
Assignee | ||
Updated•12 years ago
|
Keywords: dev-doc-needed
Comment 10•12 years ago
|
||
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/22
https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/inIDOMUtils#getCSSPropertyNames()
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•