SVG browser detectie

[Verwijderd]

Beste mensen,

Ik maak voor een zoekmachine gebruik van het volgende php-script:

[code=php]
$datafile = "http://www.domein.nl/database.txt";

require("../scripts/zoek.php");

$selectie[0] = "Achternaam: ";
$selectie[1] = "Voornaam: ";
$selectie[2] = "Straat: ";
$selectie[3] = "Huisnummer: ";
$selectie[4] = "Postcode: ";
$selectie[5] = "Gemeente: ";
$selectie[6] = "Plattegrond: ";
[/code=php]

Werkt allemaal prima, maar... Het laatste veld verwijst naar een SVG-bestand en niet alle browsers ondersteunen dat. Ik wil dus graag dat het laatste veld alléén zichtbaar is in moderne browsers, (al dan niet mobiele) browsers dus die het SVG-formaat ondersteunen.

Ik weet hoe ik dat in JavaScript moet oplossen, namelijk met iets als:

[code=javascript]
if(document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1") )
{
document.write("SVG enabled");
}
else
{
document.write("SVG unabled");
}
[/code=javascript]

Maar hoe doe ik dat zo compact (en netjes) mogelijk in het bovenstaande php-script? Ik heb namelijk nauwelijks verstand van php. Iemand?

Hartelijk bedankt!
Shelley

[Ramon]

Voor feature detection zou ik gebruik maken van modernizr http://modernizr.com/. Hiermee kan je svg en nog veel meer detecteren.

Wat ik verder uit je verhaal niet helemaal snap is waarom je de detection wil verplaatsen naar je PHP script? Je PHP script genereert html, en in de client (javascript) bepaal je vervolgens wat je wel of niet wil tonen adhv bijv. modernizr, toch?

[Merethil]

Verwijderd schreef op zaterdag 15 juni 2013 @ 11:08:
Beste mensen,

Ik maak voor een zoekmachine gebruik van het volgende php-script:

[(code)]

Hartelijk bedankt!
Shelley

Je zou het toch standaard uit kunnen zetten en alleen aanzetten wanneer je via JS erachter bent gekomen dat het geimplementeerd is? Op die manier word de mogelijkheid alleen getoond als JS actief is, de browser het ondersteunt en dus getoond mág worden.

[ Voor 51% gewijzigd door Merethil op 15-06-2013 13:58 ]

[NMe]

Nou hoef je niet per se Modernizr te gebruiken als je alleen maar wil checken of SVG mogelijk is. Daar voldoet bovenstaande code volgens mij ook prima voor en dan zit je niet met een complete ongebruikte library.

Overigens krijg ik dezelfde antwoorden die je hier krijgt als ik ga [google=php check svg support].

[ Voor 86% gewijzigd door NMe op 15-06-2013 13:59 ]

[R4gnax]

NMe schreef op zaterdag 15 juni 2013 @ 13:58:
Nou hoef je niet per se Modernizr te gebruiken als je alleen maar wil checken of SVG mogelijk is. Daar voldoet bovenstaande code volgens mij ook prima voor

Bovenstaande detectie code op basis van hasFeature heeft nog wel eens problemen gegeven i.v.m. het gebruikte versie nummer van de specificatie. Daarom detecteert o.a. Modernizr SVG ondersteuning op het kunnen aanmaken van een SVG root element en of dat één v/d meer basale APIs ondersteunt:

JavaScript:

function supportsSVG() {
  return !!document.createElementNS && !!document.createElementNS('http://www.w3.org/2000/svg', "svg").createSVGRect;
}

Als je je niet druk hoeft te maken over de iets oudere Webkit builds, dan zou de detectie gebaseerd op hasFeature wel goed werken. (Het is ook zeker wat je eigenlijk hoort te gebruiken; sommige browsers maken het alleen vleugellam.)

[Merethil]

R4gnax schreef op zaterdag 15 juni 2013 @ 14:10:
[...]


Bovenstaande detectie code op basis van hasFeature heeft nog wel eens problemen gegeven i.v.m. het gebruikte versie nummer van de specificatie. Daarom detecteert o.a. Modernizr SVG ondersteuning op het kunnen aanmaken van een SVG root element en of dat één v/d meer basale APIs ondersteunt:

JavaScript:

function supportsSVG() {
  return !!document.createElementNS && !!document.createElementNS('http://www.w3.org/2000/svg', "svg").createSVGRect;
}

Als je je niet druk hoeft te maken over de iets oudere Webkit builds, dan zou de detectie gebaseerd op hasFeature wel goed werken. (Het is ook zeker wat je eigenlijk hoort te gebruiken; sommige browsers maken het alleen vleugellam.)

Volgens mij is de Modernizr functie gewoon een incapsulering van de hasFeature() en doet 't hetzelfde met wat extra checks. Maar Modernizr voegt direct een hele zut aan extra functies toe die je dan weer hoogstwaarschijnlijk niet nodig gaat hebben.

In mijn ogen wegen de voordelen niet op tegen de nadelen die je dan hebt.

[Verwijderd]

Hallo,

Bedankt allemaal voor de antwoorden, maar zoals gezegd: ik heb een php-script nodig... Dit werkt in ieder geval niet:

[code=php]
if (stristr($_SERVER["HTTP_ACCEPT"], "image/svg+xml"))
{
echo 'TRUE';
}
else
{
echo 'FALSE';
}
[/code=php]

Maar ik weet dan ook weinig tot niets van php. Iemand een werkend alternatief?

Hartelijke groeten,
Shelley

[NMe]

Checken in javascript, postback doen via AJAX naar een PHP-script dat per IP bijhoudt of het SVG ondersteunt (evt. in combinatie met user agent), cookie setten en dan de pagina vernieuwen. En dan op de vernieuwde pagina eerst dat cookie checken zodat je weet dat je niet nogmaals dat request hoeft te doen.

[R4gnax]

Merethil schreef op zaterdag 15 juni 2013 @ 14:26:
[...]

Volgens mij is de Modernizr functie gewoon een incapsulering van de hasFeature() en doet 't hetzelfde met wat extra checks.

Volgens mij niet.

Merethil schreef op zaterdag 15 juni 2013 @ 14:26:
Maar Modernizr voegt direct een hele zut aan extra functies toe die je dan weer hoogstwaarschijnlijk niet nodig gaat hebben.

Je kunt heel eenvoudig zelf een uitgeklede build maken.

Merethil schreef op zaterdag 15 juni 2013 @ 14:26:
In mijn ogen wegen de voordelen niet op tegen de nadelen die je dan hebt.

Voordeel
Gestandardiseerde code waarvan je weet dat deze getest is onder alle browsers en naar behoren werkt.

Voordeel
Goed gedocumenteerde library met goede naamsbekendheid. De de-facto standaard, waarvan het gebruik ook bij andere web developers bekend zal zijn.

Voordeel
Goede code organisatie: één centraal, makkelijk terug te vinden opslagpunt voor alle feature detectie tests. Ook makkelijk uitbreidbaar met extra tests.

Voordeel
Integratie met class names op het <html> element, zodat je direct op SVG beschikbaarheid kunt switchen vanuit je CSS files ipv zelf nog JS er voor te moeten schrijven.

Nadeel (?)
Een extra file om in te laden. Verwaarloosbaar als je na gaat dat het maar een paar Kb minified/gzipped is, veelal kleiner dan het kleinste JPG plaatje dat je in de content van je webpagina terug kunt vinden. Daarnaast kan het ook nog eens statisch gecached worden met far future expiration, zodat een bezoeker het feitelijk maar één keer hoeft te downloaden.

[ Voor 13% gewijzigd door R4gnax op 15-06-2013 19:40 ]

[Ramon]

Verwijderd schreef op zaterdag 15 juni 2013 @ 16:21:
Hallo,

Bedankt allemaal voor de antwoorden, maar zoals gezegd: ik heb een php-script nodig... Dit werkt in ieder geval niet:

[code=php]
if (stristr($_SERVER["HTTP_ACCEPT"], "image/svg+xml"))
{
echo 'TRUE';
}
else
{
echo 'FALSE';
}
[/code=php]

Maar ik weet dan ook weinig tot niets van php. Iemand een werkend alternatief?

Hartelijke groeten,
Shelley

Misschien kunnen wij je beter helpen als we iets meer context hebben. Want met wat ik nu weet denk ik eigenlijk dat jij een verkeerde gedachtegang hebt waardoor je denkt dat je in PHP moet weten of de client SVG ondersteunt. Wat is er mis met de volgende opzet: 1) browser laadt html pagina 2) javascript kijkt of de browser SVG ondersteuning biedt. 3) zoja, insert het element wat de SVG toont 4) zo nee, doe iets anders. Je kan ook zoals hierboven staat met AJAX en met cookies gaan werken maar dat hoeft imho niet eens.

