Svenska ElektronikForumet

Alla har vi varit barn i början, inget att skämmas för

Webbläsare, och vad som behövs eller ej:
* Parsa HTML - Ja
* CSS - Ja
* Javascript - Ja
* Bygga upp DOM-träd - Nej
* Hantera mus - Ja
* Tangentbord - Ja
* Touch - Endast datortelefon
* GPS - Nej
* Mikrofon - Nej
* Accelerometer - Nej
* Ladda ner filer över HTTP - Ja
* Kryptering med HTTPS - Ja
* Säker lagring av lösenord - Fungerar ändå inte
* Lagring av kakor - Ja med påtvingad giltighetstid
* Filtring av vilka resurser får tillgång till kakorna - Ja
* Ladda ner bilder - Ja
* Avkoda bildformat - Ja
* Rendera DOM-trädet till skärmen skalad till 96 dpi - Nej
* Kompilera Javascript - Fungerar utan, så nej
* Optimera Javascript - Fungerar utan, så nej
* Jäkla massa annat - Oftast onödigt

Webbläsaren behöver göra en hel del. Men det finns en hel del onödiga tillägg i den också. Användande av Javaskript, bakgrundsbilder, textfärg, kakor, osv borde ha en åtkomstkontroll per sajt för att kyla av de värsta webbhipstersna.

Webbläsaren Dillo får väl ses som en som är effektiv. Den saknar stöd för Javascript dock. Med en kodstorlek på 430 kByte och starttid på någon sekund. Arora lär också vara effektiv med storlek på 1,2 MByte och stöd för Javascript samt Frames. Mycket beror på vad man skall använda det till.

TomasL skrev:Alla har vi varit barn i början, inget att skämmas för

Du anar inte vad den kommentaren värmer!

Tack!

MVH/Roger

blueint skrev:Webbläsare, och vad som behövs eller ej:
* Parsa HTML - Ja
* CSS - Ja
* Javascript - Ja
* Bygga upp DOM-träd - Nej
* Hantera mus - Ja
* Tangentbord - Ja
* Touch - Endast datortelefon
* GPS - Nej
* Mikrofon - Nej
* Accelerometer - Nej
* Ladda ner filer över HTTP - Ja
* Kryptering med HTTPS - Ja
* Säker lagring av lösenord - Fungerar ändå inte
* Lagring av kakor - Ja med påtvingad giltighetstid
* Filtring av vilka resurser får tillgång till kakorna - Ja
* Ladda ner bilder - Ja
* Avkoda bildformat - Ja
* Rendera DOM-trädet till skärmen skalad till 96 dpi - Nej
* Kompilera Javascript - Fungerar utan, så nej
* Optimera Javascript - Fungerar utan, så nej
* Jäkla massa annat - Oftast onödigt

Webbläsaren behöver göra en hel del. Men det finns en hel del onödiga tillägg i den också. Användande av Javaskript, bakgrundsbilder, textfärg, kakor, osv borde ha en åtkomstkontroll per sajt för att kyla av de värsta webbhipstersna.

Webbläsaren Dillo får väl ses som en som är effektiv. Den saknar stöd för Javascript dock. Med en kodstorlek på 430 kByte och starttid på någon sekund. Arora lär också vara effektiv med storlek på 1,2 MByte och stöd för Javascript samt Frames. Mycket beror på vad man skall använda det till.

Det här värmer också en hel del!

Jag gillar din passion, blueint!

MVH/Roger

blueint skrev: * Bygga upp DOM-träd - Nej

Hur ska då CSS fungera?

blueint skrev: * Rendera DOM-trädet till skärmen skalad till 96 dpi - Nej

Så när sidor renderas på en ny skärm med hög upplösning (alla telefoner t.ex.)
så vill du att texten ska bli minimal och oläsbar?

blueint skrev:Fungerar utan, så nej

Så du tycker inte bbcode knapparna
här på forumet är smidiga? Och webbapplikationer som gmail ska inte få finnas?

blueint skrev:Webbläsaren behöver göra en hel del. Men det finns en hel del onödiga tillägg i den också. Användande av Javaskript, bakgrundsbilder, textfärg, kakor, osv borde ha en åtkomstkontroll per sajt för att kyla av de värsta webbhipstersna.

Installera noscript i Firefox.

Eftersom jag nu är på gott humör igen tänkte jag fortsätta pladdra lite i nattmössan

