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 25932 - many links point at whatwg specs
Summary: many links point at whatwg specs
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: DOM4 (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Robin Berjon
QA Contact:
URL:
Whiteboard:
Keywords: CR
Depends on:
Blocks:
 
Reported: 2014-05-31 08:19 UTC by Glenn Adams
Modified: 2014-06-24 14:51 UTC (History)
0 users

See Also:


Attachments

Description Glenn Adams 2014-05-31 08:19:09 UTC
The following concept and type related links point at whatwg specs but should point at the w3c edition of the spec:

* alias (concept origin alias)
* ASCII whitespace
* compound microtask
* createContextualFragment() (dom range createcontextualfragment)
* effective script origin
* encoding
* execute a compound microtask subtask
* input (the input element)
* HTML parsing
* load() (dom xmldocument load)
* name (of the encoding)
* origin
* Queue (queue a microtask)
* script (the script element)
* unit of related similar-origin browsing concepts
* utf-8

Just search the source file for links to whatwg.org for a complete list.
Comment 1 Robin Berjon 2014-06-20 14:38:14 UTC
The majority of those have been replaced to point to the W3C version, but not all since in some cases the WHATWG version is the ED for the W3C version (e.g. Encoding).
Comment 2 Glenn Adams 2014-06-20 14:57:55 UTC
(In reply to Robin Berjon from comment #1)
> The majority of those have been replaced to point to the W3C version, but
> not all since in some cases the WHATWG version is the ED for the W3C version
> (e.g. Encoding).

Could you create a new bug that tracks the remaining links needing updates? I'm not comfortable with closing this and leaving the remaining links dangling unless there is something tracking them.
Comment 3 Robin Berjon 2014-06-23 08:20:18 UTC
(In reply to Glenn Adams from comment #2)
> Could you create a new bug that tracks the remaining links needing updates?
> I'm not comfortable with closing this and leaving the remaining links
> dangling unless there is something tracking them.

I don't mind leaving it as RESOLVED LATER if you want to use it as a tracking bug.
Comment 4 Glenn Adams 2014-06-23 15:13:00 UTC
(In reply to Robin Berjon from comment #3)
> (In reply to Glenn Adams from comment #2)
> > Could you create a new bug that tracks the remaining links needing updates?
> > I'm not comfortable with closing this and leaving the remaining links
> > dangling unless there is something tracking them.
> 
> I don't mind leaving it as RESOLVED LATER if you want to use it as a
> tracking bug.

I need some bug that is marked as OPEN that tracks the remaining links.
Comment 5 Robin Berjon 2014-06-24 11:28:56 UTC
(In reply to Glenn Adams from comment #4)
> I need some bug that is marked as OPEN that tracks the remaining links.

Can you clarify the reasoning behind this request? The whole point of LATER is precisely to revisit it for future tracking.
Comment 6 Glenn Adams 2014-06-24 14:51:41 UTC
(In reply to Robin Berjon from comment #5)
> (In reply to Glenn Adams from comment #4)
> > I need some bug that is marked as OPEN that tracks the remaining links.
> 
> Can you clarify the reasoning behind this request? The whole point of LATER
> is precisely to revisit it for future tracking.

First, unless all aspects of the bug are addressed, then I don't consider it RESOLVED. Second, I am concerned that if not marked OPEN, it will fall through the cracks, e.g., it may fail to be reported as an open issue when doing a director's call. Third, many people who review the bug lists don't look at RESOLVED, but only OPEN bugs. Fourth, I don't see a process item in the WG that indicates that RESOLVED LATER bugs will be reviewed prior to moving the document forward.

I'd be happy to raise these points during the next HTMLWG call.