[_Thanatos_]

R4gnax schreef op zaterdag 15 juni 2013 @ 19:34:
[...]
Nadeel (?)
Een extra file om in te laden. Verwaarloosbaar als je na gaat dat het maar een paar Kb minified/gzipped is, veelal kleiner dan het kleinste JPG plaatje dat je in de content van je webpagina terug kunt vinden. Daarnaast kan het ook nog eens statisch gecached worden met far future expiration, zodat een bezoeker het feitelijk maar één keer hoeft te downloaden.

Een kleine extra file kun je prima in je bestaande javascript-file includen. Je hebt altijd wel iets van eigen javascript code, een default.js of functions.js of hoe je het ook wilt noemen. En daarin zet je de inhoud van je modernizr-build gewoon bovenin. Doe ik ook altijd. Scheelt weer een request.

@TS
SVG vanuit PHP detecteren kan volgens mij niet. PHP heeft geen weet van de capabilities van de browser. De User-agent string hiervoor gebruiken is onbetrouwbaar, en vergt teveel onderhoud.

Je kunt ook de aanname maken dat alle te ondersteunen browsers behalve IE8 en eerder géén SVG ondersteunen. Als die aanname goed genoeg is voor je doelgroep (als je bijv weet dat er geen Android <=2.3 gebruikt wordt), dan zou een conditional comment kunnen volstaan.