Min lilla ändring "läsa ner sidor på nätet" menades retroaktivt täcka fallet nerladdning av godtyckliga filformat (typ pdf, jpg, mov) och inte bara html/php.

För tanken som dök upp under dan var att webbläsare inte behöver ha plug-ins för dessa filformat.

Programmen kan lika gärna vara separata dvs man bygger sin webbläsare som så att dessa filtyper sparas i typ tre olika kataloger på hårddisken (när man klickar på dom likt man försöker spara en *.zip), säg Dokument, Bilder, Video och att man sedan går ut och "kör" de nytankade filerna separat (med exempelvis Adobe Reader m.fl).

Jag ser två nackdelar:

1) Browsningen blir inte så rolig
2) Det är inte säkert man "får/kan" ladda hem t.ex ett videoklipp från YouTube på detta viset.

Fördelarna är dock tre:

1) Browsern blir enklare.
2) Man slipper allt "insticksmodulen är sårbar"-fjanteri
3) Du kan själv styra vilken version av program du vill ha för att köra filen (så länge det går, dvs)

Är den här ide'n nåt att ha?

MVH/Roger

Förutom PDF läsare som är inbyggda i webbläsaren (Chromes egena eller PDF.js i
Firefox) så är alla externa program. De inbyggda kan du dessutom stänga av. I
inget av webbläsarna med integrerad PDF-läsare är den en integrerad del av koden
och laddas aldrig in om du inte använder den. I Firefox är den inget annat än vilken
webbsida som helst.

Så mycket för den ide'n

Men jag ser klar skillnad på min tvungna FF 31 på jobbet när jag klickar på en pdf och när jag hämtar hem den och kör den med AR 11.

När jag klickar på den går CPU'n på knäna och det tar en våldsam tid innan den går att läsa men kör jag den "externt" går det nästan på en gång.

Jag har en 10Mb-lina på jobbet.

MVH/Roger
PS
Datorn är minst 10 år. SCSI-HD bl.a

1) Man får ett separat sårbarhetsproblem istället med fler program som skall patchas mm
2) Webbläsandet blir klumpigt och ineffektivt men plugin för allt skulle dock göra det möjligt att byta ut delar mycket lättare

Den där inbyggda PDF mekanismen fungerar oftast dåligt. Speciellt om det är lite större dokument i antal MByte eller sidor. I synnerhet om man vill söka efter text.

Det finns en webbläsare som är helt modulär. Den kallas Breach. Citat "Breach goes one step beyond Mozilla & Chrome, who enable developers to build 3rd party add-ons/plugins for the respective browsers when you first start Breach, it has no functionality. Functionalities are brought in by modules, meaning that everything down to the core features of a browser navigation, display, etc. are hackable."

blueint skrev: Det finns en webbläsare som är helt modulär. Den kallas Breach. Citat "Breach goes one step beyond Mozilla & Chrome, who enable developers to build 3rd party add-ons/plugins for the respective browsers when you first start Breach, it has no functionality. Functionalities are brought in by modules, meaning that everything down to the core features of a browser navigation, display, etc. are hackable."

JESUS, detta är vad jag har drömt om och pratat med min kollega om i så många år!

VARFÖR kan inte saker och ting i datavärlden vara mer moduluppbyggt?

OCH/ELLER open source?

SÅ man kan skräddarsy saker och ting som man vill ha det!

Min tanke började dock med att jag fanimej inte behöver 1000 fonter i Word. Om jag vill ha 1000 fonter så borde man kunna köpa det separat!

Jag behöver ju bara EN

MVH/Roger

Det finns en stor tröghet i befintlig utrustning, befintlig programvara, ingånga avtal och inte minst hur människor tänker (vanor). Så att bryta ny mark är trögt.

rogerk8 skrev: 5) Om vi vänder på frågan då? En browser t.ex, vad behöver den egentligen ha för finesser? Jag ser bara fem dvs den ska kunna läsa (ner) sidor på nätet, man ska kunna klicka på länkar för kunna komma till annan sida, man ska kunna skicka information, den bör ha flikar och den bör gärna ha möjlighet att spara bokmärken.

Problemet är att dina fem "finesser" består av flera dussin olika funktioner.

För att kunna läsa ner sidor måste den dels kunna hantera http (relativt lätt att göra) och dels https (krypterad förbindelse, vilket kräver en hel del beräkningar). De flesta webbläsare idag klarar också ftp så folk ska slippa ha ett separat ftp-program.

