Closed Bug 843499 Opened 8 years ago Closed 8 years ago

html bookmark files don't use valid HTML

Categories

(Toolkit :: Places, defect)

19 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jmichae3, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331

Steps to reproduce:

exported an HTML bookmarks file


Actual results:

DT and DD elements do not have a close tag. it's been this way for years. doesn't mean it's right.


Expected results:

should have a close tag on DD and DT elements.
btw, they are not void/empty elements according to the w3c/whatwg HTML standards out there.

this could be an invalid bug, since I just noticed the <!DOCTYPE on the bookmarks file is NOT any W3C standard but a netscape standard.

what standard is that? don't know. there is no URL for a DTD I can investigate, nor is one embedded.

with no DTD it means it doesn't even conform to normal tag standards of "open+close or singleton/void/empty" elements. (?) can anyone confirm/deny this?

the way the document is now, it treats DD or DT like a void element with following text.

I think it's a bad idea hawking it as an HTML file. surprisingly,the browser allows you to view it.
it just treats the file as badly formatted HTML I guess.

because 
- it does not have the !DOCTYPE of an HTML file
- it does not use a standard DTD
- it does not follow HTML file format of any kind (though the file extension is .html)
and the pelements are not closed either.
the spacebar on my keyboard is tough.  I tried to say, the p elements are not closed either.
Closing tags seem to be optional in HTML.
Component: Untriaged → Places
OS: Windows XP → All
Product: Firefox → Toolkit
The bookmarks.html file is an historical html-like format defined by Netscape, thus we can't change it (and even if we could the resources would be better spent elsewhere). The fact it is named .html is just an incident.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Marco Bonardo [:mak] (Away Mar 1) from comment #5)
> be better spent elsewhere). The fact it is named .html is just an incident.

But the Export/Import menu items say HTML…
(In reply to Aleksej [:Aleksej] from comment #6)
> (In reply to Marco Bonardo [:mak] (Away Mar 1) from comment #5)
> > be better spent elsewhere). The fact it is named .html is just an incident.
> 
> But the Export/Import menu items say HTML…

That's what users expect, changing that would just be confusing at this point. and it's html backwards compatible, regardless. It's just not xhtml or html5.
Aleksej, http://www.whatwg.org/specs/web-apps/current-work/complete/syntax.html#void-elements
is probably what you are referring to.

I made a comment on the standard there due to its ambiguity. if you read it techically, neither the start nor end tag is required. so if you put in nothing, no way is left to identify the element. it's an improperly worded specification. it should say something like
"for a non-void, non-foreign element, either a start tag or an end tag or both is required."
OR
"for a non-void, non-foreign element, both a start tag and an end tag is required."

I finally noticed the top of the file and noticed it was not a standard HTML !DOCTYPE. so I guess the file extension is just a misnomer (probably shouldn't have been in the first place).

defacto industry standards error. so case is closed I guess. thanks for clarifying.
I guess the file format appeared before 2005.
(and is for exporting an importing, so needs compatibility)
stranhge thing about it is, it is not consistent in its use of elements. like HTML, some are void elements, some  are open+close elements. odd thing about the void elements is, some of them can have text after them as part of its definition, as if there was an assumed closing tag. 

this is what violates the HTML TR. the elements used are specified in the TR as not being void/empty elements, meaning they are supposed to have open+close elements.
strangely enough, the browser (quirks mode?) allows for the lack of closing tags and displays it anyway if you view with a browser.
You need to log in before you can comment on or make changes to this bug.