[ Voor 21% gewijzigd door _Thanatos_ op 15-06-2013 23:35 ]

[Compizfox]

Verwijderd schreef op zaterdag 15 juni 2013 @ 16:21:
Hallo,

Bedankt allemaal voor de antwoorden, maar zoals gezegd: ik heb een php-script nodig... Dit werkt in ieder geval niet:

[code=php]
if (stristr($_SERVER["HTTP_ACCEPT"], "image/svg+xml"))
{
echo 'TRUE';
}
else
{
echo 'FALSE';
}
[/code=php]

Maar ik weet dan ook weinig tot niets van php. Iemand een werkend alternatief?

Hartelijke groeten,
Shelley

Iets als dit server-side implementeren is niet alleen niet semantisch, je maakt het jezelf er ook nog eens moeilijker mee dan nodig is. Waarom denk je dat dit perse in PHP moet?

[Verwijderd]

Ik wil onder geen beding dat de php-code (zie helemaal bovenaan deze pagina) zichtbaar is de in broncode. Dan ligt een server-side oplossing voor de hand waarbij ik eerst filter op wel/geen SVG kunnen weergeven, en dan de php-code met/zonder

[code=php]
$selectie[6] = "Plattegrond: ";
[/code=php]

in de pagina gebruik. Eenvoudig en compact. Maar ik begin nu te beseffen dat dat niet mogelijk is in php (?). Jammer, want Modernizr, cookies, Ajax zijn niet echt een eenvoudige en compacte oplossing.

[Compizfox]

Verwijderd schreef op zondag 16 juni 2013 @ 11:58:
Ik wil onder geen beding dat de php-code (zie helemaal bovenaan deze pagina) zichtbaar is de in broncode.

PHP-code is nooit zichtbaar in de broncode die de client te zien krijgt.

in de pagina gebruik. Eenvoudig en compact. Maar ik begin nu te beseffen dat dat niet mogelijk is in php (?).

Het is wel mogelijk, maar dat moet dan heel omslachtig omdat je iets wat puur client-side is, server-side wilt gaan implementeren.

[Verwijderd]

PHP-code is nooit zichtbaar in de broncode die de client te zien krijgt.

