Jaki jest prawidłowy sposób dołączenia obrazu bez src?
234
Mam obraz, który później dynamicznie zapełniam src javascript, ale dla ułatwienia chcę, aby tag obrazu istniał przy ładowaniu strony, ale po prostu niczego nie wyświetlał. Wiem, że <img src='' />jest nieprawidłowa, więc jaki jest najlepszy sposób na to?
To stosunkowo stare pytanie, ale warto wziąć pod uwagę, że obraz bez src jest w zasadzie bez znaczenia i dlatego specyfikacja mówi, że obraz musi mieć src wskazujący na jakiś osadzony zasób. Jeśli zastanawiasz się nad poprawnością i / lub semantyką, znacznie lepiej jest ci to zrobić, pomijając obraz i dodając go po fakcie, ponieważ HTML nie pozwala na określenie obrazu zastępczego, który zostanie wypełniony danymi później.
Korzystając z leniwej wtyczki jQuery Miki Tuupola, używa znaczników „<img class =" lazy ”data-original =" img / example.jpg "width =" 640 "height =" 480 "> ', więc w pewnym sensie wskaż źródło, ale nie trzeba tego robić za pomocą atrybutu src.
Choć nie ma poprawny sposób pominąć źródło fotografowanego obrazu, tam są źródła, które nie spowoduje hitów serwerów. Niedawno miałem podobny problem ze iframes i zdecydowałem, //:0że to najlepsza opcja. Nie naprawdę!
Rozpoczęcie od //(pominięcie protokołu) powoduje użycie protokołu bieżącej strony, co zapobiega ostrzeżeniom o „niebezpiecznej zawartości” na stronach HTTPS. Pominięcie nazwy hosta nie jest konieczne, ale jest krótsze. Wreszcie port :0gwarantuje, że żądanie serwera nie może zostać wykonane (zgodnie ze specyfikacją nie jest poprawnym portem).
To jedyny adres URL, który znalazłem, nie spowodował żadnych trafień na serwer ani komunikatów o błędach w żadnej przeglądarce. Zwykły wybór - javascript:void(0)- spowoduje wyświetlenie ostrzeżenia o „niezabezpieczonej zawartości” w IE7, jeśli zostanie użyte na stronie obsługiwanej przez HTTPS. Każdy inny port spowodował próbę połączenia z serwerem, nawet w przypadku nieprawidłowych adresów. (Niektóre przeglądarki po prostu wysyłają nieprawidłowe żądania i czekają, aż upłynie limit czasu).
Zostało to przetestowane w Chrome, Safari 5, FF 3.6 i IE 6/7/8, ale spodziewam się, że będzie działać w dowolnej przeglądarce, ponieważ powinna to być warstwa sieciowa, która zabija każdą próbę żądania.
Ta odpowiedź może spowodować, że zapora sieciowa ostrzeże Cię na przykład o dostępie do portu 0. Lub może spowodować dziennik bezpieczeństwa serwera. Doradztwo w odpowiedzi about:blankjest prawdopodobnie lepszym rozwiązaniem.
To nie działa: Mam aplikację ASP.NET MVC 4, która zawiera wtyczkę galerii obrazów o nazwie czyszczenie. Wtyczka tworzy obrazy dynamicznie i umieszcza //: 0 o src, dopóki obraz nie zostanie faktycznie pobrany. To spowodowało, że akcja indeksu mojego kontrolera domowego została wywołana dwukrotnie. Więc uważaj.
Świetny pomysł! Dla mnie jednak to zabija element obrazu - jeśli ktoś potrzebuje innych aspektów tego imgelementu, aby pokazać np. Tło i obramowanie, spróbuj, src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="które są pobierane z przezroczystego gif 1 x 1 x x, zrobiłem I Photoshop przepchnięty przez base64-image.de
Drugi przykład wyświetla „Tekst alternatywny” (oraz ikonę zepsutego obrazu w Chrome i IE).
"data:,"jest prawidłowym identyfikatorem URI. Domyślny typ pustego nośnika to text/plain. Oznacza to pusty plik tekstowy i jest równoważny z"data:text/plain,"
OT: Wszystkie przeglądarki rozumieją jasno alt. Możesz pominąć ="", jest domyślny dla specyfikacji HTML.
również spójrz na prependi append. W przeciwnym razie, jeśli masz taki znacznik obrazu i chcesz go zweryfikować, możesz rozważyć użycie fikcyjnego obrazu, takiego jak przezroczysty gif 1 px lub png.
+1 To jest najlepsza odpowiedź. Jeśli źródło obrazu i tak jest ustawiane dynamicznie, cały element powinien być dodawany dynamicznie. Jeśli nie chcesz, aby był widoczny, dopóki nie zostanie ustawiony src, nie mogę wymyślić żadnego dobrego powodu, dla którego element powinien być tam wcześniej.
Nie robiłem tego od dłuższego czasu, ale raz musiałem przejść przez to samo.
<imgsrc="about:blank"alt=""/>
Jest moim ulubionym - ten //:0sugeruje, że spróbujesz nawiązać połączenie HTTP / HTTPS z serwerem źródłowym na porcie zero (port tcpmux?) - co jest prawdopodobnie nieszkodliwe, ale wolałbym tak nie robić. Heck, przeglądarka może zobaczyć port zero i nawet nie wysłać żądania. Ale nadal wolałbym, aby nie było tak określone, gdy prawdopodobnie nie to masz na myśli.
W każdym razie renderowanie about:blankjest bardzo szybkie we wszystkich testowanych przeglądarkach. Właśnie wrzuciłem go do walidatora W3C i nie narzekał, więc może nawet być ważny.
Edycja : Nie rób tego; nie działa we wszystkich przeglądarkach (pokaże ikonę „uszkodzony obraz”, jak wskazano w komentarzach do tej odpowiedzi). Skorzystaj z <img src='data:...poniższego rozwiązania. Lub jeśli nie zależy ci na ważności, ale nadal chcesz unikać zbędnych żądań do serwera, możesz to zrobić <img alt="" />bez atrybutu src. Ale to NIEPRAWIDŁOWY HTML, więc wybieraj to ostrożnie.
Strona testowa pokazująca całą masę różnych metod: http://desk.nu/blank_image.php - obsługiwana z różnego rodzaju różnymi typami dokumentów i typami treści. - jak wspomniano w komentarzach poniżej, skorzystaj z nowej strony testowej Marka Ormstona pod adresem : http://memso.com/Test/BlankImage.html
Jest gorzej niż myślałem - nawet w przypadku html5 doctype nie działa w przeglądarce Safari ani w Chrome. Mam stronę testową w górę, która zmieni typ strony i typ strony, a do tej pory moim ulubionym jest: <img />- tag graficzny bez atrybutu src. To nie jest poprawne (więc nie ma sensu umieszczanie tam pustego znacznika alt). Nadal gram z nim i odpowiednio zaktualizuję swoją odpowiedź (lub przekreślę ją).
Wziąłem twoją stronę testową i zaktualizowałem ją, więc jest o wiele bardziej oczywiste, gdy obrazy nie działają poprawnie. Stary pusty obraz jest dołączony jako przykład „Zawsze działa”, a także krótki opis tego, co widzisz: memso.com/Test/BlankImage.html To mi uświadomiło, że prawidłowy gif z pustymi danymi jest jedynym narzędziem wielokrotnego użytku opcja dla współczesnych przeglądarek, innych niż stary pusty obraz gif (który jest nadal wymagany dla starego IE7 i niższych)
jeśli utrzymasz pusty atrybut src, przeglądarka wyśle żądanie do bieżącego adresu URL strony zawsze dodawaj 1 * 1 przezroczysty obraz w atrybucie src, jeśli nie chcesz żadnego adresu URL
Chcesz wyjaśnić opinię? Zauważ, że nie polecam korzystania z tej metody, tylko jako argument do dyskusji. Spełnia wymagania zawarte w pytaniu, aby poprawnie zweryfikować i nie składać dodatkowych wniosków.
Będzie miał domyślny rozmiar do 300 x 150 pikseli, jak każdy inny plik SVG, ale możesz pracować z tym w imgdomyślnych stylach elementu, tak jak byś potrzebował w każdym przypadku w praktycznej implementacji.
Dziękujemy za aktualizację odpowiedzi, ale podejrzewam, że kompatybilność jest jeszcze gorsza niż w przypadku innych rozwiązań URI, biorąc pod uwagę, że używasz svg, który był niezgodny do IE9. Na szczęście minęło trochę czasu, odkąd musiałem wspierać starszą IE, ale nadal jest to istotne dla niektórych osób.
Ale czy to nie dotyczy tych samych problemów, co w tym artykule? dev.mobify.com/blog/data-uris-are-slow-on-mobile . Myślę, że najlepsza jest opcja <img src = "about: blank"> z css img [src = "about: blank"] {nieprzezroczystość: 0}. Lub, jeśli ten poziom selektora CSS nie jest obsługiwany w starszych przeglądarkach, po prostu nadaj tagowi img klasę „ładowanie” lub coś w tym rodzaju. Jeszcze lepiej, podaj jej klasę, użyj JavaScript, aby zamienić dane src, a następnie ustaw funkcję ładowania obrazu, aby zmieniła się przy ładowaniu. Możesz także ustawić pokrętło, które będzie wyświetlane podczas ładowania. Wygląda naprawdę profesjonalnie.
@JordanCarter Pewnie, jeśli szczegółowa wydajność stanowi problem. Na marginesie, powiedziałbym, że visibility: hiddenjest trochę bardziej odpowiedni niż opacity: 0dla selektorów atrybutów, które sugerujesz.
@mystrdat: Chcesz wyjaśnić, dlaczego jest brudny? Zaakceptowana odpowiedź przy użyciu „//: 0” wciąż dawała mi ikonę zepsutego obrazu oraz dziwne, niekończące się żądanie w Firefoksie. Jednopikselowa alternatywa base64 png, także z dużą ilością głosów, sprawiła mi kłopotów przy użyciu <img> jako symbolu zastępczego, zarówno z określeniem wysokości, jak i szerokości. Jest to najczystszy sposób, w jaki udało mi się osiągnąć mój cel bez zbędnych próśb i bez przechodzenia przez wszystkie kłaczki i walidacje.
@funkylaundry Przepraszam za zgłaszanie wielkich roszczeń i znikanie, opublikowałem teraz swoją odpowiedź. Przyznaję też, że wcześniej nie zauważyłem innych rozwiązań Data URI, z którymi się zgadzam, ale sądzę, że moje i tak jest lepsze pod względem składni.
Gdzie invis.gif jest jednopikselowym przezroczystym gifem. Nie złamie się to w przyszłych wersjach przeglądarek i działa w starszych przeglądarkach od lat 90.
png też powinien działać, ale w moich testach gif miał 43 bajty, a png 167 bajtów, więc gif wygrał.
ps nie zapomnij o znaczniku alt, podobnie jak walidatory.
Używamy plików cookie i innych technologii śledzenia w celu poprawy komfortu przeglądania naszej witryny, aby wyświetlać spersonalizowane treści i ukierunkowane reklamy, analizować ruch w naszej witrynie, i zrozumieć, skąd pochodzą nasi goście.
Kontynuując, wyrażasz zgodę na korzystanie z plików cookie i innych technologii śledzenia oraz potwierdzasz, że masz co najmniej 16 lat lub zgodę rodzica lub opiekuna.