ugrás a tartalomhoz

Miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás elemeket?

Atomi · 2021. Feb. 10. (Sze), 22.08
2021 van, modern honlapok készítésére van lehetőség CSS-sel, Flexbox-szal, html5-tel.
Amit nem értek (próbáltam utánajárni, az okának), hogy miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás, stb. alap elemeket?

Miért vagyunk arra kényszerítve, hogy mindenféle hack megoldást alkalmazzunk, ráadásul van amit nem is lehet rendesen, pl. a Tallózás gombot.

Magát a jelenséget nem értem. Ez valami beteges maradvány a böngészőháborúból, hogy mindenki ránk kényszerítse a saját ronda elemeit?
 
1

Valahogy úgy. Egyébként lehet

inf · 2021. Feb. 11. (Cs), 02.23
Valahogy úgy. Egyébként lehet mindegyiket, file inputnál le kell venni az opacity-t és fölé kell tenni egy képet, a checkbox-nál meg display none kell a checkboxra és a label-t lehet formázni. link Olyan 6 éve jelentettem, hogy nem működik ezeknél a billentyűzetes bejelölés, csak az egeres, és azóta sem történt semmi az ügy érdekében. Nagyjából ez a szint a böngészőknél. Már akkor utáltam, hogy minden böngészőben máshogy működik egy kód, vagy egyáltalán nem megy valami bug miatt, azóta messzire kerülöm a frontendet, ha csak lehet néhány hobbi projekttől eltekintve.
2

Engedik

Pepita · 2021. Feb. 11. (Cs), 10.18
miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás, stb. alap elemeket?
Miért ne engednék?
Egyedül a file input nehézkes egy kicsit, mert több részből áll, de szó sincs arról, hogy ne "engednék".
2021-ben - ha később nem is akarod felhasználni - próbaképpen húzz be a projektbe egy népszerű frontend keretet (pl Bootstrap, de más is lehet), csinálj vele egy teszt-formot, és nézd meg, milyen szelektorokkal milyen szabályokat használ. Sokat lehet belőle tanulni; ha utána nem is használod élesben, akkor is jócskán lehet tanulni a meglévő modern FE keretekből. Ezeket - a népszerűbbeket - sokan fejlesztik, így sok ember tudása benne van.
Aztán ha valamelyik megtetszik, az se baj, ha "bent hagyod" a projektben és használod, nekem legalábbis már nemigen van időm és türelmem arra, hogy 0-ról én írjam az összes css-t...
3

Drupal Zen témából indulok ki

Atomi · 2021. Feb. 11. (Cs), 20.26
Drupal Zen témából indulok ki mostanában, de csináltam már nulláról is, végeredményben a teljesen saját jobb, mert nem megy el idő azzal, hogy rájöjjek, mit hol csináltak egy meglévőben.
Csak hát a gányolás elkerülhetetlen, amit nem szeretek.

Ha engednék, az azt jelentené, hogy lenne rá CSS separator, ami kedvünk szerint engedné a változtatás, nem eltüntetni, meg átlátszóvá tenni az elemeket, stb.

A Bootstrap-ot is néztem, de az túl összetett, meg kéne az egészet érteni, túlságosan kötve vagyok akkor.
4

Én a 90-es évek vége óta

inf · 2021. Feb. 11. (Cs), 22.45
Én a 90-es évek vége óta nézegetem a HTML és JS kódokat, és azt kell, hogy mondjam, hogy ez nem fog változni. A kliens oldalon mindig lesz tákolás és mindig lesz, ami eltörik egyik vagy másik böngészőben. A keretrendszereket érdemes használni pont emiatt, mert akkor nem te szívsz vele, hanem a keretrendszer készítője. Én is szeretem a saját kódot, de nem túl produktív, ha neki állsz sajátot hegeszteni ahelyett, hogy olyat használnál, ahol már rászánták azt a fél-egy év tesztelést különböző böngészőkben. Ha hobbi projekt, vagy csak egy böngészőben kell, hogy menjen, akkor persze mindegy.
5

Én nem így látom.Szerintem

mind1 valami név · 2021. Feb. 13. (Szo), 12.24
Én nem így látom.
Szerintem elég tempósan haladunk afelé, hogy egységes legyen a böngésző.
Lassan nem marad más, mint a chrome... pardon, chromium alap.
A mozilla már egy éve dolgozik a firefox tempós tönkretételén, a MS már chromium a ... más most nem is nagyon jut eszembe ami elterjedt.
Opera/vivaldi még talán ott vannak, de helyenként a vivaldi kísértetiesen chrome-szerű... nem tudom, miért. (felhasználóként mondom)

ui: ja, meg a Safari ami talán kilóg mindebből.
6

Ja Firefox-nál ha megnézed a

inf · 2021. Feb. 13. (Szo), 16.52
Ja Firefox-nál ha megnézed a bug reportok egy része "Chrome compatibility". Úgyhogy már egy jó ideje a Chrome mondja meg, hogy mi legyen, ők csak követik. Valami antitrust vizsgálat lehet, hogy befigyel a végén, mint a Microsoft-nál, de nem igazán van fogás rajtuk, mert nem kényszerítenek senkit arra, hogy telepítsék a Chrome-ot, egyszerűen csak ez a legjobb a piacon az emberek többsége szerint.
7

Opera, meg a többi.

Arnold Layne · 2021. Feb. 13. (Szo), 16.59
Úgy tudom Opera is már régesrég dobta a sajátját (Presto talán) a webkitért. Talán a Safari, de úgy tudom az se nagyon lóg ki a sorból, mert ha jól tévedek nem túl messzi a közös őse a Safarinak és a Chrome-nak. Meg talán a KDE is érintett (volt) a dologban. De fixme. Szóval egy darabig még a Mozilla kilóg a sorból, meg a fejl...akarommondani változásban megállt forkjai, úgy mint Pale Moon, meg van valami mosómedvés is, de annak nem jut eszembe a neve. De ez utóbbiak erősen futottak még esetek.
9

Hogyan teszi tönkre a Mozilla

Endyl · 2021. Feb. 15. (H), 12.47
Hogyan teszi tönkre a Mozilla a Firefoxot? Csak mert számomra még mindig a leghasználhatóbb böngésző akár böngészésre, akár fejlesztésre.
13

Akkor te nem használod

mind1 valami név · 2021. Feb. 15. (H), 16.58
Akkor te nem használod Androidon...
Már az első váltás pár évvel ezelőtt is, finoman szólva katasztrofális romlást hozott a használhatóságban, ez az egészen új, amivel a bővítmények 90%-a ment a kukába... egyszerűen tragikus.
A közelmúltban kirúgták a fejlesztők nagy részét.
Sok jót ezek után nem várok tőlük.
14

De, androidon is a kedvencem.

Endyl · 2021. Feb. 15. (H), 22.17
De, androidon is a kedvencem.
8

Tákolás

Endyl · 2021. Feb. 15. (H), 12.43
Szerintem a frontend tákolásnak két fő forrása van.

Egyrészt ugyebár a frontend "NeM IGaZi PrOgRAmOzÁs". Főleg a HTML és a CSS, és elkezdtek mindent áttolni JS-be. Mert hát CSS-sel nem lehet problémákat megoldani, de akik ezt mondják azoknál a CSS kimerül abban, hogy:
div div div div > span#my-h1 {
  color: red;
  z-index: 9999999999999999999 !important;
  font-size: 56px !important;
}
Így mindenki Reacttal meg Vue-val kezd, aztán csodálkoznak, hogy nem értik, miért úgy működnek a dolgok ahogy.

A másik probléma meg az, hogy még mindig megpróbálják a webes megjelenítést megerőszakolni egy pixelpontos elrendezéssel bármilyen eszközön (mert nyomtatásban az milyen jól működik) ahelyett, hogy egyszerűen a használhatóságra mennének.
10

+1

Pepita · 2021. Feb. 15. (H), 13.23
A color: red; miért nem important?... :-D
12

Konzisztencia

Endyl · 2021. Feb. 15. (H), 14.49
Az túl konzisztens lenne.
15

Probléma

Arnold Layne · 2021. Feb. 16. (K), 11.50
A másik probléma meg az, hogy még mindig megpróbálják a webes megjelenítést megerőszakolni egy pixelpontos elrendezéssel bármilyen eszközön

A probléma inkább az, hogy van nekünk a HT*, ami tök jó dokumentumok megosztására a hálózaton, csak hát az igények túlnőtték. Nem elég már, hogy csak megjelenítjük böngészőben, hanem szerkesszük is böngészőben, közben videócseteljünk is mellette szintén böngészőben, satöbbi. Az a véleményem az egészről, hogy tököt kéne növeszteni és azt mondani hogy a HTML akkor maradjon csak meg dokumentumoknak, és mellé/fölé valami olyan alkalmazások írására alkalmas tech rakást odatenni, ami tényleg alkalmazások írására van kitalálva. Mert — továbbra is csak véleményem szerint — ezzel a HTML5-tel és a modern webnek csúfolt valamivel csak egy seggel próbálunk meg két lovat megülni. És valamiért tudomást sem akarunk venni arról, hogy így akár a két ló közé is be lehet esni. Szerintem.
16

