70022 - #ifdef AURAL portions of the style system

Status: RESOLVED WONTFIX

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

Description

[Marc Attinasi]

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?

Comment 1

[Hixie (not reading bugmail)]

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

Comment 2

[timeless]

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.

Comment 3

[Marc Attinasi]

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.

Comment 4

[Hixie (not reading bugmail)]

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

Comment 5

[Aaron Leventhal]

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.

Comment 6

[Pierre Saslawsky]

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

Comment 7

[Christopher Hoess (gone)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 9

[Alec Flett]

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

Comment 10

[Aaron Leventhal]

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

Comment 11

[timeless]

Attachment: draft

Comment 12

[Alec Flett]

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

Comment 13

[Aaron Leventhal]

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.

Comment 14

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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.

Comment 15

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

BTW, CaScadeS, my CSS editor for Composer, allows to edit Aural styles... I will
have to remove that if AURAL is ifdef'd.

Comment 16

[Alec Flett]

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.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 18

[Aaron Leventhal]

I see. As long as it's enabled by default that's fine with me.

Comment 19

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Fine for me too.

Comment 20

[Alec Flett]

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 21

[timeless]

Comment on attachment 118368 [details]
draft

preemptively killing my patch so it doesn't appear on queries.

Comment 22

[Anne (:annevk)]

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

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.