2010-02-13 8 views
7

Co to jest użyteczność, dostępność, czytnik ekranu lub jakakolwiek inna kwestia związana z programowaniem, funkcjonalnością lub przeglądarką internetową pod numerem ?Co to jest użyteczność, dostępność, czytnik ekranu lub jakikolwiek inny program, funkcjonalność, problem z przeglądarką internetową w iframe?

Czy istnieje alternatywa dla ?

Czy są jakieś techniki JavaScript/jQuery lub po stronie serwera, które mogą zmniejszyć problemy z użytecznością, dostępnością lub czytnikiem ekranu z ?

Dlaczego W3C nie jest dołączony w języku XHTML Strict, a HTML 5 obsługuje ?

zmiana:

znalazłem kilka dobrych myśli tutaj także:http://uxexchange.com/questions/1817/iframe-accessibility-and-usability-issues

+1

Prawdopodobnie oznacza zmniejszenie * problemów *. –

+0

Co masz na myśli przez "alternatywę dla iframe". To zależy od tego, co próbujesz osiągnąć. Jeśli zależy to na odrysowaniu dynamicznej zawartości i zachowaniu statycznej zawartości (np. Nawigacji itp.), Istnieje wiele alternatyw po stronie serwera ... – anthares

+0

@anthares - mam na myśli ładowanie treści z innej domeny do naszej witryny. możesz zobaczyć przykładowy link i powiedzieć, czy możemy użyć dowolnej alternatywnej strony serwera, aby pokazać narzędzie do wykresów –

Odpowiedz

6

Dostępność:

  • Trudniej przewijać cię iframe, myszka musi być int zakresie iframe . Jest to trudne dla osób o skłonnościach do poruszania się.
  • Przeglądarki dla osób niewidomych mogą nie zawierać treści z twojego elementu iframe, a te osoby do niego nie dotrą.

Użyteczność:

  • To nie jest fajne, gdy masz kilka pasków przewijania w oknie głównym i na iframe. Trudno przewijania

Inne kwestie:

  • Mobilna przeglądarka prawdopodobnie nie uczyni cię iframe. Nawet jeśli to uczyni, będzie wyglądać źle i brzydko.
  • Wyszukiwarki będą miały problemy z indeksowaniem stron w elemencie iframe. Prawdopodobnie będą to pominąć lub nie podejmie indeksowane prawidłowo
  • Ładowanie iframe zajmie więcej czasu niż strony o tej samej treści i bez ramki
+0

pasek przewijania? zobacz tę stronę http://is.gd/8joWF Główna tabela jest w ramce iframe, ale nie ma paska przewijania. –

+0

Pasek przewijania pojawia się tylko wtedy, gdy zawartość strony o dużej skali jest większa niż wysokość iframe. –

+0

tylko dlatego, że zawartość nie jest wystarczająco długa, lub na ekranie i oknie przeglądarki - wystarczająco duża. – anthares

0

Jeśli masz jeden iframe, nie byłoby trochę problem . Jednak wiele elementów iframe stanowi problem. Punkt skupienia nie jest wyraźnie dostępny, a czytniki ekranu nie są wystarczająco inteligentne, aby znaleźć korelację wizualną (ten sam powód, dla którego tabele są złe dla projektu). ARIA to próba rozwiązania niektórych podobnych problemów. YUI plugin link zawiera więcej informacji.

Jednak iframe znajdują swoje miejsce w designie. W jednym projekcie, w którym pracowałem wcześniej, strona zawierała dwa elementy iframe (jeden z nich był ukryty), a ukryta ramka służyła do pobierania apletu uwierzytelniania.Nie dodawać żadnych nieszczęść dostępu jako punkt uwagi jest ograniczona do jednego iframe, który łączy się z seemlessly stronie

+0

Czy obłudna opieka wyborców wytłumaczy powód? – questzen

4

Dlaczego W3C nieuwzględnione w XHTML Strict iframe

Ponieważ w chwili był postrzegany jako bękartowe dziecko z szeroko pojętego tagu <frame>. Zasadniczo ma wiele takich samych właściwości, jak <frame>, ale w praktyce wydaje się, że zachęciło to do bardziej gustownego użytkowania, ogólnie unikając najgorszych problemów nawigacyjnych i związanych z użytecznością, z jakimi ucierpiały interfejsy ramek.

Podczas gdy HTML 5 obsługuje elementy iframe?

(a). Ponieważ, w przeciwieństwie do <frame>, , okazało się, że ma to zasadnicze znaczenie dla dokumentów mieszanych, takich jak te, w tym reklamy i wiele rodzajów aplikacji internetowych. Nadal występują problemy, o czym wspominano w innych odpowiedziach, ale ogólnie rzecz biorąc, jest postrzegany jako niezbędna funkcja, która ma pozostać. To nie jest prawda o <frame>, która jest "niezgodną funkcją" w HTML5 (najbliższy HTML5 dostaje się do dowolnego "ścisłego").

(b). ponieważ autorzy HTML5 nie dbają tak bardzo o zachęcanie do dobrych praktyk; chodzi o dokumentowanie tego, co muszą robić użytkownicy. W standardzie zostały odrzucone wszelkie przestarzałe cechy HTML4, a także wiele innych tradycyjnych, ale nietypowych zachowań przeglądarki, w tym każde ostatnie dziwne parsowanie zerwanych tagów. [na marginesie: Jestem bardzo rozbawiony widząc, że najnowszy argument, który jest dyskutowany na ich liście, dotyczy sposobu obsługi elementu <isindex> - elementu, którego dosłownie nikt nie użył, ponieważ elementy formularza HTML 2.0 uczyniły go przestarzałym w 1995 roku.]

Biorąc pod uwagę oszałamiającą wielkość i złożoność HTML5, nie jest zaskakujące, że nie chcieli dodatkowego wysiłku deklarowania bardziej ograniczonego profilu "trybu ścisłego". Ponieważ prace dobiegają końca, bardzo chciałbym zobaczyć XHTML5 Strict lub podobny wysiłek, aby odciąć część tego bałaganu. W obecnej formie Hixie i jego koleżanki zrobili migawkę z każdym paskudnym hackem, który przeglądarka musi obecnie wprowadzić w celu zapewnienia zgodności, i uczyniła go standardowym wymogiem dla wszystkich przeglądarek w dającej się przewidzieć przyszłości, skutecznie potępiając złą praktykę.

Powiązane problemy