Closed Bug 246446 Opened 21 years ago Closed 17 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 → ---
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 ago17 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.