Volt ilyen, java applet,

inf · 2021. Feb. 16. (K), 11.54
Volt ilyen, java applet, flash, silverlight, valahogy mind kidöglöttek és html5 lett helyette. Gondolom oka van.
17

Annyi légy nem tévedhet

Arnold Layne · 2021. Feb. 16. (K), 12.46
Java appletből nem sokkal találkoztam, a Flash és a Silverlight pedig tudtommal zárt volt. Egyetlen előnyét tudom elképzelni a HTML5-nek: az olcsó és gyorsan pótolható munkaerő. Gondolom hasonló okok miatt halt ki az XHTML is: nem tolerálta a gányolást. De javítsatok ki ha tévednék.
18

Korai APEH adóbevallás?

mind1 valami név · 2021. Feb. 16. (K), 13.38
Korai APEH adóbevallás? :)
Vagy az nem applet volt?

Azon túl csak egykori munkahelyem egyik csodaszoftverét tudnám emlegetni, de esetleg elpirul a háttérkép is :D
19

Korai APEH adóbevallás?

Arnold Layne · 2021. Feb. 16. (K), 14.30
Korai APEH adóbevallás? :)
Vagy az nem applet volt?

Nem tudom, akkoriban még nem kellett adóbevallással foglalkoznom.
21

A Flash azt hiszem többé

inf · 2021. Feb. 17. (Sze), 01.16
A Flash azt hiszem többé kevésbé gányolható volt, olyasmi, mint a js most. A java és a C# olyan nyelvek, amikhez azért nagyobb képzettség kell, mint ilyen script nyelvekhez, nem véletlen nem született sok applet és silverlight program sem. Az utóbbit nagyon szerették, akik értettek hozzá úgy hallottam. Én szerettem az XHTML-t, kimondottan jó volt, hogy XML parsolható, lehetett névtereket használni, akár RDF-et beilleszteni, kár érte, hogy nem folytatták.
20

Tudtommal a html továbbra is

Endyl · 2021. Feb. 16. (K), 16.21
Tudtommal a html továbbra is dokumentumstruktúra leírásra való, a megjelenésért felel a css, az alkalmazáslogika meg a js dolga. Ezek szépen fejlődnek is.

Most inkább úgy tűnik, hogy a tömegek megragadtak az IE korszakban és oda-vissza erőszakolják meg* a fenti három technológiát olyan dolgokkal, amik nem a feladatuk, és csodálkoznak, hogy nem, lassan, vagy rosszul működnek.

Plusz mindenkinek meg van ígérve, hogy 5 perc alatt fb klónt csinálhat, "jótékonyan" hallgatva a szükséges tudásról és az oda vezető útról. Emberi problémákat akarunk megoldani technológiai megoldásokkal*. Az embereket kéne segíteni a fejlődésben ahelyett, hogy hozzávágunk a dologhoz még "5 kiló technológiát", aztán furcsálljuk, hogy az emberek nem tudnak kiigazodni rajta.

* Gondolok itt a css-in-js vagy a <span class="button"></span> jellegű csodákra.
22

Hogy őszinte legyek én már a

inf · 2021. Feb. 17. (Sze), 01.23
Hogy őszinte legyek én már a CSS-nél elvesztettem a fonalat, hogy erre miért kell nekünk egy új nyelvet kitalálni, miért nem lehet JS-ből megoldani. Azóta sem igazán értem, maximum az lehet érv, hogy gyorsabban feldolgozható és ha valaki kikapcsolja a JS-t, akkor nem esik szét az oldal. Nekem ez nem elég érv mellette azóta sem, de másoknak biztos az volt.
23

Kulcsszó: "struktúra"

Pepita · 2021. Feb. 17. (Sze), 09.31
a html továbbra is dokumentumstruktúra leírásra való
Csak egyetérteni tudok.
Kicsit részletezve:
- HTML: mit akarok megjeleníteni
- CSS: hogyan jelenik meg, milyen színű, mekkora, legyen-e körülötte rózsaszín köd, stb
- JS: mi történjen akkor, amikor a user pl megnyom egy gombot.

Aztán sajnos azok miatt, akiknek meg lett ígérve,
hogy 5 perc alatt fb klónt csinálhat
, miattuk igen nagy az átfedés a két leíró- és a szkript-nyelv között. Gyakorlatilag mindegyik "rétegből" meg lehet változtatni a másikat - ebből aztán egyenesen következik sajnos, hogy
erre miért kell nekünk egy új nyelvet kitalálni

(Egyébként attól, hogy js-ből változtatsz html-t vagy css-t, ezek még mindig különálló leíró nyelvek maradnak.)

Nem akarlak meggyőzni, mert a technológiai szabványok feladata nem az, hogy egy-egy embert meggyőzzön, hanem az, hogy ha sok ember akar azonos technológiát használni, akkor ezt megtehessék, egyforma tudásszinttel egyforma minőséget tudjanak létrehozni.
25

A CSS-sel

Endyl · 2021. Feb. 17. (Sze), 13.02
A CSS-sel egyszerűbb/hatékonyabb leírni egy layoutot/megjelenést (mivel erre lett kitalálva), az újraszámolások sokkal gyorsabbak, mint bármi, amit JS-ből meg lehetne csinálni, stb.

Például nem véletlen, hogy megjelentek a CSS-animációk. A JS animációk teljesítménye olyan gyatra volt, hogy kellett egy jobb, gyorsabb megoldás: CSS. Vagy pl. a masonry layout.

Arról nem is beszélve, hogy a JS nem csak akkor nem működik, ha valaki direkt kikapcsolja. Reklám- vagy szkriptblokkolók, hibás vagy direkt szűrő proxyk, szakadozó/hullámzó kapcsolat mind okozhatják. Vagy akár egy nem 100%-ig bugmentes JS kód is futhat úgy hibára, hogy a layout engine leáll (vagy a layout engine hibája miatt áll le az alkalmazáslogika; egyik se túl szerencsés).

Mondjuk furcsa, hogy az IT más területein azért "harcolunk", hogy minden csak a saját feladatát oldja meg (SRP), vagy ne kelljen ugyanazt többször megcsinálni (DRY), de a JS-be csak azért is bele próbáljuk erőltetni a layout/megjelenítés számolását, újra meg újra megoldva azokat dolgokat kevésbé hatékonyan, amik CSS-ből már működnek, ráadásul nagyobb hibatoleranciával.
26

Mondjuk furcsa, hogy az IT

inf · 2021. Feb. 17. (Sze), 21.18
Mondjuk furcsa, hogy az IT más területein azért "harcolunk", hogy minden csak a saját feladatát oldja meg (SRP), vagy ne kelljen ugyanazt többször megcsinálni (DRY), de a JS-be csak azért is bele próbáljuk erőltetni a layout/megjelenítés számolását, újra meg újra megoldva azokat dolgokat kevésbé hatékonyan, amik CSS-ből már működnek, ráadásul nagyobb hibatoleranciával.


Az SRP teljesen más kontextusban értendő. A HTML és a CSS domain specific language-ek, a JS meg general purpose language. Ennyi erővel minden alkalmazáshoz tervezhetnénk külön nyelvet könyvtárak helyett, ha ez így működne. Szerintem csak arról van szó, hogy sokan nem voltak hajlandóak a HTML helyett valami újat megtanulni. Ami végülis oké, ha csak néhány dokumentumot akarunk a weben megjeleníteni, de ha alkalmazás fejlesztésről van szó, akkor gagyi a HTML.
27

Nyilván

Endyl · 2021. Feb. 18. (Cs), 09.53
Nyilván más az SRP kontextusa, de attól még általánosítható belőle az a megfigyelés, hogy hatékonyabb és könnyebben kezelhető lesz egy olyan komponens, aminek egy feladata van 100 helyett.

Ezen felül, ahogy Pepita mondta, attól még, hogy JS-ből piszkálják egyesek a CSS-t, attól az még CSS marad. Ha nem értik a CSS-t, akkor JS-en keresztül sem lesz egyszerűbb jó, hatékony CSS-t írni. Tehát végeredményben a szuboptimális CSS-üket még megfejelték némi szükségtelen JS feldolgozási és futtatási idővel, ami elég kontraproduktívnak tűnik.

Szerintem csak arról van szó, hogy sokan nem hajlandóak a JS helyett valami "újat" (khm, az alapokat) megtanulni :)
28

Ezen felül, ahogy Pepita

inf · 2021. Feb. 18. (Cs), 23.19
Ezen felül, ahogy Pepita mondta, attól még, hogy JS-ből piszkálják egyesek a CSS-t, attól az még CSS marad. Ha nem értik a CSS-t, akkor JS-en keresztül sem lesz egyszerűbb jó, hatékony CSS-t írni. Tehát végeredményben a szuboptimális CSS-üket még megfejelték némi szükségtelen JS feldolgozási és futtatási idővel, ami elég kontraproduktívnak tűnik.


