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. :-)

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.

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.

I'll do it at the same time as I add aural properties. Marked dependency on bug 47159.

Removing css2 keyword, this bug isn't about feature support.

Assigning pierre's remaining Style System-related bugs to myself.

this would be cool.. cc'ing jkeiser in case he feels like poking at this...we'd need a configure.in test of course...

Is another possibility to somehow move it into the accessibility dll so that it only gets loaded when accessibility gets loaded?

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.

Comment on attachment 118368 [details] draft preemptively killing my patch so it doesn't appear on queries.

Now bug 125246 has been fixed, does this bug still needs investigation?

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.