The default bug view has changed. See this FAQ.

HTML5-style block-level links break when the link contains new HTML5 elements

RESOLVED FIXED in mozilla1.9.3a5

Status

()

Core
HTML: Parser
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Oli Studholme, Unassigned)

Tracking

({html5})

unspecified
mozilla1.9.3a5
x86
Mac OS X
html5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by the HTML5 parser], URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

In HTML5 <code>&lt;a&gt;</code> is now able to wrap block level elements. This works as expected for HTML4 elements (<code>&lt;div&gt;</code> etc). However when <code>&lt;a&gt;</code> wraps a new HTML5 element, Firefox closes the HTML5 element and link when it encounters a contained block-level element, then wraps the next element’s content in a link, then following block-level elements in a single block-level link.

Reproducible: Always

Steps to Reproduce:
1.Wrap an HTML5 element in a link
2.Observe DOM breakage with Firebug

Actual Results:  
Firefox closes the HTML5 element and link when it encounters a contained block-level element, then wraps the next element’s content in a link, then following block-level elements in an a single block-level link.

Expected Results:  
* Expected the HTML5 element containing other elements to contain them.
* Expected the block level link to contain all contained elements.

is in the test case
(Reporter)

Comment 1

8 years ago
One more time:

Description:
In HTML5 <a> is now able to wrap block level elements. This
works as expected for HTML4 elements (<div> etc). However
when <a> wraps a new HTML5 element, Firefox closes the HTML5
element and link when it encounters a contained block-level element, then wraps
the next element’s content in a link, then following block-level elements in a
single block-level link.

Further information is in the test case:
http://oli-studio.com/bugs/mozilla/block-level-links.html
(Reporter)

Updated

8 years ago
Keywords: html5
Version: unspecified → 3.5 Branch
(Reporter)

Comment 2

8 years ago
Also note that the UA default a {text-decoration: underline;} link style is not picked up by contained block-level elements.
(Reporter)

Comment 3

8 years ago
I found a workaround—using a wrapper <div> inside the block-level link seems to stop the problem. Here’s a blog post about it:
http://boblet.tumblr.com/post/178852468/block-level-links

Comment 4

8 years ago
The above workaround (comment 3) posted by Oli Studholme did not work for me.  I was using <h3> tag inside a block wrapped with an <a>.  To workaround I used a <span> instead of an <h3> and used CSS to format the span to look like the <h3>.
(Reporter)

Comment 5

8 years ago
While I initially thought I’d fixed the problem, it would still occur rarely to one of the four block links I initially made, even with a div wrapper (the this-should-be-an-IE-bug packet boundary thing?). I worked around it by styling the broken layout using advanced selectors to (mostly) replicate the intended layout.

I’ve also heard of Paul’s suggested workaround of wrapping things in spans, but that removes the point for me (although it does have the benefit of actually working :| ).

The more I try using block-level links in FF, the more I experience this ‘links self-closing’ bug. This also includes wrapping HTML4 elements like dl. Unfortunately I haven’t had time to look for a solution/make more reductions.

Comment 6

7 years ago
The same problems and workarounds in Linux Opensuse 11.2 - using html5 tags, only in FF ---3.6 | not in other browsers like Opera, Chrome.
Nobody working for a fix?

Comment 7

7 years ago
Does this work with the HTML5 parser? See http://hsivonen.iki.fi/test-html5-parsing/ for more info. I think it does, but maybe I'm not reading carefully this late at night..

(BTW sorry for the slow replies -- it's better to file technical bugs in the relevant Core component <https://bugzilla.mozilla.org/enter_bug.cgi?product=Core> or even in Core:General you'd have more chances of a quick reply.)
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Version: 3.5 Branch → unspecified

Comment 8

7 years ago
You don't even need a nightly build. It does indeed parse correctly if you go into about:config in Firefox 3.6 and turn on html5.enable. I'll attach an HTML file that lets you test this quickly, by having or losing the styling on the header block of the file. If you have DOMInspector, looking at the DOM with html5.enable set to false is pretty trippy.

Comment 9

7 years ago
Created attachment 440113 [details]
Test HTML file to show parsing errors with anchor blocks from HTML5
(Reporter)

Comment 10

7 years ago
@Nickolay, @Bruce — the HTML5 parser does indeed work as expected. However as Bruce notes the HTML5 parser is not the default. Until it is this bug is still … well, a bug.

@Nickolay — noted. however please realise that expecting bug submitters to be familiar with internal terminology is a recipe for disappointment ;-)

Additional packet boundary bug for reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=414418
Depends on: 373864

Comment 11

7 years ago
@Oli - Agreed this is still a bug, and a really annoying one. I'm starting a project to get a Javascript library together to provide HTML5 compatibility across browsers (http://modernbrowsers.sourceforge.net/) so that we can convince authors to start using HTML5 now, and how I am going to handle repairing this dogs breakfast from Javascript is utterly beyond me right now.

Comment 12

7 years ago
> @Nickolay — noted. however please realise that expecting bug submitters to be
> familiar with internal terminology is a recipe for disappointment ;-)
I understand that, but there's little I can do about bug handling process, so the least I can do is explain the situation to the individual bug reporters, who file useful bugs...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]

Comment 13

7 years ago
As has been alluded to in previous comments, this doesn't even need HTML5 elements within the block-level anchor to cause the bug. I've got an anchor wrapping a pair of divs, and it's still happening.

If the HTML5 parser were the default, this would indeed be resolved and fixed. Sadly though it is not, so it isn't.
(In reply to comment #13)
> If the HTML5 parser were the default, this would indeed be resolved and fixed.
> Sadly though it is not, so it isn't.

The HTML5 parser is on by default on trunk. Are you sure you haven't turned the HTML5 parser off in your profile?

Comment 15

7 years ago
I fixed temporarly this problem with JavaScript on the website http://www.tsr.ch/

Look at this : http://www.tsr.ch/js/libs/ffRebuild.js (it's based on jQuery). You can see the fixed links on the Firebug's console.

If it can help someone... Juste take it and share it!

Note that it works all around our website, but it might bug with another way to write your HTML code.

Comment 16

6 years ago
I still have this issue in FF 3.6.13 on OS X 10.5.8 PPC.

Comment 17

6 years ago
Hugh: the fix is in Firefox 4 and not in 3.6.x.
Target Milestone: --- → mozilla1.9.3a5

Comment 18

6 years ago
I've found that wrapping the elements with a span is less likely to break than a div. This is invalid markup however.
You need to log in before you can comment on or make changes to this bug.