Jó, de én egyáltalán nem erről beszéltem, hanem hogy amikor annak idején 20 éve behozták a CSS-t, akkor kellett volna egy kicsit átgondolni, és helyette JS-el megoldani. Biztos, hogy abban is elérhető ugyanez a sebesség, mint CSS-el, ha hajlandóak ráfordítani a fejlesztési időt. És akkor nem kellett volna tök feleslegesen még egy nyelvet megtanulni, vagy mondjuk azon agyalni, hogy ez a stílus, amit egy elem éppen kapott a CSS, HTML vagy a JS fájlban van megadva. Na mindegy ez a hajó már 20 éve elment, úgyhogy kár vitatkozni rajta.
29

Nem hozták be

Pepita · 2021. Feb. 19. (P), 09.57
amikor annak idején 20 éve behozták a CSS-t
Nem "hozták be", hanem kezdettől fogva a HTML "társa" bizonyos formában. Kezdetben nem volt látható forráskód szinten (még nem is "igazi" css volt), de a legelső böngészőkben is tudott a felhasználó betűméretet, stb, stílust állítani magának.
Emellett sok más asztali szoftverben is megszokott volt a '90-es évektől, hogy a megjelenésre vonatkozó adatokat (pl ablak, gombok mérete, felirata) külön tárolja a működéstől (pl windows alatt *.ini fájlok).
1996 decemberében a CSS level 1 ajánlata hivatalosan is megjelent.
Tehát majd' negyed százada van lehetősége "olvasható" nyelven, az attribútumoknál részletesebben beavatkoznia a szerzőnek a dokumentum kinézetébe.

Remélem feltűnt, hogy idáig csak dokumentum, kinézet, szerző és felhasználó szerepelt. Még semmi sem "működik", csak visszamentünk az alapokhoz.
És akkor az érdekesség:
A JavaScriptet először 1997–99 között szabványosította az ECMA „ECMAScript” néven.
Vagyis '96-ban esély sem volt beleerőszakolni, még ha akarták volna sem.
Megjegyzem: valószínűleg sokkal kevesebb és másmilyen webfejlesztők lennének ma, ha egykor meggondolatlanul "összegyúrták" volna a nem összeillő dolgokat.

ez a stílus, amit egy elem éppen kapott a CSS, HTML vagy a JS fájlban van megadva
Kb minden mai böngészőben vannak fejlesztői eszközök (Chrome, FF, Opera, Edge biztosan), amikkel 2-3 másodperc alatt láthatod, hogy minek és milyen megjelenítési hatása van az elemre. A hellyel együtt, ahol a css szabály definiálva van.
Az tud cumi lenni ebben, amikor pl js-ből kap további css class-t az elem, vagy netán inline style-t: böngészőben az látszik, hogy ott van, az nem, hogy "js-ből jött". Ezért sem szabad js-ből "design-olni".

Alapok: HTML, CSS, JS. Ebben a sorrendben. Valószínű Neked a CSS kimaradt, vagy nincs elég jó szinten, ezért szeretnéd js-ből megoldani. Mindig sokkal lassabb lesz úgy, mert újra kell építeni hozzá a DOM-ot (egy részét).
Csinálj szép weboldalt teljesen js nélkül, meg fogod látni, hogy valójában nem kell a megjelenéshez js.
30

Én úgy emlékszem, hogy annak

inf · 2021. Feb. 19. (P), 10.18
Én úgy emlékszem, hogy annak idején maga a külön style tag és a css fájl egyáltalán nem volt jelen, inkább csak attribútumokban adták meg a dolgokat, és nem hasznosították újra. Viszont most visszanéztem, és 2000-ben a weblabor.hu-nál már volt külön css fájl, igaz ha belenézünk a kódba, akkor vegyesen még benne volt a formázás:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0052)http://weblabor.externet.hu/leiras/javascr/index.htm -->
<HTML><HEAD><TITLE>Weblabor - JavaScript</TITLE>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="Weblabor (C) 1999 [http://weblabor.externet.hu/]" name=Copyright>
<META content="hungarian, hun, hu, magyar" name=Language>
<META content="Weblabor - JavaScript" name=Description>
<META content=all name=Robots>
<META content="20 days" name=Revisit-After>
<META 
content="javascript, jscript, js, juray, Juray Tamas, Juray Tamás, ingyenes, ingyen, free, honlap, homepage, ottlap, internet, web, Internet, Web, WWW, webmester, webmaster, weblabor, webépítes, honlapszerkesztés, honlapépítés, honlaptervezés" 
name=Keywords><LINK href="Weblabor - JavaScript_elemei/main.css" rel=STYLESHEET 
type=text/css>
<SCRIPT language=JAVASCRIPT src="Weblabor - JavaScript_elemei/alldisp.js" 
type=TEXT/JAVASCRIPT></SCRIPT>

<SCRIPT language=JAVASCRIPT src="Weblabor - JavaScript_elemei/s_jstanf.js" 
type=TEXT/JAVASCRIPT></SCRIPT>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<SCRIPT language=JAVASCRIPT type=TEXT/JAVASCRIPT>
<!-- hide JavaScript code from old browsers
	display_menu();
// -->
</SCRIPT>
<NOSCRIPT>
<DIV align=center>[JavaScript kód]<BR><BR></DIV></NOSCRIPT>
<TABLE bgColor=#000000 border=0 cellPadding=1 cellSpacing=0 width="100%">
  <TBODY>
  <TR>
    <TD>
      <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
        <TBODY>
        <TR>
          <TD bgColor=#6699ff rowSpan=4 width=10><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=10></TD>
          <TD bgColor=#6699ff width=140><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=140></TD>
          <TD bgColor=#6699ff rowSpan=4 width=10><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=10></TD>
          <TD bgColor=#ffffff rowSpan=2 width=10><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=10></TD>
          <TD bgColor=#ffffff width="100%"><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=1></TD>
          <TD bgColor=#ffffff rowSpan=2 width=10><IMG alt="" height=1 
            src="Weblabor - JavaScript_elemei/co_blank.gif" width=10></TD></TR>
        <TR vAlign=top>
          <TD bgColor=#6699ff class=sidel width=140>
            <SCRIPT language=JAVASCRIPT type=TEXT/JAVASCRIPT>
<!-- hide JavaScript code from old browsers
	display_sidebar();
	display_onead("usual|js|webtech");
// -->
</SCRIPT>
            <NOSCRIPT>[JavaScript kód]</NOSCRIPT></TD>
          <TD bgColor=#ffffff class=wtext width="100%">
            <DIV class=blackmenu>Leírások+Referenciák / JavaScript / 
            Tartalomjegyzék</DIV><BR>
            <P>A következõ JavaScript leírás Juray Tamás munkája. Könnyen 
            megtanulhatóak belõle a JavaScript alapjai, és a haladóbb technikák 
            is. A haladást az oldalak alján található elõre és vissza utaló 
            linkek és a jobboldaldi tartalom segíti. Ezeket a fejezeteket a 
            szerzõ szívélyes beleegyezésével közöljük.<BR><BR>
            <TABLE align=center border=0 cellSpacing=0 CELLPAGGIND="0">
              <TBODY>
              <TR>
                <TD class=wtextl>
                  <P>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/eloszo.htm">Elõszó</A><BR><BR>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index01.htm">I. 
                  Bevezetés</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#javascript">Mi 
                    a JavaScript?</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#nemjava">A 
                    JavaScript nem Java!</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#futtatas">JavaScript 
                    futtatása</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#beagyazas">JavaScript 
                    beágyazása HTML dokumentumba</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#esemenyek">Események</A> 

                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index01.htm#fuggvenyek">Függvények</A> 
                    </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index02.htm">II. 
                  A HTML dokumentum</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index02.htm#felepitese">JavaScript 
                    felépítése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index02.htm#location">A 
                    location objektum</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index03.htm">III. 
                  Keretek</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index03.htm#keret_HTML">Keretek 
                    létrehozása HTML dokumentumban</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index03.htm#keret_javascript">Keretek 
                    kezelése JavaScript-ben</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index04.htm">IV. 
                  Ablakok</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index04.htm#letrehozas">Ablakok 
                    létrehozása</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index04.htm#bezaras">Ablakok 
                    bezárása</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index04.htm#onthefly">Dokumentumok 
                    készítése JavaScriptbõl</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index05.htm">V. 
                  Az állapotsor</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index05.htm#timeouts">A 
                    Timeout-ok (késleltetés)</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index05.htm#scroll">Egyszerû 
                    scroll JavaScriptben</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index06.htm">VI. 
                  A JavaScript objektumai</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index06.htm#Array">Array 
                    (tömb) objektum</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index06.htm#Date">A 
                    Date (dátum) objektum</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index06.htm#matematika">A 
                    Math (matematikai) objektum</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index06.htm#String">String 
                    objektum</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index07.htm">VII. 
                  Az ûrlapok</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index07.htm#ures">Üres 
                    mezõ ellenõrzése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index07.htm#Email">E-mail 
                    cím ellenõrzése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index07.htm#Numerikus">Numerikus 
                    értékek ellenõrzése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index07.htm#Fokusz">Fókusz 
                    állítása ûrlapmezõkre</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index07.htm#kuldes">Ûrlapok 
                    elküldése levélben</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index08.htm">VIII. 
                  A képek kezelése</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index08.htm#ujkepek">Új 
                    képek betöltése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index08.htm#betoltes">Képek 
                    elõre történõ betöltése</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index08.htm#esemeny">Felhasználói 
                    események által kiváltott képcserék</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index09.htm">IX. 
                  Layerek 1.</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index09.htm#letrehoz">Layerek 
                    létrehozása</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index09.htm#JSLAYER">A 
                    JavaScript és a layer-ek kapcsolata</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index09.htm#mozgo">Mozgó 
                    rétegek</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index10.htm">X. 
                  Layerek 2.</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index10.htm#vag">Vágás</A> 

                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index10.htm#nested">Egymásba 
                    ágyazott layerek</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index11.htm">XI. 
                  Cookiek (sütik)</A> 
                  <UL>
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index11.htm#szorit">Megszorítások</A> 

                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index11.htm#JSCOOKIE">A 
                    "sütik" és a JavaScript</A> 
                    <LI><A 
                    href="http://weblabor.externet.hu/leiras/javascr/index11.htm#pelda">Példa 
                    a "süti" használatára</A> </LI></UL>
                  <LI><A 
                  href="http://weblabor.externet.hu/leiras/javascr/befejez.htm">Befejezés</A></LI></TD></TR></TBODY></TABLE>
            <TABLE border=0 cellPadding=0 cellSpacing=0 width="100%">
              <TBODY>
              <TR>
                <TD class=wtextr>
                  <P><A 
                  href="http://weblabor.externet.hu/leiras/javascr/index01.htm">Tovább 
                  az elsõ fejezethez 
        &gt;&gt;</A></P></TD></TR></TBODY></TABLE></P></TD></TR>
        <TR>
          <TD bgColor=#6699ff class=sidebar vAlign=bottom width=140>
            <DIV align=center><A href="mailto:tjuray##kukac##bigfoot.com"><IMG border=0 
            src="Weblabor - JavaScript_elemei/juray.gif" vspace=2></A><BR><IMG 
            src="Weblabor - JavaScript_elemei/allow.gif"><BR><BR><A 
            href="http://weblabor.externet.hu/info/copyrig.htm">Copyright 
            Weblabor<BR>© 1999-2000 All Rights Reserved</A></DIV></TD>
          <TD bgColor=#ffffff class=blackmenu colSpan=3>
            <SCRIPT language=JAVASCRIPT type=TEXT/JAVASCRIPT>
