Closed Bug 609555 Opened 14 years ago Closed 12 years ago

beforescriptexecute/afterscriptexecute should use moz prefix or should be defined in some specification

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: smaug, Unassigned)

References

Details

(Keywords: dev-doc-needed)

If we do this, this should happen before ff4. But in general, we really shouldn't add random new events to web platform without prefixing them.
Blocks: 587931
blocking2.0: --- → ?
Given that people generally seemed happy with this suggestion on the list, and given that the events are simple events with no data on them, it seemed very unlikely that there will be incompatible changes here. The three types of changes I could think of people asking are: 1. Wanting to make more data available on the event. Not a problem since we can always add properties that aren't there without worrying about compat. 2. Wanting different names. Not a problem since it wouldn't be a name collision. 3. Wanting the events to fire at slightly different points in time. This could in theory be a problem, but there really isn't much that the time of firing the event could be adjusted here. Only thing is if it should be before or after the 'load' event, or before or after we set the document.write insertion point. Either of these changes we could probably do without worrying about breaking people.
FWIW, I agree with sicking's reasoning and I think this bug should be WONTFIX.
Well, another solution for this is the get this defined in some spec.
Summary: beforescriptexecute/afterscriptexecute should use moz prefix. → beforescriptexecute/afterscriptexecute should use moz prefix or should be defined in some specification
Seems there's agreement on us not wanting to change this, but yeah, we should get this into a spec. Not blocking on that though.
blocking2.0: ? → -
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.