Sì, questo è un bug. Puoi trovare il biglietto Bugzilla here.
David Baron sottolinea la cause, che indica nel codice stesso che ciò sia dovuto ad una limitazione nota:
La causa è il codice in nsLineLayout :: ReflowFrame:
if (psd->mNoWrap) {
// If we place floats after inline content where there's
// no break opportunity, we don't know how much additional
// width is required for the non-breaking content after the float,
// so we can't know whether the float plus that content will fit
// on the line. So for now, don't place floats after inline
// content where there's no break opportunity. This is incorrect
// but hopefully rare. Fixing it will require significant
// restructuring of line layout.
// We might as well allow zero-width floats to be placed, though.
availableWidth = 0;
}
Mi chiedo se la cosa giusta da fare sia:
- non manipolare la larghezza disponibile o
- rendono la larghezza disponibile infinito, poiché il contenuto nowrap è mai andare a avvolgere il galleggiante comunque
(In teoria, la soluzione corretta non è quella di provare a mettere il galleggiante fino alla successiva occasione pausa. Mi chiedo se altri browser lo facciano.)
In realtà penso che sia abbastanza fattibile; abbiamo già rinviato il layout dei float in mBelowCurrentLineFloats; dobbiamo solo fare qualcosa di simile e notificare il layout della linea alle opportunità di interruzione. È tutt'altro che banale, però. (Abbiamo anche bisogno di mettere il galleggiante immediatamente se siamo attualmente a un'opportunità di interruzione ... credo.)
anch'io chiedo se questo è ciò che fanno gli altri browser (Chrome e IE si comportano allo stesso, ponendo il float sulla stessa riga del blocco inline). Sfortunatamente non comprendo pienamente l'interazione tra i float e line breaks, quindi non posso commentare ulteriormente.
Cos'è Chromium? – Dan
Chrome per Linux –
Oh ...beh, "cade" anche in Chrome, ma non penso che sia un bug. – Dan