Afbeeldingen en HTML5

Question

Afbeeldingen en HTML5

Deze vraag is filosofischer dan technisch.

Ik heb mezelf opgeleid als een webontwikkelaar toen webontwikkelaars webmasters werden genoemd en mijn favoriete apparaat was FrontPage, evendsoft eerste pagina 2000.

Dat was de laatste keer dat ik een HTML-afbeeldingkaart gebruikte.

Nu is het HTML5, AJAX, vectorillustraties, CSS 3D, jQuery, lokale opslag, touchscreen Safari, noem maar op. De imagemap is vervaagd tot een obscuriteit waar zelfs Google niet te veel relevante resultaten te zien geeft; een verplichte W3C Schools entry en enkele forumberichten uit 2004.

Uiteraard was het creëren van een website-navigatie of vergelijkbare trivialiteit met behulp van een imagemap een slecht idee toen en het is vandaag zeker niet onvergeeflijk.

Maar nu heb ik een taak om een polygoon klikbaar gebied boven op een div te maken met een achtergrondafbeelding.

Ik zou er geen probleem mee hebben om dit in de imagemap te doen, omdat het lijkt alsof het zo ontworpen is voor een use-case, en hoewel ik geen tests heb gedaan, kon ik me niet voorstellen dat een browser ondersteuning zou laten vallen voor een element dat prachtig werkte voor jaren. Maar ik kan niet anders dan denken dat er vandaag een betere manier moet zijn om dit te doen.

My web creation philosophy is to develop for IE5.5, and then design for Chrome edge. This means that the site first needs to work on a basic level on even the most antiquated browser, and then start adding JS & CSS to make it more beautiful, more usable, faster, simpler, friendlier and better.

Hoewel ik weet dat ik in Raphaël een canvas kan maken en allerlei hippe hover-effecten en dergelijke kan toevoegen, denk ik dat voor het maken van een eenvoudige functionaliteit geen 89 kb (of X kb) JS-bibliotheek nodig is. Of zelfs JS helemaal.

Ik weet niet of CSS3 over mogelijkheden beschikt om polygonale gebieden te definiëren, maar hoewel ik de grote mogelijkheden van CSS3 onderken, geef ik er de voorkeur aan alles wat daar wordt gedefinieerd te houden als een niet-essentiële flair die gracieus zou verslechteren.

Dus in de webdev-wereld van vandaag, wat is de meest cross-browsermanier om een veelhoekig klikgebied te definiëren (bij voorkeur op een manier die kan worden overgenomen door een jQuery .hover() , of ten minste een CSS <-code >: hover ), die niet afhankelijk is van JavaScript- of CSS-kenmerken die beschikbaar zijn in een minderheid van browsers? Is beeldkaart echt de enige manier om het te doen? Hoe zit het met mobiele apparaten?

7

toegevoegd 23 juni 2012 op 05:43 de auteur Emphram Stavanger

Bekeken: 2

de bron

ja ru fr es de ar

Er is geen verantwoording voor filosofie - maar ontwerpen voor een kleinste gemene deler van no JavaScript beperkt je architectuur tot een ongelooflijk primitief model. Geen ajax. Alle gegevens ingediend via HTTP-berichten? Geen validatie van clientlogica/logica/interactiviteit? Ouch. Tenzij u wilt dat al uw gebruikers een webervaring in het jaren 90 hebben, heeft u het eigenlijk over het ontwerpen van twee compleet verschillende implementaties van een website. U kunt een ajax client/server-model niet "geleidelijk degraderen"; u zou twee versies van de site maken. Het is gewoon veel te veel extra werk zonder resultaat. Wie gebruikt lynx?

toegevoegd 23 juni 2012 op 09:47, de auteur Jamie Treworgy, de bron

"kan JS echt een vereiste zijn voor een functionaliteit die even belangrijk is als formulierinzending" Waarom kan dat niet? Ik vraag opnieuw: wie gebruikt lynx? In welk jaar beslist u dat een basislijn van technologie die is ontworpen na 1991 vereist is? 2015? 2020? Beperk je jezelf tot de eerste HTML-spec? Waarom beperk je je dan tot andere aspecten van de technologie uit die tijd?

toegevoegd 26 juni 2012 op 11:56, de auteur Jamie Treworgy, de bron

.. wat ik heb tegen het indienen van formulieren op de ouderwetse manier is dat het achteraf een complete schermvernieuwing vereist, enorme hoeveelheden bandbreedte verspilt en een langzame, niet-reagerende gebruikerservaring creëert. Het is dag en nacht. Het veranderde het web. Dus als ik een website wil ontwerpen die modern is en werkt zonder JavaScript, moet ik twee totaal verschillende versies van dezelfde site maken. Ik heb nog nooit iemand gevonden die bereid is te betalen om alles tweemaal te doen, zodat ze iemand kunnen ondersteunen die misschien niet eens bestaat. Het is ook heel, heel moeilijk om complexe/meervoudige vormen op de oude manier te ontwerpen.

