#ifdef AURAL portions of the style system

RESOLVED WONTFIX

Status

()

Core
CSS Parsing and Computation
P4
enhancement
RESOLVED WONTFIX
17 years ago
3 years ago

People

(Reporter: Marc Attinasi, Unassigned)

Tracking

(Depends on: 1 bug, {footprint})

Trunk
Future
footprint
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 years ago
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! :-)

Comment 5

17 years ago
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.

Updated

17 years ago
Keywords: embed → footprint

Updated

17 years ago
Blocks: 72562

Comment 6

17 years ago
I'll do it at the same time as I add aural properties.  Marked dependency on bug 
47159.
Severity: normal → enhancement
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW

Comment 9

15 years ago
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

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

Comment 11

15 years ago
Created attachment 118368 [details]
draft

Comment 12

15 years ago
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

15 years ago
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.

Comment 16

15 years ago
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.

Comment 18

15 years ago
I see. As long as it's enabled by default that's fine with me.
Fine for me too.

Comment 20

15 years ago
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 21

15 years ago
Comment on attachment 118368 [details]
draft

preemptively killing my patch so it doesn't appear on queries.
Attachment #118368 - Attachment is obsolete: true
Attachment #118368 - Attachment is patch: false

Comment 22

14 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.