2012-04-09 14 views
9

In passato ho risposto a una domanda su "chi ha sbagliato" riguardo alle immagini SVG non "ritagliate" (overflow: hidden) in IE9, dove tutti gli altri browser di supporto lo hanno fatto. La risposta è here.I contenuti SVG dovrebbero essere visibili all'esterno di uno <svg> integrato?

Oggi, mentre la revisione di nuovo HTML5 Boilerplate, ho notato che essi affermano di "[correct] overflow not being hidden in IE9" con questo pezzo di codice:

svg:not(:root) { overflow: hidden; } 

che sto cercando qualcuno per confermare o negare la mia ricerca originale puntando a qualche altro nota nelle specifiche HTML5 o SVG. Non riesco a trovare nulla, ma voglio essere sicuro che non mi manchi qualcosa.

Il meglio che posso trovare è che stanno cercando di applicare la regola 7 here, ma che dovrebbe applicarsi solo a un documento SVG, come tramite un tag img o quando caricato direttamente.

+0

Grazie per la modifica del titolo @Phrogz. Stavo avendo qualche problema su come riassumere esattamente la domanda. –

+0

@casperOne In che modo chiedere chiarimenti su una specifica non è una domanda reale? Riesco a vedere che la dicitura è scarsa, ma non vedo come si adatti alla categoria che hai etichettato. È troppo localizzato? –

+0

Vuoi che qualcuno chiarisca se qualcuno ha ragione o torto. Potrei riaprirlo, ma poi lo chiuderei di nuovo come "Non costruttivo". – casperOne

risposta

4

La specifica SVG ha questo da dire: http://www.w3.org/TR/SVG/styling.html#UAStyleSheet

sembra simile a quello di Firefox e Chrome non fanno?

+0

Bello, anche se (secondo la mia risposta) sia Chrome che FF usano la stessa versione leggermente modificata. (Forse c'è un errata intorno a questo?) Questo implica quindi che IE ha sbagliato a non avere questo foglio UA. Tuttavia, non chiarisce completamente per quale motivo "overflow: visible" non fa apparire il percorso di overflow in Chrome/FF. È forse una domanda a parte, ma quali sono le aspettative sui "limiti" dell'SVG da rendere? Quando i limiti supererebbero mai l'altezza e la larghezza? – Phrogz

+0

[questa discussione] (http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0344.html) è pertinente. – Phrogz

+0

Grazie per averlo indicato. Sembra che forse un conflitto nel foglio di stile richiesto predefinito per gli elementi dello spazio dei nomi SVG sia in conflitto con la regola 7 sopra + http://www.w3.org/TR/SVG/styling.html#Scope? –

4

La risposta originale mi sembra corretta, utilizzando i motivi specificati (in particolare il quinto e il settimo punto elenco di the spec).

Sembra incredibilmente improbabile che IE sia corretto e Webkit e Firefox no. Tuttavia, come sospetti, il settimo punto elenco è il fattore di differenziazione.

Se si carica this test case in Chrome e utilizzare gli strumenti per sviluppatori di ispezionare il formato SVG, si vedrà:

(user agent stylesheet)

svg:not(:root), symbol, image, marker, pattern, foreignObject { 
    overflow: hidden; 
} 

Se si attiva "Mostra User Agent CSS "in Firebug vedi questa regola in Firefox:

svg.css (line 49) <System>

svg:not(:root), symbol, image, marker, pattern, foreignObject { 
    overflow: hidden; 
} 

Infine, se si modifica il banco di prova per aggiungere svg { overflow:hidden } poi IE corrisponde visivamente gli altri browser.

Quindi, mi sembra che tutti e tre i browser si comportino secondo le specifiche, ma Chrome/Safari/FF hanno tutte le regole UA che corrispondono più strettamente a ciò che la maggior parte degli utenti si aspetterebbe.

Se potessi partire abbastanza bene da solo, questo è il punto in cui interrompo questa risposta.

Tuttavia, se si edit the test case to add svg { overflow:visible }, sia Chrome che Firefox non mostrano "correttamente" il contenuto in overflow. Non sono sicuro di come risolvere questo punto dati con il resto di questa risposta. :/

+1

Parere (non risposta): senza il comportamento di Chrome e Firefox, c'è l'implicazione che ' 'Dovrebbe trovare il riquadro di delimitazione dell'intero contenuto e rendere il contenuto completo di SVG a 4px per unità mondo. Questo è così contrario a quello che vorrei da un SVG. Penso che ci debba essere una specifica che definisca le estensioni dei contenuti SVG da rendere. E sospetto che IE9 abbia mancato o interpretato erroneamente questa specifica (che non riesco a trovare). – Phrogz

+0

Grazie per la risposta dettagliata. (Anche opinione) Sono d'accordo sul fatto che la maggior parte delle persone, specialmente quelle più familiari con le immagini binarie e i tag immagine, non si aspetterebbe che l'immagine SVG si sovraccarichi di default. @ Il link di Robert sopra riportato porta un interessante conflitto nella sentenza alla luce quando si confronta l'UA predefinito che ** deve essere ** implementato rispetto alla regola 7 (documento SVG di parole chiave) + http://www.w3.org/TR/SVG/styling .html # Scope –

+0

Dopo aver messo tutto insieme con il tuo link di discussione e il link del foglio di stile UA sopra vedo dove IE9 è in errore. La regola 7 si applica, non come una regola separata, ma in combinazione con tutte le regole in "overflow" come avvertenza agli UA che lo stile predefinito per le finestre è "overflow: hidden". –

Problemi correlati