Closed Bug 246446 Opened 20 years ago Closed 16 years ago

apple.com - uses relative hrefs that aren't valid

Categories

(Tech Evangelism Graveyard :: English US, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: timeless, Unassigned)

References

()

Details

(Keywords: top500)

visit any developer.apple.com reference page in e.g. Camino and try to click on
a link from the top to its detailed description later in the page. nothing happens.

this sucks.

An example 'url':
http://developer.apple.com/documentation/CoreFoundation/Reference/CFURLAccessUtils/Reference/FunctionGroupIndex.html#//apple_ref/c/func/CFURLCreateDataAndPropertiesFromResource

copied from Safari because it is actually willing to copy something which is
useful, Camino helpfully gives me this: which is utterly useless for the purpose
of filing this bug: 
http://developer.apple.com/documentation/CoreFoundation/Reference/CFURLAccessUtils/Reference/FunctionGroupIndex.html

The actual html (according to Safari, i can't really trust Camino at this point):

<h1>Functions</h1><br>
<table cellspacing=7 valign="top">
<tbody class="content_text"><tr>
<td class="content_text" valign="top" scope="row"><a
logicalPath="//apple_ref/c/func/CFURLCreateDataAndPropertiesFromResource"
href="FunctionGroupIndex.html#//apple_ref/c/func/CFURLCreateDataAndPropertiesFromResource">CFURLCreateDataAndPropertiesFromResource</a></td>
<td class="content_text" valign="top">Loads the data and properties referred to
by a given URL.</td>
</tr>
WFM using Camino/2004060208 (v0.8b+). Clicking
CFURLCreateDataAndPropertiesFromResource spawns a new window and scrolls to
#//apple_ref/c/func/CFURLCreateDataAndPropertiesFromResource.

What build for you, timeless?
WFM.

*****

        <!-- start of path -->
<div class="breadcrumb"><a href="http://developer.apple.com/" target="_top">ADC
Home</a> &gt; <a logicalPath="//apple_ref/doc/uid/TP30000943"
href="../../../../../referencelibrary/index.html#//apple_ref/doc/uid/TP30000943"
target="_top">Reference Library</a> &gt; <a
logicalPath="//apple_ref/doc/uid/TP30000440"
href="../../../../index.html#//apple_ref/doc/uid/TP30000440"
target="_top">Documentation</a> &gt; <a
logicalPath="//apple_ref/doc/uid/TP30000421"
href="../../../CoreFoundation.html#//apple_ref/doc/uid/TP30000421"
target="_top">Core Foundation</a> &gt; <a
logicalPath="//apple_ref/doc/uid/20001496"
href="../../CFAPI-date.html#//apple_ref/doc/uid/20001496" target="_top">Core
Foundation Reference</a> &gt; <a href=""
onClick=top.location.href="../index.html" -->URL Access Utilities Reference</a>
&gt; </div><br>

<!-- end of path -->

Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
hi guys, would you please pay attention to bug components before you go randomly
poking bugs? thank you.

<blockquote src="http://w3.org/TR/html401/types.html#type-cdata">
6.2 SGML basic types

The document type definition specifies the syntax of HTML element content and
attribute values using SGML tokens (e.g., PCDATA, CDATA, NAME, ID, etc.). See
[ISO8879] for their full definitions. The following is a summary of key information:

    * CDATA is a sequence of characters from the document character set and may
include character entities. User agents should interpret attribute values as
follows:
          o Replace character entities with characters,
          o Ignore line feeds,
          o Replace each carriage return or tab with a single space.

      User agents may ignore leading and trailing white space in CDATA attribute
values (e.g., "   myval   " may be interpreted as "myval"). Authors should not
declare attribute values with leading or trailing white space.

      For some HTML 4 attributes with CDATA attribute values, the specification
imposes further constraints on the set of legal values for the attribute that
may not be expressed by the DTD.

      Although the STYLE and SCRIPT elements use CDATA for their data model, for
these elements, CDATA must be handled differently by user agents. Markup and
entities must be treated as raw text and passed to the application as is. The
first occurrence of the character sequence "</" (end-tag open delimiter) is
treated as terminating the end of the element's content. In valid documents,
this would be the end tag for the element.
    * ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed
by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"),
colons (":"), and periods (".").
    * IDREF and IDREFS are references to ID tokens defined by other attributes.
IDREF is a single token and IDREFS is a space-separated list of tokens.
    * NUMBER tokens must contain at least one digit ([0-9]).
</blockquote>

the key here is the bit about ID and NAME tokens *MUST* begin with a letter.
for reference, as indicated in the blockquote, '/' is not a letter.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new
Summary: developer.apple.com uses relative hrefs that aren't valid → apple.com - uses relative hrefs that aren't valid
Sorry timeless, I called it WFM because the links really do Work For Me, no
significant differences between Safari, Moz & FF.

If every instance of invalid syntax on the web is supposed to be an Evangelism
bug, then Mozilla.org will need to buy a MUCH bigger database server.
Keywords: top500
This is not something TE is going to be wasting its time on, since it's equally functional in every major browser I can think of at this point. WONTFIX unless someone can come up with a major modern browser in which this currently fails.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago16 years ago
Resolution: --- → WONTFIX
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.