Als ik een javascript gebruik om (afhankelijk van de SVG-ondersteuning) voor één van de twee PHP-scripts te kiezen (dus: met of zonder $selectie[6] =), is minstens één van die PHP-scripts in het javascript zelf te bekijken. En dat is precies de reden waarom ik een server-side oplossing wil.

[Ramon]

Verwijderd schreef op zondag 16 juni 2013 @ 16:06:
[...]


Als ik een javascript gebruik om (afhankelijk van de SVG-ondersteuning) voor één van de twee PHP-scripts te kiezen (dus: met of zonder $selectie\[6] =), is minstens één van die PHP-scripts in het javascript zelf te bekijken. En dat is precies de reden waarom ik een server-side oplossing wil.

Je bedoelt de URL naar je PHP-script? Is dat zo erg dan?

Ik denk zelf dat Modernizr makkelijker is dan zelf een javascript check schrijven. Modernizr hangt een class aan het html-element en dan kan je met CSS of met JS checken of die class bestaat en dan je uitvoer aanpassen daaraan.

[ Voor 19% gewijzigd door Ramon op 16-06-2013 16:08 ]

[C0rnelis]

Verwijderd schreef op zondag 16 juni 2013 @ 16:06:
[...]


Als ik een javascript gebruik om (afhankelijk van de SVG-ondersteuning) voor één van de twee PHP-scripts te kiezen (dus: met of zonder $selectie\[6] =), is minstens één van die PHP-scripts in het javascript zelf te bekijken. En dat is precies de reden waarom ik een server-side oplossing wil.

De scripts zelf zijn niet te bekijken in javascript, met standaard-instellingen van je webserver maakt het voor de server niet uit of jouw browser naar domein.nl/script.php gaat of dat er javascript diezelfde url aan roept. Geen van beide responses bevat de server-side logica met php-tags etc. De php-pagina genereert namelijk output en dat is dan ook het enige wat jij, je browser en javascript krijgt te zien. Heb je het uberhaupt al getest?

[ Voor 9% gewijzigd door C0rnelis op 16-06-2013 16:15 ]

[Verwijderd]

Ik begrijp eerlijk gezegd niet wat je wilt dat ik precies test (?).

Met een client-side oplossing is het niet mogelijk om het script volledig aan het zicht te ontrekken. Dat zal altijd ergens te bekijken zijn (bron, javascript, url, ...). Maar als ik het bij het verkeerde eind heb: ik word echt heel erg graag in het ongelijk gesteld. Want dat betekent namelijk dat je een oplossing voor mijn probleem hebt.

[Compizfox]

Welk script heb je het dan nu over? Onthoud dat PHP-scripts nooit zomaar te bekijken zijn door de gebruiker.

Als je je SVG-check in Javascript implementeert is uiteraard wel de Javascript te bekijken, maar hier zou ik niet zo'n probleem van maken. Javascript heb je voor bepaalde dingen gewoon nodig (ook al kun je tegenwoordig steeds met met HTML5 en CSS).

[Verwijderd]

Ik weet dat PHP-scripts niet te bekijken zijn. Daarom vroeg ik helemaal bovenaan deze pagina ook om een aanpassing van het PHP-script (want: server-side en dus niet te bekijken). Aan een SVG-check in JavaScript heb ik niks (want: client-side en dus wél te bekijken).

[ZpAz]

Verwijderd schreef op zondag 16 juni 2013 @ 20:11:
Ik weet dat PHP-scripts niet te bekijken zijn. Daarom vroeg ik helemaal bovenaan deze pagina ook om een aanpassing van het PHP-script (want: server-side en dus niet te bekijken). Aan een SVG-check in JavaScript heb ik niks (want: client-side en dus wél te bekijken).

En wat is het voordel dat men "de check niet kan bekijken in PHP"? Waarom wil je dat men dit niet kan zien?

[Ramon]

Verwijderd schreef op zondag 16 juni 2013 @ 20:11:
Ik weet dat PHP-scripts niet te bekijken zijn. Daarom vroeg ik helemaal bovenaan deze pagina ook om een aanpassing van het PHP-script (want: server-side en dus niet te bekijken). Aan een SVG-check in JavaScript heb ik niks (want: client-side en dus wél te bekijken).

Want je wil niet dat de client ziet dat jij in javascript op je webpagina een keuze maakt tussen wel/geen SVG tonen? Wat is daar precies erg aan?

