apple.com - Repeated and lost content in a <pre> with lots of tags

RESOLVED DUPLICATE of bug 150588

Status

Tech Evangelism Graveyard
English US
RESOLVED DUPLICATE of bug 150588
16 years ago
3 years ago

People

(Reporter: Simon Fraser, Assigned: bc)

Tracking

(Blocks: 1 bug)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
I'm seeing some really bad layout behaviour on the Apple mailing list archives.
The problems include missing or repeated content, which also breaks Find in Page.

I've tried to reduce to a test case, but it's not easy. The problem involves
having a <pre> inside a <table>, and lots of things that look like tags inside
the <pre>, such as:

To: Joe Blow <blow@mac.com>
From: Blo Joe <joe@apple.com>
In-Reply-To: <39799972-0011-11D6-B9BA-000A279431A2@mac.com>
Message-Id: <1BBFA818-005F-11D6-8F1C-0050E490D272@apple.com>
List-Help: <mailto:cocoa-dev-request@lists.apple.com?subject=help>
List-Post: <mailto:cocoa-dev@lists.apple.com>
List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/cocoa-dev>,
	<mailto:cocoa-dev-request@lists.apple.com?subject=subscribe>
List-Id: Discussions regarding native Mac OS X application development using
Cocoa frameworks. <cocoa-dev.lists.apple.com>
List-Unsubscribe: <http://www.lists.apple.com/mailman/listinfo/cocoa-dev>,
	<mailto:cocoa-dev-request@lists.apple.com?subject=unsubscribe>
List-Archive: <http://www.lists.apple.com/archives/cocoa-dev/>

I'll attach a testcase. In the testcase, scroll down to the bottom, and note how
the last few chunks are messed up.

This is a serious usability problem for me. I have to use another browser to
look at the mailing list archives.
(Reporter)

Comment 1

16 years ago
Created attachment 90243 [details]
Testcase, which shows problems near the bottom
Summary: Repeated and lost content in a <pref> with lots of tags → Repeated and lost content in a <pre> with lots of tags
I can't see the actual page because I'm not authorized, but, frankly, I'd say
this is invalid.  PRE is allowed to contain markup within it.  I don't see any
differences between what we do and what WinIE does, and, frankly, if MacIE is
showing you more, than it's on crack.
I assume you mean "is not allowed to contain markup". Over to Tech Evang, 
apple.com needs to un-brain-dead their scripts and escape "<", "&", and any 
other delimiters I've forgotten before writing to the page.
Component: Parser → US General
Product: Browser → Tech Evangelism
Version: other → unspecified
No, PRE is allowed to contain markup:

<!ENTITY % pre.exclusion "IMG|OBJECT|BIG|SMALL|SUB|SUP">

<!ELEMENT PRE - - (%inline;)* -(%pre.exclusion;) -- preformatted text -->
<!ATTLIST PRE
  %attrs;                              -- %coreattrs, %i18n, %events --
  >
Sorry, I wasn't thinking clearly--I mentally parsed that as "unescaped markup".
Anyway, point stands.
(Reporter)

Comment 6

16 years ago
You can log into the mailing list archives with username 'archives' and password
'archives' (those are just to defeat bots).

I'm quite aware that this is bad markup, but what we're doing with it seems very
wrong. We should least attempt to show all the content, even if it looks wrong,
and we do for the first chunk of content. It's only further down the page that
things go bad, and I would guess that there is a real bug lurking there.

Unescaped <> inside of a <pre> would be a fairly common thing, I would think.
Would this be a quirks issue?
(Reporter)

Updated

16 years ago
Blocks: 155802
I would say I do sometimes see unescaped < > symbols in 'pre' elements, because
they're part of the markup.  Such as:

<pre>  This is   an   example   of <b>correct</b>   whitespace      handling
  for 'pre'          elements.
</pre>

Is the suggestion to treat angle-bracket-contained text as markup if it's known
to be valid markup, and show the angle brackets as if they'd been escaped if a
<blahblah> sequence isn't recognized as a valid element tag?  How would that
work when authors start arbitrarily extending XHTML with their own elements, as
some authors are starting to figure out they can do?
Treating unrecognized tags differently is bad for forward-compatibility.

Comment 9

16 years ago
Created attachment 90509 [details]
Testcase [ I believe! ]
(Assignee)

Updated

16 years ago
Keywords: evang500
(Assignee)

Comment 10

16 years ago
back to parser
Component: US General → Parser
Product: Tech Evangelism → Browser
Version: unspecified → Trunk
Er, what's parser supposed to do about this? Apple needs to be fixing 
their archiving script to do escaping.
(Assignee)

Comment 12

16 years ago
Sorry it wasn't clear to me that this was evangelism since you had a
misunderstanding of whether markup could be contained in a pre or not.

cocoa-dev is run by: hhickman@apple.com, ramarren@apple.com,
listadmin@lists.apple.com

the list uses mailman version 2.0.13
Assignee: harishd → susiew
Component: Parser → US General
Product: Browser → Tech Evangelism
QA Contact: moied → zach
Summary: Repeated and lost content in a <pre> with lots of tags → apple.com - Repeated and lost content in a <pre> with lots of tags
Version: Trunk → unspecified

Comment 13

16 years ago
-->bclary
Assignee: susiew → bclary

Comment 14

16 years ago

*** This bug has been marked as a duplicate of 150588 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.