This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7158 - this is a discribing comment
Summary: this is a discribing comment
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2009-07-28 12:41 UTC by contributor
Modified: 2010-10-08 08:05 UTC (History)
5 users (show)

See Also:


Description contributor 2009-07-28 12:41:22 UTC

this is a discribing comment

Posted from:
Comment 1 Maciej Stachowiak 2010-03-14 14:48:37 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 2 Larry Masinter 2010-03-19 23:27:49 UTC
Just spot-checking the closed issues. It seems like the comment has something to do with the "Garbage Collection" section. Why is Garbage collection a part of the hypertext markup language and associated APIs? How could this be tested?  Isn't this just an implementation technique? Do all JavaScript implementations have to use the same style of garbage collector?

For example, the term "strong reference" is used. There is no particular way of determining whether a garbage collector exists, uses strong references, uses some other garbage collection technology. This section might belong in an implementor's guide, but it doesn't belong in this document, as it doesn't even apply to any particular conformance class, isn't the result of "reverse engineering".

If there's some invariant here that this implementation advice is trying to hint at, the invariant isn't clearly specified. "Pointers shouldn't become invalid"?

Comment 3 Ian 'Hixie' Hickson 2010-03-31 20:51:54 UTC
The original bug was not a valid bug. If you have specific issues with garbage collection, please file new bugs.