<!-- hide JavaScript code from old browsers
	display_banners(100);
// -->
</SCRIPT>
            <NOSCRIPT>
            <DIV align=center>[JavaScript 
      kód]</DIV></NOSCRIPT></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></BODY></HTML>

31

Na visszanéztem, mégiscsak

inf · 2021. Feb. 19. (P), 10.28
Na visszanéztem, mégiscsak nekem van igazam, akkor már jó ideje volt JS, amikor megjelent a CSS. Abban igazad van, hogy nem volt még szabványosítva. link

Ilyesmi kódok voltak 2000 előtt, némi JS-el megtűzve tipikusan ellenőriztek, hogy IE vagy NS böngészőben fut e a kód, néha kiírták, hogy csak IE-re van optimalizálva az oldal meg ilyesmik. Olyat nem találtam most, amiben már JS is van, de még CSS nincsen. Inkább csak ilyen menü szín változtatások voltak mikor ráhúztad az egeret meg tényleg alap dolgok. Azért logikusan jött volna, hogyha amúgy is valamennyire a kinézetért és az animációkért a JS felel, akkor azzal csinálják meg a megjelenítést.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Apache Server Frequently Asked Questions</TITLE>
 </HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  TEXT="#000000"
  LINK="#0000FF"
  VLINK="#000080"
  ALINK="#FF0000"
 >
  <DIV ALIGN="CENTER">
 <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
 <H3>
  Apache HTTP Server Version 1.3
 </H3>
</DIV>

  <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
  <P>
  $Revision: 1.129 $ ($Date: 1998/09/17 14:14:52 $)
  </P>
  <P>
  The latest version of this FAQ is always available from the main
  Apache web site, at
  &lt;<A
       HREF="http://www.apache.org/docs/misc/FAQ.html"
       REL="Help"
      ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
  </P>
<!-- Notes about changes:                                           -->
<!--  - If adding a relative link to another part of the            -->
<!--    documentation, *do* include the ".html" portion.  There's a -->
<!--    good chance that the user will be reading the documentation -->
<!--    on his own system, which may not be configured for          -->
<!--    multiviews.                                                 -->
<!--  - When adding items, make sure they're put in the right place -->
<!--    - verify that the numbering matches up.                     -->
<!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
<!--    correctly in a reliable way when this is converted to text  -->
<!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
<!--    blocks inside a <P></P> instead.  This is necessary to get  -->
<!--    the horizontal and vertical indenting right.                -->
<!--  - Don't forget to include an HR tag after the last /P tag     -->
<!--    but before the /LI in an item.                              -->
  <P>
  If you are reading a text-only version of this FAQ, you may find numbers
  enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
  reference URLs to be found at the end of the document.  These references
  do not appear, and are not needed, for the hypertext version.
  </P>
  <H2>The Questions</H2>
