Closed Bug 70022 Opened 21 years ago Closed 14 years ago

#ifdef AURAL portions of the style system


(Core :: CSS Parsing and Computation, enhancement, P4)






(Reporter: attinasi, Unassigned)


(Depends on 1 open bug)


(Keywords: memory-footprint)


(1 obsolete file)

Mostly in nsCSSPropList and nsCSSDeclaration - we could reduce a bunch of code
and static data space by #ifdef'ing the (currently unused) AURAL stuff out by
default. Aural browser developers building on Mozilla would only have to throw
the #define and would thus be laregly unaffected. Comments?
We'd be reducing our CSS2 support -- WinIE also supports having the aural stuff
in the DOM. Removing it may alleviate our problems, but presumably wouldn't be
solving the real problem. Most (typically all!) elements have absolutely no 
aural style applied to them beyond the initial values. They should therefore not
require any memory and not require any processing power. It seems to me that if
they are a burden on the style system that points to a requirement for a change
in the design rather than their removal.

cc'ing glazou, who likes to argue that we should support everything especially
if the competition are going to implement it. :-)
Keywords: css2
I don't remember who to cc for embed issues, i think that adding the #ifdef and 
then having mozilla always build w/ it on would be fine.
Keywords: embed
That is the idea: let the build decide if they want it or not. In efforts to
make things as small as possible for toe-nail browsers that are powered by
brownian motion and blood-pressure (where memory is at a premium), we could do
without the aural properties in the DOM, I think.
So long as we are not talking about the Mozilla default, and, for the Netscape 
people, so long as we are not talking about Mojo, then yeah, that's fine! :-)
At some point screen readers will be able to get this information through our
nsIAccessible interface. If that becomes commonly useful, we may later want it
back in as the default.
Keywords: embedfootprint
Blocks: 72562
I'll do it at the same time as I add aural properties.  Marked dependency on bug 
Severity: normal → enhancement
Depends on: 47159
Priority: -- → P3
Target Milestone: --- → Future
Removing css2 keyword, this bug isn't about feature support.
Keywords: css2
Priority: P3 → P4
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
this would be cool.. cc'ing jkeiser in case he feels like poking at this...we'd
need a test of course...
Is another possibility to somehow move it into the accessibility dll so that it
only gets loaded when accessibility gets loaded?
Attached file draft (obsolete) —
not bad.

I'd like to see this be something like --disable-aural-css or something, and
make the #ifdef be a DISABLE_AURAL or something, at least to indicate that the
normal state is that it is enabled.  INCLUDE_XUL is NOT a model for this. :)

Anyone want to comment on my idea? I wish we could set it so there is no extra
code footprint in the normal case, but that when the accessibility APIs are
loaded we can still have this.

That way, if a screen reader asks a DOM node its the aural style info via our
accessibility API, it still can. This is useful information for a screen reader.
I have only one problem with this. If a third-party wants to build an add-on to
Mozilla (I said an add-on, not a specific client) with ACSS speech capabilities,
removing the aural properties from the DOM could block them.
BTW, CaScadeS, my CSS editor for Composer, allows to edit Aural styles... I will
have to remove that if AURAL is ifdef'd.
look everyone, we're not talking about disabling AURAL stuff for the default
mozilla builds - this is to provide embeddors with Yet Another Feature to
disable, to save disk and memory footprint. This wouldn't be disabled in the
GRE, and it wouldn't be disabled in seamonkey, phoenix, camino, you name it.
Once bug 125246 lands, the codesize benefit of doing this would probably be at
most a few kilobytes.  Before it lands, it would just cause me additional merge
conflicts in trying to get a much larger codesize and runtime footprint win into
the tree.
I see. As long as it's enabled by default that's fine with me.
Fine for me too.
I think it might still be worth investigating, but it should by no means hamper
dbaron's work in bug 125246... lets hold off on this for now.
Depends on: 125246
Comment on attachment 118368 [details]

preemptively killing my patch so it doesn't appear on queries.
Attachment #118368 - Attachment is obsolete: true
Attachment #118368 - Attachment is patch: false
Now bug 125246 has been fixed, does this bug still needs investigation?
Assignee: dbaron → nobody
QA Contact: ian → style-system
I think this is wontfix; I think we actually do want to expose aural CSS to getComputedStyle so that extensions, etc., can experiment with it.  That's currently covered by bug 47159.
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.