toegevoegd 26 juni 2012 op 12:07, de auteur Jamie Treworgy, de bron

Het is niet dat ik gebruikers van IE5.5 target, en ik ben ook niet van plan mijn websites er mooi uit te laten zien. Ik heb niet eens een exemplaar van IE5.5 om te kijken hoe mijn websites eruit zien. Ik gebruik deze instelling echter bij het bouwen, zodat ik kan garanderen dat mijn websites werken aan zelfs de meest primitieve browser, ongeacht de leeftijd (Lynx, Kindle, browsers van het WAP/Nokia Navigator-tijdperk, schermlezers, enz.). Het helpt de inhoud en structuur als één te behouden en snazz en flair als een andere.

toegevoegd 23 juni 2012 op 08:02, de auteur Emphram Stavanger, de bron

Zoals ik al zei, IE5.5 is niet mijn doelwit en ik test er niet voor, maar het is waar ik de ruggengraat van de site voor bouw totdat ik begin erover na te denken om het mooi te maken en JS-flair eraan toe te voegen. Inzenden via AJAX is prachtig, maar kan JS echt een vereiste zijn voor een functionaliteit als kern als formulierinzending? Net als in uw browser en apparaat moet JS compatibel en ingeschakeld zijn, of werkt elk formulier op mijn site helemaal niet? En zeker betekent JS-validatie niet dat server-side validatie (een andere IE5.5-achtige benadering) kan worden genegeerd.

toegevoegd 24 juni 2012 op 07:44, de auteur Emphram Stavanger, de bron

Ik zeg natuurlijk niet dat gebruikers met JS ingeschakeld en gebruikers met JS uitgeschakeld exact dezelfde gebruikerservaring moeten hebben. Of zelfs dichtbij. Ik bedoel alleen maar, voor mij lijkt het een heel dwaze houding om je formulieren niet op de normale, ouderwetse manier voor te leggen. Voeg in elk geval de AJAX-inzending toe om de gebruikerservaring te verbeteren (dat doe ik). Maar er is gewoon geen waarneembare reden voor mijn ogen waarom ik specifiek de formulieren niet-overdraagbaar via HTTP ten gunste van AJAX zou moeten maken.

toegevoegd 24 juni 2012 op 07:52, de auteur Emphram Stavanger, de bron

... beginnend met IE5.5 is behoorlijk gek. Je doet echt jezelf pijn. Ik heb een redelijk drukke site (ongeveer 0,5 miljoen bezoekers per maand) en in de afgelopen 3 jaar heb ik geen enkel bezoek gehad met iets lager dan IE6. In het afgelopen jaar heeft IE6 ongeveer 2% van mijn gebruikersbestand goedgemaakt.

toegevoegd 23 juni 2012 op 06:10, de auteur Loktar, de bron

1 antwoord

de auteur Jamie Treworgy · Answer 1 · 2012-06-23T06:06Z

Waarom is het gebruik van afbeeldingskaarten voor navigatie onvergeeflijk? Het is een hulpmiddel als elk ander; het heeft een tijd en plaats. Het gebruik van imagemaps met JavaScript-verbeteringen is achterwaarts compatibel, degradeert elegant en heeft 100% browserondersteuning. Ze hebben geen plug-in nodig zoals flash. Ze zijn praktisch ondersteund sinds de dageraad van de webbrowser. Alleen maar omdat iets oud is, betekent nog niet dat het niet nuttig is; integendeel, het betekent dat het goed wordt ondersteund.

Ik heb een jQuery-plug-in genaamd ImageMapster geschreven om effecten toe te voegen aan imagemaps, zodat je interactieve afbeeldingen kunt maken zonder flitser te gebruiken. Het zou gemakkelijk zijn om een tool te implementeren die dezelfde functionaliteit had zonder Javascript-ondersteuning door te vervangen door een lijst in die gevallen. Persoonlijk denk ik dat proberen om voor het web te schrijven zonder javascript, net zoiets is als proberen een auto te rijden zonder banden. 99% van het internet werkt niet meer zonder meer. Dit is geen 1995. Maar als je je echt zorgen maakt, is het leuke aan imagemaps dat de basisnavigatiefunctionaliteit nog steeds werkt. Er is geen manier om dat alleen met CSS te bereiken - zelfs CSS3 niet als je onregelmatig gevormde gebieden hebt.