Ik herhaal nog maar eens: Als jij iets meer context (de hele situatie, wat meer code, het uiteindelijk gewenste resultaat,
etc) geeft over je probleem kunnen wij je beter helpen.

[Compizfox]

Waarom mag het niet te bekijken zijn? Sommige dingen zijn nu eenmaal client-side. Het is 'verkeerd' om client-side dingen koste wat het kost server-side te willen implementeren omdat het dan niet te bekijken is.

[Verwijderd]

Want je wil niet dat de client ziet dat jij in javascript op je webpagina een keuze maakt tussen wel/geen SVG tonen?

Nee, ik wil niet dat de locatie van het datafile en/of de locatie van het zoekscript traceerbaar zijn. En nee, ik geloof niet in security by obscurity.

Maar volgens mij heb ik al een antwoord op mijn oorspronkelijke vraag gekregen, namelijk: 'Dat kan niet.' Hartelijk dank daarvoor. Ik zal naar een andere oplossing moeten zoeken.

[Ramon]

Verwijderd schreef op zondag 16 juni 2013 @ 20:25:
[...]


Nee, ik wil niet dat de locatie van het datafile en/of de locatie van het zoekscript traceerbaar zijn. En nee, ik geloof niet in security by obscurity.

De locatie van je datafile staat in het PHP script, dus dat kan de client sowieso niet zien. Het zoekscript moet je gewoon goed beveiligen door alle input te valideren. Als je wil dat de client een bepaald PHP script gebruikt, kan je dan niet verbergen voor diezelfde client.

[Compizfox]

Je zegt dat je niet gelooft in security by obscurity maar toch is dit precies wat jij nu aan het doen bent. Je obscured namelijk de locatie van je datafile en je zoekscript, terwijl dat niet nodig is als je die gewoon goed beveiligd.

[Paul]

Verwijderd schreef op zondag 16 juni 2013 @ 20:25:
Nee, ik wil niet dat de locatie van het datafile en/of de locatie van het zoekscript traceerbaar zijn.

Hoe wil je het zoekscript aanroepen dan Iemand GET (of POST) toch naar www.server.com/zoeken.php lijkt me...

En nee, ik geloof niet in security by obscurity.

Nu spreek je jezelf tegen...

Maar, ik het kort wil je dus niet dat mensen de volgende code kunnen zien:
[code=javascript]
if(document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1") )
{
// Laat plaatje zien
}
else
{
document.write("SVG unabled"); // sic
}
[/code=javascript]

De locatie van het plaatje 'expose' (oeh, eng...) je toch al het enige wat men dus kan zien is een aanroep naar hasFeature

offtopic:
@RobIII: Ej, ik copy/paste het ook maar van de TS

[ Voor 4% gewijzigd door Paul op 16-06-2013 22:35 ]

[NMe]

Ik hoor inderdaad geen enkel steekhoudend argument om dit in PHP te willen doen. Doe het asjeblieft gewoon in Javascript waar het hoort.

[RobIII]

[quote]Paul schreef op zondag 16 juni 2013 @ 20:39:

JavaScript:

document.write("SVG unabled");
[/code=javascript]

offtopic:
Unabled ja? Unavailable, disabled, iets in die richting bedoel je denk ik

Ik zie 't nut ook niet; sterker: ik vind 't een redelijk absurd topic geworden. De locatie van de file kom je toch gewoon meteen achter als je een andere browser neemt? Hoe wil je dan voorkomen dat ik die file niet alsnog ophaal met een "SVG unabled" ( ) browser?

[ Voor 34% gewijzigd door RobIII op 16-06-2013 22:19 ]

[SPee]

Inderdaad.
Het is raar dat je een check wilt verbergen, omdat je anders een bestandslocatie te zien krijgt.
Maar in een andere browser krijg je die locatie toch te zien.
Dus sowieso raakt die locatie bij de clients bekend.
Dus waarom verbergen?

HTML:

<div id="svgonly" style="visibility:hidden">
   Plattegrond: <svg>
</div>
<script>
if ( Modernizr.svg ){ document.getElementById ('svgonly').style.visibility='visible';}
</script>