<!-- Stuff to Add:                                                  -->
<!-- - can't bind to port 80                                        -->
<!--   - permission denied                                          -->
<!--   - address already in use                                     -->
<!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
<!--   treated as pw, not just ++1st to --2nd.                      -->
<!-- - SSL:                                                         -->
<!--   - Can I use Apache-SSL for free in Canada?                   -->
<!--   - Why can't I use Apache-SSL in the U.S.?                    -->
<!-- - How can I found out how many visitors my site gets?          -->
<!-- - How do I add a counter?                                      -->
<!-- - How do I configure Apache as a proxy?                        -->
<!-- - What browsers support HTTP/1.1?                              -->
<!-- - What's the point of vhosts-by-name is there aren't any       -->
<!--   HTTP/1.1 browsers?                                           -->
<!-- - Is there an Apache for W95/WNT?                              -->
<!-- - Why does Apache die when a vhost can't be DNS-resolved?      -->
<!-- - Why do I get "send lost connection" messages in my error     -->
<!--   log?                                                         -->
<!--   - specifically consider .pdf files which seem to cause this  -->
<!--     a lot when accessed via the plugin ... and also mention    -->
<!--     how range-requests can cause bytes served < file size      -->
<!-- - Why do directory indexes appear as garbage?  (A: -lucb)      -->
<!-- - How do I add a footer to all pages offered by my server?     -->
<!-- - Fix midi question; a bigger problem than midi vs. x-midi is  -->
<!--   the simple fact that older versions of Apache (and new ones  -->
<!--   that have been upgraded without upgrading the mime.types     -->
<!--   file) don't have the type listed at all.                     -->
<!-- - RewriteRule /~fraggle/* /cgi-bin/fraggle.pl does not work    -->
<!-- - how do I disable authentication for a subdirectory?          -->
<!--   (A: you can't but "satisfy any; allow from all" can be close -->
<!-- - '400 malformed request' on Win32 might mean stale proxy; see -->
<!--   PR #2300.                                                    -->
<UL>
 <LI><STRONG>Background</STRONG>
  <OL START=1>
   <LI><A HREF="#what">What is Apache?</A>
   </LI>
   <LI><A HREF="#why">Why was Apache created?</A>
   </LI>
   <LI><A HREF="#relate">How does The Apache Group's work relate to
    other servers?</A>
   </LI>
   <LI><A HREF="#name">Why the name &quot;Apache&quot;?</A>
   </LI>
   <LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A>
   </LI>
   <LI><A HREF="#tested">How thoroughly tested is Apache?</A>
   </LI>
   <LI><A HREF="#future">What are the future plans for Apache?</A>
   </LI>
   <LI><A HREF="#support">Whom do I contact for support?</A>
   </LI>
   <LI><A HREF="#more">Is there any more information on Apache?</A>
   </LI>
   <LI><A HREF="#where">Where can I get Apache?</A>
   </LI>
  </OL>
 </LI>
 <LI><STRONG>Technical Questions</STRONG>
  <OL START=11>
   <LI><A HREF="#what2do">&quot;Why can't I ...?  Why won't ...
        work?&quot;  What to do in case of problems</A>
   </LI>
   <LI><A HREF="#compatible">How compatible is Apache with my existing
        NCSA 1.3 setup?</A>
   </LI>
   <LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution
        in directories other than the ScriptAlias?</A>
   </LI>
   <LI><A HREF="#premature-script-headers">What does it mean when my
        CGIs fail with &quot;<SAMP>Premature end of script
        headers</SAMP>&quot;?</A>
   </LI>
   <LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
   </LI>
   <LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A>
   </LI>
   <LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A>
   </LI>
   <LI><A HREF="#ssi-part-iv">SSIs don't work for VirtualHosts and/or 
        user home directories</A>
   </LI>
   <LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>
   </LI>
   <LI><A HREF="#multiviews">What are &quot;multiviews&quot;?</A>
   </LI>
   <LI><A HREF="#fdlim">Why can't I run more than &lt;<EM>n</EM>&gt;
        virtual hosts?</A>
   </LI>
   <LI><A HREF="#freebsd-setsize">Can I increase <SAMP>FD_SETSIZE</SAMP>
        on FreeBSD?</A>
   </LI>
   <LI><A HREF="#POSTnotallowed">Why do I keep getting &quot;Method Not 
        Allowed&quot; for form POST requests?</A>
   </LI>
   <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
        for Web page authentication?</A>
   </LI>
   <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
        401</CODE> work?</A>
   </LI>
   <LI><A HREF="#errordocssi">How can I use <CODE>ErrorDocument</CODE>
        and SSI to simplify customized error messages?</A>
   </LI>
   <LI><A HREF="#setgid">Why do I get &quot;<SAMP>setgid: Invalid
        argument</SAMP>&quot; at startup?</A>
   </LI>
   <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
   </LI>
   <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
        <SAMP>mod_cookies</SAMP>?</A>
   </LI>
   <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
        when I request an URL from an Apache server?</A>
   </LI>
   <LI><A HREF="#putsupport">Why can't I publish to my Apache server
        using PUT on Netscape Gold and other programs?</A>
   </LI>
   <LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
        more?</A>
   </LI>
   <LI><A HREF="#nodelay">Why am I getting &quot;<SAMP>httpd: could not
        set socket option TCP_NODELAY</SAMP>&quot; in my error log?</A>
   </LI>
   <LI><A HREF="#peerreset">Why am I getting &quot;<SAMP>connection
        reset by peer</SAMP>&quot; in my error log?</A>
   </LI>
   <LI><A HREF="#nph-scripts">How can I get my script's output without
        Apache buffering it?  Why doesn't my server push work?</A>
   </LI>
   <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
        of &quot;<CODE>struct iovec</CODE>&quot; when compiling under Linux?</A>
   </LI>
   <LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core,
        but where's the dump file?</A>
   </LI>
   <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
        working correctly?</A>
   </LI>
   <LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
   </LI>
   <LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using
        HP's ANSI C compiler?</A>
   </LI>
   <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
        browser can play it?</A>
   </LI>
   <LI><A HREF="#cantbuild">Why won't Apache compile with my
        system's <SAMP>cc</SAMP>?</A>
   </LI>
   <LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A>
   </LI>
   <LI><A HREF="#bind8.1">Why do I get an error about an undefined
        reference to &quot;<SAMP>__inet_ntoa</SAMP>&quot; or other
        <SAMP>__inet_*</SAMP> symbols?</A>
   </LI>
   <LI><A HREF="#set-servername">Why does accessing directories only work
        when I include the trailing &quot;/&quot;
        (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>) but
        not when I omit it
        (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</A>
   </LI>
   <LI><A HREF="#user-authentication">How do I set up Apache to require
        a username and password to access certain documents?</A>
   </LI>
   <LI><A HREF="#remote-user-var">Why is the environment variable
        <SAMP>REMOTE_USER</SAMP> not set?</A>
   </LI>
   <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
        to certain documents only if a site is either a local site
        <EM>or</EM> the user supplies a password and username?</A>
   </LI>
   <LI><A HREF="#no-info-directives">Why doesn't mod_info list any
        directives?</A>
   </LI>
   <LI><A HREF="#linux-shmget">When I run it under Linux I get &quot;shmget:
        function not found&quot;, what should I do?</A>
   </LI>
   <LI><A HREF="#authauthoritative">Why does my authentication give
        me a server error?</A>
   </LI>
   <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
        authentication information on the same machine?</A>
   </LI>
   <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
   </LI>
   <LI><A HREF="#rewrite-more-config">Where can I find mod_rewrite rulesets
        which already solve particular URL-related problems?</A>
   </LI>
   <LI><A HREF="#rewrite-article">Where can I find any published information
        about URL-manipulations and mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-complexity">Why is mod_rewrite so difficult to learn
        and seems so complicated?</A>
   </LI>
   <LI><A HREF="#rewrite-dontwork">What can I do if my RewriteRules don't work
        as expected?</A>
   </LI>
   <LI><A HREF="#rewrite-prefixdocroot">Why don't some of my URLs get
        prefixed with DocumentRoot when using mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-nocase">How can I make all my URLs case-insensitive
        with mod_rewrite?</A>
   </LI>
   <LI><A HREF="#rewrite-virthost">Why are RewriteRules in my VirtualHost
        parts ignored?</A>
   </LI>
   <LI><A HREF="#rewrite-envwhitespace">How can I use strings with whitespaces
        in RewriteRule's ENV flag?</A>
   </LI>
   <LI><A HREF="#cgi-spec">Where can I find the &quot;CGI
        specification&quot;?</A>
   </LI>
   <LI><A HREF="#year2000">Is Apache Year 2000 compliant?</A>
   </LI>
   <LI><A HREF="#namevhost">I upgraded to Apache 1.3 and now my
        virtual hosts don't work!</A>
   </LI>
   <LI><A HREF="#redhat">I'm using RedHat Linux and I have problems with httpd
        dying randomly or not restarting properly</A>
   </LI>
   <LI><A HREF="#stopping">I upgraded from an Apache version earlier
        than 1.2.0 and suddenly I have problems with Apache dying randomly
        or not restarting properly</A>
   </LI>
   <LI><A HREF="#redhat-htm">I'm using RedHat Linux and my .htm files are
        showing up as HTML source rather than being formatted!</A>
   </LI>
   <LI><A HREF="#glibc-crypt">I'm using RedHat Linux 5.0, or some other
        <SAMP>glibc</SAMP>-based Linux system, and I get errors with the
        <CODE>crypt</CODE> function when I attempt to build Apache 1.2.</A>
   </LI>
   <LI><A HREF="#nfslocking">Server hangs, or fails to start, and/or error log
        fills with &quot;<SAMP>fcntl: F_SETLKW: No record locks
        available</SAMP>&quot; or similar messages</A>
   </LI>
   <LI><A HREF="#zoom">What's the best hardware/operating system/... How do
        I get the most out of my Apache Web server?</A>
   </LI>
   <LI><A HREF="#regex">What are "regular expressions"?</A>
   </LI>
   <LI><A HREF="#broken-gcc">I'm using gcc and I get some compilation errors, 
	what is wrong?</A>
   </LI>
   <LI><A HREF="#htaccess-work">My <CODE>.htaccess</CODE> files are being
	ignored.</A>
   </LI>
   <LI><A HREF="#submit_patch">How do I submit a patch to the Apache Group?</A>
   </LI>
  </OL>
 </LI>
</UL>

<HR>

  <H2>The Answers</H2>
  <H3>
   Background
  </H3>
<OL START=1>
 <LI><A NAME="what">
      <STRONG>What is Apache?</STRONG>
     </A>
  <P>
  Apache was originally based on code and ideas found in the most
  popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
  since evolved into a far superior system which can rival (and probably
  surpass) almost any other UNIX based HTTP server in terms of functionality,
  efficiency and speed.
  </P>
  <P>
  Since it began, it has been completely rewritten, and includes many new
  features. Apache is, as of January 1997, the most popular WWW server on
  the Internet, according to the
  <A HREF="http://www.netcraft.com/Survey/">Netcraft Survey</A>.
  </P>
  <HR>
 </LI>

 <LI><A NAME="why">
      <STRONG>Why was Apache created?</STRONG>
     </A>
  <P>
  To address the concerns of a group of WWW providers and part-time httpd
  programmers that httpd didn't behave as they wanted it to behave.
  Apache is an entirely volunteer effort, completely funded by its
  members, not by commercial sales.
  </P>
  <HR>
 </LI>

 <LI><A NAME="relate">
      <STRONG>How does The Apache Group's work relate to other
      server efforts, such as NCSA's?</STRONG>
     </A>
  <P>
  We, of course, owe a great debt to NCSA and their programmers for
  making the server Apache was based on. We now, however, have our own
  server, and our project is mostly our own. The Apache Project is an
  entirely independent venture.
  </P>
  <HR>
 </LI>

 <LI><A NAME="name">
      <STRONG>Why the name &quot;Apache&quot;?</STRONG>
      </A>
  <P>
  A cute name which stuck. Apache is &quot;<STRONG>A
  PA</STRONG>t<STRONG>CH</STRONG>y server&quot;.  It was
  based on some existing code and a series of &quot;patch files&quot;.
  </P>
  <HR>
 </LI>

 <LI><A NAME="compare">
      <STRONG>OK, so how does Apache compare to other servers?</STRONG>
     </A>
  <P>
  For an independent assessment, see
  <A HREF="http://webcompare.internet.com/chart.html">Web Compare</A>'s
  comparison chart.
  </P>
  <P>
  Apache has been shown to be substantially faster than many other
  free servers. Although certain commercial servers have claimed to
  surpass Apache's speed (it has not been demonstrated that any of these
  &quot;benchmarks&quot; are a good way of measuring WWW server speed at any
  rate), we feel that it is better to have a mostly-fast free server
  than an extremely-fast server that costs thousands of dollars. Apache
  is run on sites that get millions of hits per day, and they have
  experienced no performance difficulties.
  </P>
  <HR>
 </LI>

 <LI><A NAME="tested">
      <STRONG>How thoroughly tested is Apache?</STRONG>
     </A>
  <P>
  Apache is run on over 1.2 million Internet servers (as of July 1998). It has
  been tested thoroughly by both developers and users. The Apache Group
  maintains rigorous standards before releasing new versions of their
  server, and our server runs without a hitch on over one half of all
  WWW servers available on the Internet.  When bugs do show up, we
  release patches and new versions as soon as they are available.
  </P>
  <P>
  The Apache project's web site includes a page with a partial list of
  <A HREF="http://www.apache.org/info/apache_users.html">sites running
  Apache</A>.
  </P>
  <HR>
 </LI>

 <LI><A NAME="future">
      <STRONG>What are the future plans for Apache?</STRONG>
     </A>
  <P>
  <UL>
   <LI>to continue to be an "open source" no-charge-for-use HTTP server,
   </LI>
   <LI>to keep up with advances in HTTP protocol and web developments in
    general,
   </LI>
   <LI>to collect suggestions for fixes/improvements from its users,
   </LI>
   <LI>to respond to needs of large volume providers as well as
    occasional users.
   </LI>
  </UL>
  <P></P>
  <HR>
 </LI>

 <LI><A NAME="support">
      <STRONG>Whom do I contact for support?</STRONG>
     </A>
  <P>
  There is no official support for Apache. None of the developers want to
  be swamped by a flood of trivial questions that can be resolved elsewhere.
  Bug reports and suggestions should be sent <EM>via</EM>
  <A HREF="http://www.apache.org/bug_report.html">the bug report page</A>.
  Other questions should be directed to the
  <A HREF="news:comp.infosystems.www.servers.unix"
  >comp.infosystems.www.servers.unix</A> or <A HREF=
  "news:comp.infosystems.www.servers.ms-windows"
  >comp.infosystems.www.servers.ms-windows</A>
  newsgroup (as appropriate for the platform you use), where some of the 
  Apache team lurk, in the company of many other httpd gurus who 
  should be able to help.
  </P>
  <P>
  Commercial support for Apache is, however, available from a number
  of third parties.
  </P>
  <HR>
 </LI>

 <LI><A NAME="more">
      <STRONG>Is there any more information available on
      Apache?</STRONG>
     </A>
  <P>
  Indeed there is.  See the main
  <A HREF="http://www.apache.org/">Apache web site</A>.
  There is also a regular electronic publication called
  <A HREF="http://www.apacheweek.com/" REL="Help"><CITE>Apache Week</CITE></A>
  available.  Links to relevant <CITE>Apache Week</CITE> articles are
  included below where appropriate. There are also some 
  <A HREF="http://www.apache.org/info/apache_books.html"
  >Apache-specific books</A> available.
  </P>
  <HR>
 </LI>

 <LI><A NAME="where">
      <STRONG>Where can I get Apache?</STRONG>
     </A>
  <P>
  You can find out how to download the source for Apache at the
  project's
  <A HREF="http://www.apache.org/">main web page</A>.
  </P>
  <HR>
 </LI>
</OL>
  <H3>Technical Questions</H3>
  
  ..............

<H3 ALIGN="CENTER">
 Apache HTTP Server Version 1.3
</H3>

<A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
<A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>

</BODY>
</HTML>


Nem tudom miért gondolod, hogy nekem kimaradt volna, vagy nincs elég jó szinten a CSS. Jó mondjuk a flexbox és az újabb dolgok tényleg kimaradtak, mert egy ideje nem érdekel annyira a kliens oldal, de azért egy 10-15 évig követtem a fejlődését.
37

Bocsi, de

Pepita · 2021. Feb. 23. (K), 14.17
akár hányezer sornyi innen-onnan, de böngészővel lementett HTML kódot mutatsz (ne felejtsük el, hogy az nem pontosan a forrása), még nem lesz igaztalan, amit a wikipediáról idéztem. ;)

valamennyire a kinézetért és az animációkért a JS felel
Ez még mindig tévedés. Bár ma már nem divat arra készülni, hogy kikapcsolja a user a js-t, de talán erről az oldalról a legkönnyebb megérteni.

Mi történik akkor, amikor js-el "animálsz"?
1. betöltődik a html
2. betöltődnek (jó esetben aszinkron) a hozzá tartozó css és js fájlok, valamint képek, egyéb statikus tartalmak.
3. a böngésző rendereli az oldalt (kvázi "lefordítja" a html-t + css-t + megjeleníti a képeket) - ez egy szál
4. elindul a js animációd (új szál, ráadásul interpreteres nyelv)
5. Hopp, megváltozott a DOM, SOS renderelni kell! - veszi észre az első szál.
6. újrarenderel (első)
7. közben tovább futott a második is, és jön a következő módosítás (pl csak inline style-ban egy width értéket változtatunk adott sebességgel)
8. Úristen már megint! - mondja az első szál
És ez így megy, mondjuk 3 sec alatt 60-szor, mire sikerült "leanimálni", hogy a user valami fölé vitte az egeret...

Mi van, ha css-el animálod ugyanezt?
A 3. pont annyiban változik, hogy a zárójeles rész kicsit kibővül. A css "fordítása" közben - mivel hover volt az esemény - már "ráakasztja" a célzott elemekre az eseménykezelőt (core szinten, nem egy interpreteres nyelven), plusz előre kiszámolja az animációhoz szükséges matekot.
Amikor "jön a hover", már semmit nem kell matekolni (pláne nem neked js-ből), és gyönyörűen megjeleníti amit kell, nem "akad" és nincs se "hopp", se "Úristen".

Nos ezért a css-ben a helye a megjelenítésnek.

Jó mondjuk a flexbox és az újabb dolgok tényleg kimaradtak
Nos pont a fenti (egyébként korántsem teljes) összehasonlítás miatt érdemes szinten tartani.
39

akár hányezer sornyi

inf · 2021. Feb. 23. (K), 18.34
akár hányezer sornyi innen-onnan, de böngészővel lementett HTML kódot mutatsz (ne felejtsük el, hogy az nem pontosan a forrása)

Nyilván a szerver oldali kód nincs benne, de annak idején 2000-ben ezt adta vissza az oldal.

valamennyire a kinézetért és az animációkért a JS felel

Ez nagyon jó példája, hogy miért nem érdemes kiragadni a kontextusból mondatokat és átértelmezni. Az IE és Netscape időkben 25 éve a JS-t használták arra, amire most a CSS-t, pl :hover helyett onmouseover-el oldották meg. Annyit kellett volna tenni, hogy betesznek egy style API-t, amit JS kóddal megváltoztathatunk az oldal betöltődése közben, és ugyanazt csinálja, mint a CSS. Az újra renderelés problémája ezzel meg lenne oldva. Plusz nem lenne az, ami most van, hogy a CSS-be megpróbálnak minél több okosságot beletákolni.
32

Ha a CSS a JS része lenne, és

Endyl · 2021. Feb. 19. (P), 11.18
Ha a CSS a JS része lenne, és ugyanazt a hatékonyságot akarnánk elérni, ugyanúgy meg kéne érteni a CSS-re jellemző koncepciókat (lépcsőzetesség, öröklődés, elsőbbségi szabályok, doboz modell, stb). Ugyanígy ma is lehet teljes stíluslapokat gyártani JS-ből, megvan hozzá az API, de ha nem tanulod meg, hogy hogyan működik a mögöttes layout engine (ami gondolom már a CSS bárminemű megejelése előtt is ott volt, már az első grafikus megjelenítésnél, és a CSS csak egy API-t biztosít a befolyásolására), ugyanolyan nehéz lesz gyors, hozzáférhető, hatékony megjelenést csinálni.

Továbbá ha a CSS a JS része lenne, akkor cserébe azt keresgélhetnéd, hogy melyik JS fájlban van megadva a megjelenés :) Így legalább tudod, hogy CSS fájlban kell keresgélni. Persze lehetnek kivételek, amikor a teljesítmény nevében inline-olni kell néhány szabályt, vagy valami nagyon egzotikus megjelenéshez JS-ből kell hozzányúlni a megjelenéshez, de az esetek túlnyomó többségében nagyon is könnyen kideríthető, hogy honnan jön a stílusszabály.
33

Nem ez a lényeg, hanem hogy

inf · 2021. Feb. 19. (P), 11.43
Nem ez a lényeg, hanem hogy teljesen feleslegesen létrehoztak egy új nyelvet, amikor volt már egy létező, ami előtte kötődött valamennyire a megjelenítéshez. Simán kellett volna egy style API-t csinálni JS-ben, aztán ugyanazt lekódolni hozzá ahelyett, hogy egy külön nyelvet csinálnak. Szerintem. Úgy cirka egy évtizeddel vetette vissza mindez a JS fejlődését, jöttek a jquery és társai, aztán annak hatására végül mégis megcsinálták a query selector-t. Mondjuk amit Pepita ír az nem annyira hülyeség olyan szempontból, hogy talán akkor még nem volt egyértelmű, hogy a JS egyáltalán túl fog e élni, vagy Java applet lesz az alkalmazásokhoz és HTML némi formázással a dokumentumokhoz.
34

Továbbra sem értem, hogy

Endyl · 2021. Feb. 19. (P), 15.02
Továbbra sem értem, hogy miért baj, hogy egy jól behatárolt feladatra létrehoztak egy céleszközt.

Kicsit olyan érzésem van ettől, mintha azon vitáznánk, hogy pl. az assembly után miért volt szükség más nyelvre, amikor az már ott volt és kötődött a géppel való kommunikációhoz.
35

Én feleslegesnek éreztem,

inf · 2021. Feb. 19. (P), 15.15
Én feleslegesnek éreztem, ennyi. Lehet más a véleményed.
38

+1

Pepita · 2021. Feb. 23. (K), 14.23
pl. az assembly után miért volt szükség más nyelvre
Ez a mondat nagyon ott van! :)
Pedig előtte is ott volt a gépi kód!
(És bibibííí, nekem még van egy kis halvány emlékem Commodore-16 Assembly-ről, utána a .386 valós mód is már a kánaán volt! :-D )
40

Ha már visszatértünk ehhez

inf · 2021. Feb. 23. (K), 20.15
Ha már visszatértünk ehhez is. Az assembly-nél magasabb szintű nyelveket hoztak létre, az assemblyt pedig meghagyták a maga szintjén.

A CSS ezzel szemben a JS-hez képest nem nyújt semmi extrát, sőt visszalépés hozzá képest. Persze elhiszem, hogy egyszerűbb volt gyorsan tákolni rá egy DSL-t, mint elgondolkodni, hogy esetleg fejleszthetnék a meglévő eszközöket.

Mondjuk itt van ez, ami gondolom a CSS 1.0-val is működik.

body {
    font-family: Tahoma, Geneva, sans-serif;
    font-size: 0.9em;
    line-height: 1.45em;
}
Meg lehetett volna oldani akár így is már akkor szinte azonos renderelési sebességgel:

var text = new style.Text();
text.font = fonts.Tahoma || fonts.Geneva || fonts.SansSerif;
text.unit = style.units.em;
text.size = 0.9;
text.line.size = text.size + 0.55;
text.color = colors.black;

var box = new style.Box();
box.background = colors.white;

if (browser.settings.shortSighted){
    text.size = 2;
    text.line.size = text.size + 0.55;
}

if (browser.time.isNight) {
    text.color = colors.white;
    box.background = colors.black;
}

document.setStyle("body", box, text);
Nyilván hosszabb, mint a CSS, de megvan az az előnye, hogy programozható. 25 éve ugyanezt full esélytelen volt megoldani csak CSS-el, JS-el meg pillanatok alatt össze lehetett volna szórni tök egyszerűen. Ahogy nézem CSS3-ra lettek függvények és változók, úgyhogy talán már lehetne valami ilyesmit, de még most sem hiszem, hogy tisztán CSS-el kliens időből megoldható a nappal és éjszaka megállapítása, azt az infot, hogy valakinek jó lenne nagyítani a betű méreten meg továbbra sem adja át a böngésző. Fantasztikus fejlődés...

Engem ez az egész sokkal inkább arra emlékeztet, hogy létrehoznak n+1 sablonnyelvet szerver oldalon, aztán a 10.0 verzióra, amikor már 1000 featuret és függvényt hozzáadtak, mindig rájönnek, hogy mégiscsak ugyanazt kéne tudnia, mint az eredeti nyelvnek, amin létrehozták.
41

Én nem tartom visszalépésnek

Endyl · 2021. Feb. 23. (K), 21.44
Én nem tartom visszalépésnek a sokszorosan gyorsabb és simább megjelenést és tömörebb, deklaratív szintaxist. Azt sem látom előnynek, hogy sokmegás szkriptek parszolására és futtatására kelljen várni ahhoz, hogy megjelenjen az oldal.

Egy jól megírt CSS-sel plusz sorok/logika nélkül támogatod a változtatható betűméretet reszponzív módon. A felhasználó ezt be tudja állítani magának a böngészőben, és nem azt kell használnia, amit te JS-ben megadsz.

Ha időtől függően azt akarod, hogy máshogy nézzen ki, akkor hozzáadsz egy osztályt a html elemhez és kész. A logika marad a JS-ben, a dokumentumtól függő megjelenés meg a CSS-ben.

Én továbbra is csak előnyöket látok.
42

Nyilván nem fogok fél óra

inf · 2021. Feb. 24. (Sze), 10.57
Nyilván nem fogok fél óra alatt összeszórni neked egy W3C szabványt, ami a CSS minden előnyével rendelkezik. Viszont ha ennyire nem tudsz elvonatkoztatni a mostani állapotoktól, akkor nincs értelme ezt a szálat folytatni.

Én nem tartom visszalépésnek a sokszorosan gyorsabb és simább megjelenést és tömörebb, deklaratív szintaxist. Azt sem látom előnynek, hogy sokmegás szkriptek parszolására és futtatására kelljen várni ahhoz, hogy megjelenjen az oldal.

Senki nem kötelez rá, hogy mindent egybe csomagolj. A stílust tartalmazó JS fájloknál ugyanúgy lehetne jelezni a böngészőnek egy link rel-el, vagy egy attribútummal, hogy dolgozza fel mielőtt áttér a maradékra, mert kell a rendereléshez, esetleg betehetünk defert a maradékra. Ha konfig fájl jellegű szintaxist akarsz, akkor meg JSON-ban vagy ahhoz hasonló formátumban meg lehetett volna adni, aminek a feldolgozása a CSS-el azonos sebességgel megoldható.

Egy jól megírt CSS-sel plusz sorok/logika nélkül támogatod a változtatható betűméretet reszponzív módon. A felhasználó ezt be tudja állítani magának a böngészőben, és nem azt kell használnia, amit te JS-ben megadsz.

Ezzel el is veszik egyúttal a lehetőséget azoktól, akik bármilyen okból nem akarnak reszponzív oldalt csinálni csak mondjuk támogatni egy alap és egy nagybetűs kinézetet valami vállalható formában. A reszponzívval kapcsolatban valószínűleg sokkal jobban megoldható lehet egy normális programnyelven, ahhoz képest, ami most CSS-ben van, de nem vagyok benne biztos.

Ha időtől függően azt akarod, hogy máshogy nézzen ki, akkor hozzáadsz egy osztályt a html elemhez és kész. A logika marad a JS-ben, a dokumentumtól függő megjelenés meg a CSS-ben.

Ja hát igen, pont erről beszéltem, hogyha már minimális logikát akarsz belevinni a kinézetbe, akkor nyúlhatsz a JS-hez, aztán kommunikálhatod tovább a CSS felé amennyire ez lehetséges a DOM betöltése előtt. Eleve a CSS bizonyította, hogy a JS DOM megléte egyáltalán nem szükséges a stílus változtatásához, elég ha megadunk egy szabályt, hogy ami megfelel egy query-nek, arra a következő stílus vonatkozik, aztán majd a renderelő alkalmazza a szabályt, ha illik valamire a query, amit éppen ki akar rajzolni. A DOM csak arra kell, hogy bejárhassuk a HTML csomópontok fáját, és hozzáadjunk vagy elvegyünk valamit. Jelenleg ha kommunikálni akarunk a JS és CSS között mielőtt a teljes DOM-ot betöltené a böngésző, akkor kénytelenek vagyunk egy félkész DOM-ot módosítani hozzá ahelyett, hogy csak hozzáadnánk egy szabályt.

// ezek mennek
document.documentElement.setAttribute("class", "night");
document.styleSheets[0].insertRule("body {background-color: black; color: white}", 1);
// ez már elhasal, mert még nincs body
document.getElementsByTagName("body")[0].setAttribute("class", "night");
Sokkal egyszerűbb és következetesebb lenne, ha egyáltalán nem engednénk hozzáférést a DOM fához ameddig nincs teljesen felépítve, és csak szabályokat fogalmaznánk meg rá.

document.style.addRule("body", {
    backgroundColor: "black",
    color: "white"
});
Ugyanezt akár lehetne így is:

document.querySelector("body").addRule("style", {
    backgroundColor: "black",
    color: "white"
});
Ilyen téren akár tovább is lehet menni, és eseménykezelőket is hozzá lehetne csapni, amit később minden csomópontra alkalmaz a JS, amire teljesül a query.

document.querySelector("body").addRule("event:load", function (event){
    event.target.setAttribute("class", "night");
});
43

Sokkal egyszerűbb és

Endyl · 2021. Feb. 24. (Sze), 12.30
Sokkal egyszerűbb és következetesebb lenne, ha egyáltalán nem engednénk hozzáférést a DOM fához ameddig nincs teljesen felépítve, és csak szabályokat fogalmaznánk meg rá.

Pont ez a gond. A JS-nek az a dolga, hogy módosítsa a dokumentumot. Így ha betöltés közben talál a böngésző egy normál script elemet, akkor a megjelenítést meg kell állítania, (adott esetben) letöltenie a kódot, értelmeznie és futtatnia, és utána tudja tovább építeni a dokumentumot. És ezt a viselkedést nem lehet csak úgy eldobni, mert sok régi oldal lehet, hogy nem működne ezek után. Tehát hiába akarunk elvonatkoztatni a jelenlegi (és az akkori helyzettől), csak bizonyos keretek között lehet ezt megtenni úgy, hogy a meglévő infrastruktúra is működőképes maradjon.

Nem kétlem, hogy lehet olyan (kitchen sink) nyelvet írni nulláról, ami mindent is meg tud csinálni optimálisan, de a komplexitása könnyen lehet, hogy akkora lenne, hogy az egyes feladatokra optimalizált API-jai annyira más gondolkodást és szintaxist igényelnének, hogy praktikusak legyenek, hogy akár külön nyelvek is lehetnének. Főleg ha elkezded "külön csomagolni" ezeket a részeket a hatékonyság kedvéért.

Ezzel el is veszik egyúttal a lehetőséget azoktól, akik bármilyen okból nem akarnak reszponzív oldalt csinálni csak mondjuk támogatni egy alap és egy nagybetűs kinézetet valami vállalható formában. A reszponzívval kapcsolatban valószínűleg sokkal jobban megoldható lehet egy normális programnyelven, ahhoz képest, ami most CSS-ben van, de nem vagyok benne biztos.

A HTML alapból reszponzív. Ha megtanul az ember CSS-ül, akkor nem kerül plusz erőfeszítésbe reszponzív módon megírni egy oldal megjelenését ahhoz képest, mint ami egy nem reszponzív oldalhoz kell. Szóval ezzel azt mondod, hogy elveszik azt a lehetőséget az embertől, hogy olyanra csinálja meg az oldalát, amit kevesebb eszközzel vagy kevesebb különböző adottságokkal rendelkező ember tudja használni. De ugyebár ez a lehetősége nincs elvéve. Kedvedre csinálhatsz olyan gyatra reszponzivitású és hozzáférhetőségű oldalt, amilyet csak szeretnél (ld. ma létező weboldalak). Milyen jók is voltak az "ez az oldal csak az IE6-ot támogatja 1024×768 felbontásban" idők :)

Nyilván nem fogok fél óra alatt összeszórni neked egy W3C szabványt, ami a CSS minden előnyével rendelkezik.

Nyilván. És senki más sem. Ehhez idő kell. De közben azt is szeretnénk, hogy fejlődjön a web. Ezért a problémát partícionálni kell, hogy a logikusan összetartozó dolgokat praktikusan lehessen megoldani. És ebből a folyamatból született meg a CSS. Volt egy adott helyzet, amiben különböző problémákra megoldásokat kellett találni jobbára visszafelé kompatibilis módon.
44

Pont ez a gond. A JS-nek az a

inf · 2021. Feb. 24. (Sze), 14.34
Pont ez a gond. A JS-nek az a dolga, hogy módosítsa a dokumentumot.


Ja és ezt ki döntötte el és mikor? Mert simán hozzá lehetett volna csapni a stíluslapokat is JS-hez mielőtt valakinek jött az a világmegváltó ötlete a W3C-nél, hogy kitalál rá egy harmadik nyelvet.

Meg lehetne csinálni ma is visszafele kompatibilisen, viszont kapásból jönne az, hogy nincs semmi értelme, mert működnek CSS-el is az alap dolgok, a maradékhoz meg hozzátákolunk egy kis JS-t, aztán kész. A CSS kivezetése meg szintén baromi megterhelő lenne mindenkinek. Ezt akkor cseszték el javíthatatlanul, amikor fel se tették a kérdést, hogy milyen létező eszközöket lehetne erre a célra használni.
45

Ja és ezt ki döntötte el és

Endyl · 2021. Feb. 24. (Sze), 16.31
Ja és ezt ki döntötte el és mikor? Mert simán hozzá lehetett volna csapni a stíluslapokat is JS-hez mielőtt valakinek jött az a világmegváltó ötlete a W3C-nél, hogy kitalál rá egy harmadik nyelvet.


Eleve azért hozták létre a JS-t, hogy letöltődés után meg lehessen változtatni a dokumentumokat, és ne csak statikus oldalak legyenek. Szóval ezt még a Mosaic/Netscape-nél döntötték el.

De igazad van, azzal nem tudok mit kezdeni, hogy neked antipatikus valamiért a CSS. Mindez annak ellenére, hogy belátható, hogy a hatékony layout kezelést nem szerencsés összekeverni dokumentum módosításokkal, hogy érdemes külön kezelni a megjelenésért felelős kódot az egyéb logikától, stb.

A korábbi kódrészletekből azt gondolom, hogy ismered a CSSOM-ot. Ezt használva bárki, aki rendesen ért a CSS-hez, talán csinálhatna egy nem túl borzasztó JS alapú stílus APIt. De egyrészt aki kellően magabiztos CSS tudással rendelkezik, az valószínűleg nem fog egy nyakatekertebb megoldást használni, másrészt meg ugye ennek a hatékony használatához továbbra is érteni kéne, hogy a böngészők hogyan végzik a megjelenítést, ami független attól, hogy milyen nyelven van az APIja.

Ahogy már az elején is írtam, szerintem nem a nyelvvel van a baj, hanem hogy az emberek csak felszínesen hajlandóak megérteni egy weboldal renderelésének a folyamatát és mechanizmusait. Úgy meg nehéz lesz bármilyen nyelven jó megjelenést írni. Ha JS-ben menne a stílusolás, akkor szerintem a JS stílus APIval kapcsolatban menne az, ami most a CSS-re irányul, és lenne ugyanennyi elfuserált, lebutított wrapper körülötte ahelyett, hogy rávennék az embereket, hogy megtanulják használni. Ehhez a megértéshez meg hozzátartozna a másik nagy probléma, hogy egy weboldal megjelenésének mikéntjét nem tudjuk befolyásolni úgy, mint egy nyomtatott kiadványnál. Tehát aki szembemegy a reszponzivitással, az számítson a masszív szenvedésre, ami emiatt vár rá.
46

Pontatlanul fogalmaztam, úgy

inf · 2021. Feb. 24. (Sze), 19.41
Pontatlanul fogalmaztam, úgy értettem, hogy ki döntötte el, hogy csak erre lehet használni. A lényegen mondjuk már nem változtat. A maradékkal egyetértek, hogy rendesen meg kell tanulni a már létező eszközöket, ha már csak az jutott.
24

modern web

Pepita · 2021. Feb. 17. (Sze), 09.53
a HTML5-tel és a modern webnek csúfolt valamivel csak egy seggel próbálunk meg két lovat megülni
Megülni meg lehet vele akár 100 lovat is, a lényeg, hogy ezt kellően tudjuk szétválasztani, ne mind a 100 legyen egy oldalon.

Egyébként a "modern webnek" lassan el kell(ene) indulnia egy, a mostanihoz képest nagyon más irányba. Elértük órajelben, RAM-ban, háttértárban és hálózatban nagyjából a maximum sebességet, "darabszámot" még tudunk növelni, cluster-t építeni, de minek?
Minél nagyobb sávszélességet tudok adni pl mobilon, annál olcsóbban kell adnom az egységnyi adatot, közben nekem, a szolgáltatónak egyre drágább a több eszköz és nagyobb üzemeltetési költség miatt.
Kinek jó ez? Senkinek. A kliens(ek) számára sem, mert ugyan nagyobb adatforgalmat kap ugyanannyiért, de semmivel se több hasznos tartalmat, és még a teló is hamarabb lemerül...
Emellett nincs igazán helye további "technológiáknak", amik még több sávszélt + procit + memóriát igényelnek, csak azért, hogy a "fejlesztők" gyorsabban, kevesebb munkával tudjanak haszontalan tartalmat gyártani...

Az irány inkább az lesz, hogy hogyan tudjuk az energiafogyasztást csökkenteni, értékes tartalom mellett. (Nem, attól nem fogják jobban megvenni a gumilabdát, hogy a pontos leírás helyett egy autostart fullhd videón van egy labdázó kisgyerek.)

Ha már annyira technológia: üzemeltetési oldalon van pár (viszonylag) újdonság a sebesség növelésére, adatforgalom csökkentésére.
11

Hajrá

Pepita · 2021. Feb. 15. (H), 13.28
A Bootstrap-ot is néztem, de az túl összetett, meg kéne az egészet érteni
Meg kéne bizony.
Igen, összetett. Annyiból kötöttséget is jelent, hogy kénytelen leszel azt az "építési struktúrát" követni, amire ki van találva.
Összességében ezek nem rossz dolgok, sőt, sokat lehet tanulni is belőle.
Más is írta: nem mellékesen produktívabb is, mint 0-ról egyedül.
(Egyébként a Drupal Zen téma nem hsználja véletlenül? :) )
36

A Zen Zent használ.

Atomi · 2021. Feb. 21. (V), 17.49
A Zen Zent használ.
47

Ontopic

Endyl · 2021. Feb. 25. (Cs), 12.58
A checkbox és radio elemek elég jól stílusolhatóak a :checked pszeudo-osztály segítségével.

A select szintén tűrhetően alakítható, ha csak az elemet nézzük. A legördülő rész macerás tud lenni, és OS függő.

A file elemhez meg létezik a ::file-selector-button / ::-webkit-file-upload-button pszeudo-elem. Esetleg akár egy labelbe csomagolva és elrejtve lényegében tetszőleges megjelenést tudsz neki adni.

Bizonyos esetekben érdemes lehet megpróbálni egy appearance: none; szabályt.