Sen vill du väl att sidan ska visas på skärmen också? Sidan måste alltså renderas. Där måste då HTML och CSS läsas in, "trädifieras" och parsas så alla element hamnar där de ska och får rätt utseende. Elementen på sidan då? Ja, text är fint. Vilken teckenkodning? Ska browsern bara klara amerikansk text från vänster till höger utan åäö? Eller ska den kanske klara alla möjliga språk, även såna som skriver från höger till vänster och såna där tecken ser olika ut beroende på omgivande tecken?

Bilder kanske ska finnas på sidan? Vilka bildformat ska kunna hanteras? De flesta bildformat är komprimerade och kräver beräkningar för att "packas upp". Med CSS kan man dessutom styra storlek på bilderna så webbläsaren behöver kunna skala om dem (och troligen rotera också, jag har inte riktigt koll på om CSS även stödjer rotering). Transparens i bilder gillar de flesta webbutvecklare idag, det kräver ytterligare beräkningar för att fungera.

Och nu har vi ändå bara avverkat EN av dina fem "finesser".

> OCH/ELLER open source?
> SÅ man kan skräddarsy saker och ting som man vill ha det!

Därför att för 99.999 % av alla användare så är det komplett ointressant.

Det går inte att diskutera hur en vanlig "PC" ska fungera med ett gäng nördar.
Speciellt om de tror att om något inte fungerar som man vill, så är det bar att
hämta källkoden och fixa det. Oerhört naivt och långt från verkligheten så klart.

> Oj, vad jag har trampat i klaveret!

Nja, jag tycker att du har en poäng i sak, men dina slutsatser kanske inte
alltid är helt korrekta. Det har funnit problem med vissa projekt (flera av dom
har valsat runt i media efter att de craschat) där man kan koppla misslyckadet
till en oansvarig tilltro till "nya" tekniker och plattformar och där man har saknat
all känska för sådant som skalbarhet. Ofta skrivet i något modernt som Java eller
liknande. Eller något färdigt paket som t.ex Polisens system med ett Oracle syste
som inte höll måttet. Inom vårdsvängen har det också varit ett par projekt med
liknande problem.

Problemet är att de som inte förstår bättre, försöker skala upp tekniker som
fungerar OK på e 4-core "PC" till stora servrar med 100 eller 1000-tals användare.

I dessa fall handlar det till stor del om det som du har försökt beskriva, men där du
har gett exempel från "PC" miljöer där problemet inte får lika allvarliga konsekvenser.

Skulle nog vilja påstå att renderingen av html till grafisk presentation är den tuffaste biten. Att fixa dekodning av bilder och transparens. Eller kryptoöverföring modell https är betydligt enklare.

Allt gällande bilder från gif till jpeg2000 skulle kunna hanteras med plugins.

En dräglig webbläsare bör klara:
* http, https
* html + frame + css rendering
* gif-png-jpeg avkodning och skalning
* Javascript
* Inställningar som listar godkända webbsajter för javascript och annat som kan missbrukas

Sedan bör webbläsarens rendering ske i en sandbox då risken för allehanda exploits är stor.

sodjan skrev:> OCH/ELLER open source?
> SÅ man kan skräddarsy saker och ting som man vill ha det!

Därför att för 99.999 % av alla användare så är det komplett ointressant.

Här missuppfattar du mig lite. Jag menar mest den modulära biten och inte just open source för det behöver den faktiskt inte vara. För om bara mjukvarutillverkarna skärpte till sig lite så skulle jag kunna köpa exakt de moduler jag vill ha. Fast det är klart, att kunna designa sina egna moduler är förstås ännu mer attraktivt (även om jag ju inte ens kan programmera )

> Oj, vad jag har trampat i klaveret!

Nja, jag tycker att du har en poäng i sak, men dina slutsatser kanske inte
alltid är helt korrekta.

Tredje gången ikväll som nån värmer mig

Problemet är att de som inte förstår bättre, försöker skala upp tekniker som
fungerar OK på e 4-core "PC" till stora servrar med 100 eller 1000-tals användare.

Det här tror jag mig förstå.

I dessa fall handlar det till stor del om det som du har försökt beskriva, men där du
har gett exempel från "PC" miljöer där problemet inte får lika allvarliga konsekvenser.

Och då borde jag ju förstå det här, eller hur?