Custom CSS snippets

[crisp]

NMe schreef op maandag 6 mei 2019 @ 17:45:
[...]

Wat betreft het laatste puntje: hoe wil je populariteit meten? Ik zou willen voorstellen om dat te doen op basis van het aantal mensen dat nú de snippet gebruikt, hoe meer mensen dat zijn hoe hoger de score. De andere optie is om het met duimpjes te doen of iets dergelijks, maar die worden niet automatisch teruggetrokken op het moment dat mensen stoppen met het gebruiken van die specifieke snippet, dus dat maakt het lastiger om nieuwe snippets op de kaart te zetten.

Daar moeten we nog verder over nadenken. Ratings of duimpjes staan ook op de radar, maar zijn vooralsnog een 'nice to have'.

Juup schreef op maandag 6 mei 2019 @ 18:12:
Let op dat je met CSS wachtwoorden kan stelen en andere rare fratsen:
https://github.com/jbtronics/CrookedStyleSheets

Er zal inderdaad iets van sanitizing gedaan worden om te voorkomen dat o.a. resources van externe (niet-vertrouwde) bronnen geinclude kunnen worden.

Mogen de snippets gebruikt worden om reclame te hiden?

Dat lijkt me niet...

[NMe]

crisp schreef op maandag 6 mei 2019 @ 18:55:
[...]

Daar moeten we nog verder over nadenken. Ratings of duimpjes staan ook op de radar, maar zijn vooralsnog een 'nice to have'.

Populariteit op basis van het aantal gebruikers dat 't daadwerkelijk gebruikt lijkt me makkelijker te bouwen en zoals gezegd effectiever. Duimpjes toevoegen kan ook best maar ik zou die niet gebruiken voor de populariteitssortering.

Ik kan niet helemaal uit je bericht opmaken of dat sorteren op populariteit nou ook een "nice to have" is maar het lijkt me dat de feature bijna niet zinnig te gebruiken is zonder die sortering.

Juup schreef op maandag 6 mei 2019 @ 18:12:
Let op dat je met CSS wachtwoorden kan stelen en andere rare fratsen:
https://github.com/jbtronics/CrookedStyleSheets

Ik zou eerder deze als voorbeeld gebruiken voor waarom er een filter nodig is. https://github.com/maxchehab/CSS-Keylogging

[Zeror]

ikloon schreef op maandag 6 mei 2019 @ 17:05:
Dus even opgesomd waar we aan denken:

• Iedereen met custom CSS kan CSS snippets aanmaken, gebruiken en onderhouden
• Snippets kunnen worden gedeeld
• Je kunt zoeken naar snippets van andere gebruikers en deze zelf ook gebruiken
• Je kunt de maker van de snippet voorstellen doen ter verbetering
• Het gebruik van de snippets wordt bijgehouden en is zichtbaar (populariteit)

En is dan 1 persoon eigenaar van zo'n snippet of zou je daar ook meerdere eigenaren aan kunnen toevoegen? Net zoals bijv. een mede-auteur bij een topicstart.

[Hero of Time]

Zit er een maximum grootte aan een snippet? Of maximum aantal snippets? Want als mensen een 'dark mode' maken, zal dat veel meer code zijn dan wat marges hier of daar aanpassen.

[Jogai]

Worden de tweakers sources gepubliceerd? Dan wordt het wat makkelijker om bijv. een dark mode te maken dmv variabelen in less/css. Qua publicatie hoef je alleen de diff van de output als snippet te publiceren

[crisp]

NMe schreef op maandag 6 mei 2019 @ 19:15:
[...]

Populariteit op basis van het aantal gebruikers dat 't daadwerkelijk gebruikt lijkt me makkelijker te bouwen en zoals gezegd effectiever. Duimpjes toevoegen kan ook best maar ik zou die niet gebruiken voor de populariteitssortering.

Ik kan niet helemaal uit je bericht opmaken of dat sorteren op populariteit nou ook een "nice to have" is maar het lijkt me dat de feature bijna niet zinnig te gebruiken is zonder die sortering.

Gebruiksdata willen we sowieso wel gaan gebruiken als populariteitsindicatie, en waarschijnlijk ook wel een simpele keyword-search (de maker kan een titel + omschrijving toevoegen aan een snippet). Verder ligt het er natuurlijk aan hoeveel snippets er uiteindelijk gaan rouleren of daar verdere metrics en searchopties voor nodig zijn.

Zeror schreef op maandag 6 mei 2019 @ 19:20:
[...]

En is dan 1 persoon eigenaar van zo'n snippet of zou je daar ook meerdere eigenaren aan kunnen toevoegen? Net zoals bijv. een mede-auteur bij een topicstart.

In eerste instantie is er maar 1 eigenaar. Mede-auteurs is weer een typische 'nice-to-have' en zal zeker niet in eerste instantie prioriteit krijgen.

Hero of Time schreef op maandag 6 mei 2019 @ 19:51:
Zit er een maximum grootte aan een snippet? Of maximum aantal snippets? Want als mensen een 'dark mode' maken, zal dat veel meer code zijn dan wat marges hier of daar aanpassen.

Daar hebben we nog niet echt over nagedacht. Ik denk niet dat we daar hele restrictieve limieten op zullen zetten, maar we raden wel aan om snippets 'klein' te houden. Dat vergemakkelijkt onderhoud, maakt het opsporen van bugs makkelijker, en dan kunnen mensen makkelijker snippets combineren met minder kans op conflicten. Een complete dark-mode kan natuurlijk, maar zelfs daarvoor zou ik kijken of je dat op een of andere manier goed kan structureren.

Jogai schreef op maandag 6 mei 2019 @ 19:55:
Worden de tweakers sources gepubliceerd? Dan wordt het wat makkelijker om bijv. een dark mode te maken dmv variabelen in less/css. Qua publicatie hoef je alleen de diff van de output als snippet te publiceren

Onze SASS sources bedoel je? We zijn sowieso niet van plan om SASS of LESS ondersteuning aan te bieden, en we gebruiken ook geen CSS variabelen op dit moment en daar zijn ook geen plannen voor. Ik kan wel intern opperen of we onze styleguide openbaar kunnen maken.

* disclaimer: alles wat ik hier post is uiteraard nog onder voorbehoud e.d. Dit topic is in eerste instantie bedoelt om te peilen of dit voorziet in een behoefte. De ideeën zijn daarom ook nog vrij ruw. We kijken in eerste instantie natuurlijk vooral naar wat nodig is voor een eventuele MVP.

[ Voor 5% gewijzigd door crisp op 06-05-2019 21:39 ]

[Jogai]

@crisp Sass bedoel ik ja. Niet om sass snippets te publiceren, maar dan kan je als snippet schrijver makkelijk de sass variabelen herbruiken. Als snippet hoef je dan alleen de output te publiceren die daadwerkelijk afwijkt. Voor dark mode krijg je dan css waar alleen de kleuren overschreven worden bijv.

[.oisyn]

Juup schreef op maandag 6 mei 2019 @ 18:12:
Let op dat je met CSS wachtwoorden kan stelen en andere rare fratsen

Dit is ook het eerste waar ik aan dacht bij de automatische updates van de eigenaar. Je kunt in principe verifiëren dat de huidige snippet niet kwaadaardig is, maar je geeft de eigenaar van een veelgebruikte snippet wel veel macht ineens. Ik snap de toegevoegde waarde ervan wel, maar misschien handig om een notificatie te geven als een snippet aangepast is?

[Zeror]

crisp schreef op maandag 6 mei 2019 @ 21:35:
[...]

In eerste instantie is er maar 1 eigenaar. Mede-auteurs is weer een typische 'nice-to-have' en zal zeker niet in eerste instantie prioriteit krijgen.

Zeker bij populaire snippets kan het erg handig zijn om meerdere eigenaren te hebben. Zou er zeker wel over nadenken om het snel in deze nieuwe feature erbij te hebben.

[Hero of Time]

crisp schreef op maandag 6 mei 2019 @ 21:35:
[...]

Daar hebben we nog niet echt over nagedacht. Ik denk niet dat we daar hele restrictieve limieten op zullen zetten, maar we raden wel aan om snippets 'klein' te houden. Dat vergemakkelijkt onderhoud, maakt het opsporen van bugs makkelijker, en dan kunnen mensen makkelijker snippets combineren met minder kans op conflicten. Een complete dark-mode kan natuurlijk, maar zelfs daarvoor zou ik kijken of je dat op een of andere manier goed kan structureren.

Dat was ook een beetje mijn insteek. Als je meerdere snippets mag hebben, zonder bepaalde beperking van aantal, is het veel overzichtelijker om een dark mode te maken en bij te houden. Je kan dan 'per pagina' een snippet maken dat samen een geheel wordt.

Jogai schreef op maandag 6 mei 2019 @ 22:41:
@crisp Sass bedoel ik ja. Niet om sass snippets te publiceren, maar dan kan je als snippet schrijver makkelijk de sass variabelen herbruiken. Als snippet hoef je dan alleen de output te publiceren die daadwerkelijk afwijkt. Voor dark mode krijg je dan css waar alleen de kleuren overschreven worden bijv.

Ik denk niet dat het heel viable is om dat te maken. Zoals ik de functie hier zie, is een aanpassing van de huidige custom css mogelijkheden. Oftewel, het zal hoe dan ook ná de standaard CSS worden gemaakt en de server geeft volledige CSS terug. Wat jij in je custom CSS zou zetten dat als variabele een waarde in de SASS/LESS code zou overschrijven, is dan geen variabele meer.

Je kan wel altijd je eigen variabelen gebruiken.


Ik zie ook wel iets in het notificatiesysteem wat @.oisyn oppert. Blind zaken toepassen als update wil ik niet. Want naast veiligheid zit je ook met compatibiliteit. Stel dat ik al iets heb gestyled wat een ander in zijn/haar snippet ook gaat doen. Dan wil ik niet dat die code de mijne overschrijft, alleen maar omdat de reden dat ik de code had toegevoegd om een bepaalde functie was.

[.oisyn]

Hero of Time schreef op maandag 6 mei 2019 @ 23:02:
Ik zie ook wel iets in het notificatiesysteem wat @.oisyn oppert. Blind zaken toepassen als update wil ik niet.

Daar zat ik idd ook aan te denken (oa door de door jouw aangedragen argumentatie), maar ik schreef het niet op omdat het systeem dan al snel ingewikkeld wordt om te implementeren. Er zijn een aantal opties:

1. Er is een versioning systeem waarbij iedereen gewoon een specifieke versie van de snippet kan gebruiken en on demand kan updaten
2. Iedereen heeft zijn eigen lokale kopie van de snippet, die eveneens on demand geüpdate kan worden als het origineel is gewijzigd
3. Na elke change staat een snippet standaard uit en moet je 'm opnieuw goedkeuren

1 is natuurlijk het mooist maar lijkt me enorm veel werk om te implementeren. Punt 3 is denk ik heel onwerkbaar als je veel snippets hebt met regelmatige updates. Dan kom je uit op punt 2, met uiteraard als nadeel dat je heel veel kopieën gaat krijgen van dezelfde snippet, of je moet een copy-on-write scheme hanteren oid.

[crisp]

Notificatie bij een update zou misschien kunnen. Een indicatie bij je custom css (waar je dan ook een overzicht van de gebruikte snippets zou hebben) dat er een recente update is geweest van een bepaalde snippet lijkt me sowieso handig. Versioning en/of on-demand updaten maken het systeem m.i. nodeloos complex en minder gebruiksvriendelijk.

We kijken in eerste instantie wat er echt minimaal voor een dergelijk systeem nodig is.

[Zeror]

Ik beeld mij een soort van codepen-achtige interface in waarmee je x-aantal css-snippets kunt toevoegen (afhankelijk van het aantal karma of abo). En je kunt je snippet een naam geven en tags toevoegen.

[Hero of Time]

Zeror schreef op maandag 6 mei 2019 @ 23:59:
Ik beeld mij een soort van codepen-achtige interface in waarmee je x-aantal css-snippets kunt toevoegen (afhankelijk van het aantal karma of abo). En je kunt je snippet een naam geven en tags toevoegen.

Alsjeblieft geen beperking opleggen in aantal en whatnot, zeker gebaseerd op karma en/of abbo status. Dat is een echte dooddoener voor deze feature.

[Jogai]

@Hero of Time Ik bedoel ook niet sass variabelen in snippets, ik doel alleen erop dat je makkelijker css snippets kan maken als je de sass source hebt. Dat in de frontend alleen css compatible is snap ik. Maar voor de rest is het niet zo'n heel belangrijk punt.

Zeror schreef op maandag 6 mei 2019 @ 22:58:
[...]

Zeker bij populaire snippets kan het erg handig zijn om meerdere eigenaren te hebben. Zou er zeker wel over nadenken om het snel in deze nieuwe feature erbij te hebben.

Maar als iemand samen wil werken kan die dat prima zelf (via github oid) regelen toch? Het hoeft niet perse via tweakers te verlopen?

[Hero of Time]

Jogai schreef op dinsdag 7 mei 2019 @ 11:11:
@Hero of Time Ik bedoel ook niet sass variabelen in snippets, ik doel alleen erop dat je makkelijker css snippets kan maken als je de sass source hebt. Dat in de frontend alleen css compatible is snap ik. Maar voor de rest is het niet zo'n heel belangrijk punt.

Wat let je om zelf main.css e.d. te downloaden om zo alle elementen te verkrijgen? Maar wat in een ander topic al eens is gezegd, er zijn ook nog wat elementen die wel in CSS staan, maar niet in gebruik in de code. Bijvoorbeeld omdat het element zelf weg is of van naam is verandert.

Dus al zou je het hebben, dan nog kan je overbodig werk zitten te doen.

[masauri]

Ikzelf kan zelf geen snippits/costum ccs maken, ,maar een darkmode aanpassing of tweakblogs van een bepaald persoon zichtbaar/niet zichtbaar weergeven zou ik ten zeerste appricieren!!!

[Zeror]

Jogai schreef op dinsdag 7 mei 2019 @ 11:11:
Maar als iemand samen wil werken kan die dat prima zelf (via github oid) regelen toch? Het hoeft niet perse via tweakers te verlopen?

Met dat argument kun je net zo goed geen snippet functie toevoegen. Het zou juist mooi zijn als samenwerken aan een snippet gewoon op Tweakers kan zonder een extra tool.

[Gropah]

Zeror schreef op dinsdag 7 mei 2019 @ 15:06:
[...]

Met dat argument kun je net zo goed geen snippet functie toevoegen. Het zou juist mooi zijn als samenwerken aan een snippet gewoon op Tweakers kan zonder een extra tool.

Maar zoiets integreren kost denk ik erg veel tijd. Het lijkt mij belangrijker om op een manier snippets te kunnen delen (en een overzicht te hebben van welke snippets er (veel gebruikt worden)/zijn) dan om er samen aan te kunnen werken. Bij het delen kan iedereen waarschijnlijk al bij de CSS en/of de auteur benaderen met bugs, ideeen en evt. code als iemand een idee al heeft geimplementeerd.

edit: trouwens goed dat hier aan gewerkt word!

[ Voor 3% gewijzigd door Gropah op 07-05-2019 15:09 ]

[Zeror]

Zoals Crisp al aangaf is het samenwerken wel een 'nice to have'-feature. Daar ben ik het wel mee eens hoor. Het delen van snippets moet dus hoofdzaak worden. Bij een populaire snippet zou het echter wel mooi zijn als je deze met meerdere mensen kunt onderhouden.

[P1nGu1n]

Ik ben zelf een fanatieke custom CSS gebruiker. Mijn custom CSS bestaat uit een hoop kleine tot middelgrote snippets, die ik graag zou delen. En het gebruiken van snippets van mede-Tweakers uiteraard, die zullen ongetwijfeld leuke ideeën hebben

Hoe ik het voor me zie:

Must have:

• Overzicht met aangeboden snippets
• Overzicht met snippets die je nu gebruikt
• Titel en omschrijving
• Screenshots
• Code bekijken
• Code updaten (door eigenaar)
• Automatische security check (bv door het blokkeren van externe resources, zoals hierboven geopperd)

Should have:

• Zoeken naar snippets
• Populariteitsindicatie (likes/votes/users)
• Syntax highlighting van code
• Rapporteren van snippets
• Snippet moderators (waar kan ik me inschrijven? )
• Custom CSS forum

Could have:

• Controle van alle snippets of Verified snippets (goedgekeurd by devvers/moderators)
• Versioning en version control
• Collaboration / meerdere maintainers
• Minification van custom CSS (dus niet van de snippet zelf, die moet moet in te zien zijn)
• Iets van een systeem met feedback op een snippet, waar gebruikers kunnen melden dat een snippet niet meer werkt en het voor andere gebruikers duidelijk is dat er een probleem kan zijn

Won't have Wishes:

• Officiële dark mode

Volgens de MoSCoW methode, de Must Haves vormen een MVP.

Regels voor snippets:

• Geen advertenties blokkeren
• Minification niet toegestaan
• Geen externe resources inladen

[ Voor 14% gewijzigd door P1nGu1n op 07-05-2019 17:19 ]

[Toxic_Dreams]

Misschien dat het een idee is om geaccepteerde includes toe te voegen? Bijv. van Font Awesome.

Dat mensen deze includes toe kunnen voegen aan hun snippet door uit een lijst te kiezen met includes die is geaccepteerd door Tweakers zelf.

Zo kunnen mensen geen willekeurige includes toevoegen, maar enkel includes die zijn goedgekeurd. Wel includes, een stuk minder risico.

[josvane]

Ben ik de enige die zich verbaasd over deze functie. Diverse zaken worden er uit de code gesloopt omdat die zo gezegd te veel onderhoud vergen en volgens de statistieken alleen door hardcore gebruikers gebruikt worden en daardoor niet waardevol genoeg zijn om te houden.

Naast dat worden de ankeliers compleet om zeep geholpen met de nieuwe weergave en promoten ze een custom CSS om het volledig te verbergen.

Vervolgens gaan we echter een functie in het leven roepen die mogelijk nog meer code en onderhoud vraagt en veelal precies doet wat de devvers niet willen. Dingen verbergen.

Kortom volgens mij gaat er bij Tweakers echt wat mis.

[Hero of Time]

Het is een uitbreiding op een functie die er al jaren is: custom css. Als je alles wilt verbergen op de FP, kan dat tot op zekere hoogte (elementen waar advertenties in staan worden automatisch uitgeschakeld in je code).

Er is gehoor gegeven aan de vele kritiek die is gekomen, die extra hoorbaar was bij de recente make-over van de FP. Had je liever gehad dat die groep hardcore tweakers wordt doodgezwegen en men de klachten maar wegwuiven onder het mom van 'wen er maar aan'? Dán gaat er pas echt wat mis.

[.oisyn]

Ik hoop trouwens niet dat de komst van snippets ervoor zorgen dat ik helemaal geen custom resources mag includen. Dat ik die vervolgens niet als snippet kan delen kan ik best inkomen, maar ik wil de optie om het te kunnen wel houden.

[crisp]

.oisyn schreef op donderdag 9 mei 2019 @ 20:47:
Ik hoop trouwens niet dat de komst van snippets ervoor zorgen dat ik helemaal geen custom resources mag includen. Dat ik die vervolgens niet als snippet kan delen kan ik best inkomen, maar ik wil de optie om het te kunnen wel houden.

Het idee is dat je naast het gebruik van snippets nog steeds het huidige CSS-veld houdt waar je in kan doen wat je wilt

[NMe]

josvane schreef op donderdag 9 mei 2019 @ 17:04:
Vervolgens gaan we echter een functie in het leven roepen die mogelijk nog meer code en onderhoud vraagt en veelal precies doet wat de devvers niet willen. Dingen verbergen.

Als dit eenmaal gebouwd is hoeft er op zich geen devver meer naar te kijken.

[josvane]

Hero of Time schreef op donderdag 9 mei 2019 @ 18:52:

Er is gehoor gegeven aan de vele kritiek die is gekomen, die extra hoorbaar was bij de recente make-over van de FP. Had je liever gehad dat die groep hardcore tweakers wordt doodgezwegen en men de klachten maar wegwuiven onder het mom van 'wen er maar aan'? Dán gaat er pas echt wat mis.

Je zegt het zelf al: "aan de vele kritiek". Als we Femme mogen geloven dan lijkt dit maar een kleine groep.
Begrijp mij niet verkeerd het komt alleen een beetje over van:

Ik maak iets wat goed is kapot, via een omweg maak ik het en wil daar graag een schouderklopje voor.

[josvane]

NMe schreef op donderdag 9 mei 2019 @ 23:10:
[...]

Als dit eenmaal gebouwd is hoeft er op zich geen devver meer naar te kijken.

Waarom heeft deze code geen onderhoud nodig, en die van cozy, compact e.d. wel?

[.oisyn]

josvane schreef op vrijdag 10 mei 2019 @ 08:42:
[...]


Waarom heeft deze code geen onderhoud nodig, en die van cozy, compact e.d. wel?

"Onderhoud" is niet binair, maar een schaal. Het onderhouden van allerlei layout setting is veel meer werk en bovendien volatieler dan een systeem om snippets te kunnen delen. Je kunt de twee dus niet zomaar tegen elkaar wegstrepen.

[ Voor 7% gewijzigd door .oisyn op 10-05-2019 09:25 ]

[ACM]

josvane schreef op vrijdag 10 mei 2019 @ 08:41:
Je zegt het zelf al: "aan de vele kritiek". Als we Femme mogen geloven dan lijkt dit maar een kleine groep.

Het lastige aan dergelijke kritiek is dat (lang) niet iedereen kritiek heeft en bovendien daarna niet dezelfde oplossing voor ogen heeft.
Daarnaast is sommige van de kritiek lastig te verenigen met interne plannen/wensen; en doordat het 'sommige' is is het weer niet genoeg om die plannen (significant) aan te passen.

Al met al is er al custom css en wordt dat al gebruikt om bestaande en nieuwe features anders te presenteren of te verbergen.

Het is vanuit de 'veranderaar' gezien natuurlijk letterlijk een lapmiddel; maar wel een die best goed werkt.
En dat willen we dus wat beter toegankelijk maken voor degenen die minder thuis zijn in css of de tijd er niet voor willen nemen.

josvane schreef op vrijdag 10 mei 2019 @ 08:42:
Waarom heeft deze code geen onderhoud nodig, en die van cozy, compact e.d. wel?

Alle code heeft in beginsel onderhoud nodig. Er is voortschreidend inzicht van hoe iets hoort te werken (bijv nieuwe inzichten in veiligheid) en doordat andere code verandert kan code ook verouderen en daarmee de toekomstige aanpasbaarheid en onderhoudbaarheid verslechteren.

Er zit echter een groot verschil tussen die layout-settings en veel andere code.

Cozy/compact was niet (min of meer) losse 'feature' van de site, maar een instelling voor de weergave van heel Tweakers en daarmee dus een instelling die invloed kon hebben op elke feature. Dat hebben we om die reden dan ook op een gegeven moment gereduceerd tot de frontpage en het forum; en ondertussen alleen het forum.

De layout-settings moesten in principe meegenomen worden bij elke aanpassing aan bestaande functionaliteit en bij nieuwe functionaliteit. En tot de scope-reductie gaf dat dus in principe iedere keer wat extra werk (soms alleen een 'het gaat vanzelf al goed alleen nog even dubbelchecken' en soms extra css werk). En de keren dat dat ten onrechte vergeten werd, gaf het dan extra werk via bugreports

Los daarvan biedt custom css ook mogelijkheden om andere wensen door de gebruiker zelf in te laten vullen. Een concreet voorbeeld is de wens voor een "dark mode".
Ook daarvan zien we het niet zitten om dat te doen, want ook dat vereist steeds opnieuw voor extra aandacht en inspanning vanwege de donkere versie bij iedere toekomstige wijziging. En dat komt bovenop de toch al forse taak om het überhaupt in eerste instantie 'goed genoeg' te maken (en de bugreports die volgen omdat bepaalde plekken gemist zijn of op schermen met beperkt contrast niet goed werken).

Met deze feature maken we het eenvoudiger om door de tweakers zelf een "dark mode" uit te werken en die onderling te delen en onderhouden.

Terug naar ons onderhoudswerk:
Voor het overgrote deel van de site verandert er niets, want custom css bestaat al. En in de praktijk houden we daar bij aanpassingen domweg geen rekening mee. Mochten er vragen over komen, dan helpen we doorgaans wel om e.e.a. te fixen (hoewel andere tweakers ons meestal al voor zijn).
Deze functionaliteit biedt daarom vooral een extra manier om custom css op jouw pagina te krijgen, met bovendien mogelijkheden om fixes door medetweakers 'vanzelf' bij je terecht te laten komen.

[AW_Bos]

Ik kan mij herinneren dat gebruikers van Fok! die een abonnement hadden ook de mogelijkheid hadden/hebben om Custom CSS te gebruiken. Nu zijn de meeste Fok!kers niet echt technisch aangelegd, dus had iemand (@GlowMouse dacht ik?) een soort van CSS-generator aangemaakt, waarmee je diverse stijl-snippets kon aan en uit vinken, zodat je een eigen CSS-sheet kon samenstellen.

Zoiets zou ook een idee kunnen zijn op Tweakers, en dat er iemand (bijv. via een feedback-forumtopic) leuke snippets aan de lijst toe kan voegen, zodat anderen die kunnen kiezen. Uiteindelijk wordt er dan een sheet gegenereerd die gebruikers zelf kunnen copy-pasten in hun Custom-CSS veld.

Mij lijkt het niet handig om dit automatisch vanaf de keuzelijst in de Custom-CSS te schrijven, omdat sommige Tweakers wat eigen customized styling hebben. En bovendien leren ze ook eventueel een beetje bij

[GlowMouse]

AW_Bos schreef op dinsdag 14 mei 2019 @ 12:21:
Ik kan mij herinneren dat gebruikers van Fok! die een abonnement hadden ook de mogelijkheid hadden/hebben om Custom CSS te gebruiken. Nu zijn de meeste Fok!kers niet echt technisch aangelegd, dus had iemand (@GlowMouse dacht ik?) een soort van CSS-generator aangemaakt, waarmee je diverse stijl-snippets kon aan en uit vinken, zodat je een eigen CSS-sheet kon samenstellen.

Die tool was door user PiRANiA gemaakt en is nog te bezichtigen op The Internet Archive.

[CH4OS]

Ik heb hieronder een wat kritische noot, hopelijk zijn die hier ook welkom. Mocht dat ergens anders moeten, dan verneem ik graag waar, zodat ik een mod kan vragen om mijn bericht te verplaatsen.

Enerzijds tof dat deze feature er komt. Aan de andere kant ben ik van mening dat custom CSS in tegenstelling tot bij zijn introductie (toen waarschuwde men meer dat men er een boel mee stuk kon maken en het juist zo min mogelijk gebruikt moest worden, tenzij je wist wat je doet, et cetera), steeds meer gebruikt wordt als lapmiddel/alternatief voor mensen die dingen willen in de frontpage (om diverse redenen), die voorheen wel beschikbaar waren (als feature dus), maar nu niet meer. Een en ander zou anders te complex zijn of worden. Toch blijf ik het dan vreemd vinden; als het nu (schijnbaar) zo complex is, waarom kon het in het verleden dan wel?

Ik zie custom CSS daarom (hoe goed bedoeld ook) meer als een pleister voor het daadwerkelijke probleem en ik vraag mij af in hoeverre de problemen die men op de FP bijvoorbeeld heeft daadwerkelijk "opgelost" kunnen worden door middel van custom CSS. Ik vind het dan ook jammer dat Tweakers-crew er steeds meer naar verwijst. Op deze manier loop je als user altijd achter de feiten aan wanneer een en ander aangepast is door het devteam en moet je (wanneer er weer een aanpassing is geweest) de custom CSS aanpassen of wachten op een update van de snippet, als het nog bijgehouden wordt, wat je dan ook niet 100% zeker weet.

Ik ben aan de andere kant ook heel erg benieuwd hoe dit tot een uiterst minimum beperkt gaat worden danwel voorkomen gaat worden. Hierbij maakt het mijns inziens niet uit of dit in de custom CSS van al die gebruikers moet, of de snippet door 1 iemand bijgewerkt moet worden; je hebt er gewoonweg een afhankelijkheid bij en ik denk dat niet alle CSS snippets het eeuwige leven zullen krijgen. Wellicht dus ook handig om snippets te kunnen forken, zodat een ander het eventueel over kan nemen, wanneer iemand stopt zijn snippet bij te houden.

Daar komt nog bij dat als je dingen zou verbergen met de custom CSS / snippet, dat je altijd minder content gaat zien (er komt immers ook niets voor terug). Ergens misschien fijn, maar als je uit de trackers dingen gaat filteren, moet je het aantal items altijd op 20 hebben staan, wil je nog enigszins een lijstje over kunnen houden. Toen ik dit eerder meldde heeft @crisp daar een ticket voor aangemaakt, maar aan de andere kant, in de .plans-tracker is nog steeds minimaal de helft een .adv bijvoorbeeld, iets wat ik eigenlijk sowieso al niet zou verwachten als betalend lid die advertenties uit heeft staan... Maar zou ik met custom CSS (snippets) de .adv artikelen eruit filteren, blijft er dus nog maar de helft over van de 20, want CSS kan er geen nieuwe items erbij toveren, immers. Dat kan gewoonweg niet de bedoeling zijn lijkt me? Hoe gaan jullie dat oplossen?

Ik zie dus eigenlijk best wat haken en ogen op de weg, voor een (in mijn ogen) toch al zeer bedenkelijke "oplossing" / workaround.

[ Voor 33% gewijzigd door CH4OS op 15-05-2019 01:44 ]

[CH4OS]

Om het topic weer even onder de aandacht te brengen en om ook een duit in het spreekwoordelijke zakje te doen: zou tof zijn als er ook support komt voor SASS. Dat zou eea vergemakkelijken, imo, al blijf ik van mening dat custom CSS aangegrepen gaat worden als pleister voor daadwerkelijke wonden. Of je dat in de handen van de community moet willen geven, betwijfel ik zeer.

[Hero of Time]

@CH4OS, hoe zie je dat voor je, SASS support? Je wilt juist niets extra hoeven doen op de server als er code in een veld wordt geplaatst.

Je kan wel variabelen gebruiken, zoals dat zonder aparte library al te gebruiken is.

[CH4OS]

Ik doel met name op gebruik van variabelen inderdaad, zodat je kleurcodes bijvoorbeeld maar 1x hoeft te defineren.

[.oisyn]

Dat kan al in standaard CSS

[NMe]

Jup, alleen heten ze dan anders: https://developer.mozilla...ing_CSS_custom_properties

[mbenjamins]

Ondersteuning voor SASS zou ik ook wel fijn vinden voor bijv. het nesten van je css.

[johnwoo]

Ik had de melding in de .plan eerder wel gezien, maar vindt nu het topic pas.

Exact dit had ik jaren geleden (we praten 2010) ook bedacht en deels uitgewerkt, een CSS snippet repository onder de naam TweakCSS. Inclusief validatie van tweakers account om enkel members snippets toe te laten voegen (Ik zie dat ik de validatiecode nog in m'n bio heb staan ). Het is nooit live gegaan overigens, want het was nog niet af plus ik had er geen hosting voor. Leuk om te zien dat zoiets er nu "officieel" gaat komen.

Mijn opzet had o.a.:
- Support voor LESS en SCSS (en platte CSS uiteraard).
- Automatische check op risicofactors na sanitizen (alleen op t.net gehoste images, bv, in fotoalbum, waren toegestaan voor een "safe" rating; links naar andere domeinen of CSS imports gaven automatisch een "unsafe" rating).
- Version history. Safe updates werden automatisch toegepast voor alle subscribers; wanneer een snippet "unsafe" werd, bleef een subscriber op de oude "safe" versie en kreeg alleen een notificatie (om de update desgewenst handmatig te activeren).
- Slimme caching van gegenereerde CSS (ipv verschillende snippets apart te serveren werden ze voor een gebruiker gemerged gecachet met een extreem lange expiration tijd en een cache-busting suffix).
- Compatibiliteits-info (door gebruikers ingevuld) zodat er geen 2 snippets tegelijk geactiveerd werden die niet goed met elkaar samenwerken (althans niet zonder waarschuwing/bevestiging).
- Ratings en overzichten ("most used snippets", "highest rated" en zo).
- Verder wilde ik er ook nog een vorm van dependencies in bouwen, zodat een snippet kon voortborduren op een (of enkele) andere, of verschillende snippets via een "group snippet" samen een "theme" konden vormen (maar hier was ik zelfs nog niet aan begonnen).

Ik moet eens kijken of ik die map nog ergens kan terugvinden. Erg benieuwd of het nog werkt, zulke oude PHP code (5.2 of zo)

[crisp]

johnwoo schreef op vrijdag 14 juni 2019 @ 01:01:
Ik had de melding in de .plan eerder wel gezien, maar vindt nu het topic pas.

Exact dit had ik jaren geleden (we praten 2010) ook bedacht en deels uitgewerkt, een CSS snippet repository onder de naam TweakCSS. Inclusief validatie van tweakers account om enkel members snippets toe te laten voegen (Ik zie dat ik de validatiecode nog in m'n bio heb staan ). Het is nooit live gegaan overigens, want het was nog niet af plus ik had er geen hosting voor. Leuk om te zien dat zoiets er nu "officieel" gaat komen.

Het goede nieuws is dat we er deze iteratie ook al aan begonnen zijn Uiteraard is het volgende week nog niet klaar, daar zullen nog wel een aantal iteraties overheen gaan en dus kunnen we ook nog geen ETA geven, maar het begin is er

Wat er in ieder geval niet in een eerste versie zal zitten:

• LESS/SASS support
• versiebeheer
• dependencies
• compatibiliteitsinfo (gebruikers krijgen wel de mogelijkheid om de volgorde van gebruikte snippets in te stellen)
• ratings/comments/feedback voor snippets (hoewel ik mij hier bedenk dat ons commentsysteem wel eenvoudig toegepast zou kunnen worden op een detailpagina van een snippet)
• mede-auteurs
• syntax highlighting
• screenshots
• rapportage/moderatie (in de backend bouwen we wel alvast een mogelijkheid in om snippets te kunnen disablen)

Ik ga niet vooruit lopen op de toekomst of we dergelijke zaken dan wel zullen gaan implementeren, dat is geheel afhankelijk van behoefte of noodzaak afgezet tegenover de vele andere prioriteiten...

[AW_Bos]

Ik neem aan dat er i.p.v rapportage/moderatie wel een contact linkje is naar de auteur.

[crisp]

AW_Bos schreef op vrijdag 14 juni 2019 @ 09:28:
Ik neem aan dat er i.p.v rapportage/moderatie wel een contact linkje is naar de auteur.

Ja, een linkje naar de DM of zo

[Verwijderd]

Om hier mee aan de slag te gaan zou ik ook graag het topic ID ergens in de tabellen terug willen zien. Is dat mogelijk?

[crisp]

Verwijderd schreef op maandag 24 juni 2019 @ 08:17:
Om hier mee aan de slag te gaan zou ik ook graag het topic ID ergens in de tabellen terug willen zien. Is dat mogelijk?

Wat wil je dan precies bereiken?

[Verwijderd]

crisp schreef op maandag 24 juni 2019 @ 08:22:
[...]

Wat wil je dan precies bereiken?

Topicreeksen en bepaalde topics blokkeren. Zoals je nu in je history kan doen, maar dan op meer plekken.

[crisp]

Verwijderd schreef op maandag 24 juni 2019 @ 08:27:
[...]

Topicreeksen en bepaalde topics blokkeren. Zoals je nu in je history kan doen, maar dan op meer plekken.

Ah, wegfilteren uit listings dus? Je kan met behulp van attribute selectors links verbergen. Ik denk echter niet dat we op allerlei plekken specifieke classes of id's gaan toevoegen alleen voor deze usecase.

Overigens heeft dit m.i. weinig te maken met de snippet feature. Bepaalde topics verbergen doe je volgens mij meer voor jezelf dan dat het iets is dat je wilt delen met anderen...

[Verwijderd]

crisp schreef op maandag 24 juni 2019 @ 08:37:
[...]

Ah, wegfilteren uit listings dus? Je kan met behulp van attribute selectors links verbergen. Ik denk echter niet dat we op allerlei plekken specifieke classes of id's gaan toevoegen alleen voor deze usecase.

Overigens heeft dit m.i. weinig te maken met de snippet feature. Bepaalde topics verbergen doe je volgens mij meer voor jezelf dan dat het iets is dat je wilt delen met anderen...

Ja dat is zo. Ik ga me er eens in verdiepen.

[RoestVrijStaal]

Heeft iemand het al over het integreren van een CSS linter gehad?

JSFiddle.net gebruikt StyleLint.

[ Voor 6% gewijzigd door RoestVrijStaal op 25-06-2019 15:28 ]

[ikloon]

Vandaag hebben we de custom CSS snippets feature beschikbaar gemaakt. Zie: plan: Custom-css-snippets beschikbaar - Development-iteratie #165.

[Zeror]

Waarom kan een publieke snippet eigenlijk niet meer privé gemaakt worden?

[.oisyn]

Ik gok omdat ie al in gebruik kan zijn door anderen.

Persoonlijk vind ik het niet een heel goed idee dat aanpassingen automatisch bij iedereen van toepassing zijn. Mocht een schrijver van een populaire snippet ineens mot krijgen met de crew en uit rancune een body { display:none !important; } in zijn snippet zetten dan is de hele site ineens plots onbruikbaar voor heel veel mensen.

Of, wat minder opvallend, hij krijgt ruzie met een andere user en hij maakt al zijn posts onzichtbaar.

[ Voor 87% gewijzigd door .oisyn op 24-09-2019 14:36 ]

[crisp]

.oisyn schreef op dinsdag 24 september 2019 @ 14:31:
Ik gok omdat ie al in gebruik kan zijn door anderen.

Dat inderdaad

Persoonlijk vind ik het niet een heel goed idee dat aanpassingen automatisch bij iedereen van toepassing zijn. Mocht een schrijver van een populaire snippet ineens mot krijgen met de crew en uit rancune een body { display:none !important; } in zijn snippet zetten dan is de hele site ineens plots onbruikbaar voor heel veel mensen.

Of, wat minder opvallend, hij krijgt ruzie met een andere user en hij maakt al zijn posts onzichtbaar.

Een admin kan publieke snippets tijdelijk disablen en uiteraard eventueel ander maatregelen nemen als er echt sprake is van misbruik.

[Zeror]

.oisyn schreef op dinsdag 24 september 2019 @ 14:31:
Of, wat minder opvallend, hij krijgt ruzie met een andere user en hij maakt al zijn posts onzichtbaar.

Dit vind ik anders ook niet kunnen:

https://tweakers.net/inst...omcss/snippets/bekijk/50/

Dit is boycotten van een bedrijf.

[.oisyn]

Deze is ook redelijk populair, die treft een specifieke gebruiker: https://tweakers.net/inst...omcss/snippets/bekijk/30/

Ergens vind ik dat dat moet kunnen. Althans, je kan het met custom css nu eenmaal, en die dingen zijn te delen. Anderzijds kun je je afvragen of t.net voor dit soort zaken een platform wenst te bieden.

(En ik weet toevallig dat er mensen zijn die ook zijn forumposts op die manier verbergen)

[ Voor 57% gewijzigd door .oisyn op 24-09-2019 15:14 ]

[EJlol]

Laat ik beginnen met het feit dat ik het een gave feature vind .

Het enige wat ik wel mis is een overzicht met de complete CSS. Als ik nu wil kijken of ik bepaalde snippets dubbel heb, of eventueel waarom iets niet werkt, dan moet ik eigenlijk elke snippet apart aanklikken om te kijken wat de snippet precies doet. Een overzicht van de uiteindelijke CSS kan hierbij helpen.

[Xaverius]

Aangezien ik zelf geen Custom CSS gebruik was ik nieuwsgierig naar de snippets die anderen gebruiken. Maar omdat ik dus deze functie niet geactiveerd heb kan ik niks zien. Is het mogelijk om voorbeelden van deze snippets ergens te zien of leef ik al jaren onder een steen en heb ik een topic gemist?

[Cloud]

Even afgezien van de potentie tot misbruik, vind ik het een toffe feature en werkt het goed. Lekker geïmplementeerd d:) b

Ik heb zojuist mijn eigen custom css gesplitst naar drie snippets die ik nu gebruik. Eentje was zelfs al gemaakt door iemand; de andere twee heb ik zelf publiek gemaakt.

[Kanarie]

.oisyn schreef op dinsdag 24 september 2019 @ 15:11:
Deze is ook redelijk populair, die treft een specifieke gebruiker: https://tweakers.net/inst...omcss/snippets/bekijk/30/

Ergens vind ik dat dat moet kunnen. Althans, je kan het met custom css nu eenmaal, en die dingen zijn te delen. Anderzijds kun je je afvragen of t.net voor dit soort zaken een platform wenst te bieden.

Zeror schreef op dinsdag 24 september 2019 @ 15:10:
[...]

Dit vind ik anders ook niet kunnen:

https://tweakers.net/inst...omcss/snippets/bekijk/50/

Dit is boycotten van een bedrijf.

Deze beide snippets vind ik top. Ze geven duidelijk aan wat ze doen en ze lossen 2 probleempjes op die ik al langer ervaarde op tweakers.

[.oisyn]

EJlol schreef op dinsdag 24 september 2019 @ 15:13:
Laat ik beginnen met het feit dat ik een gave feature vind .

Het enige wat ik wel mis is een overzicht met de complete CSS. Als ik nu wil kijken of ik bepaalde snippets dubbel heb, of eventueel waarom iets niet werkt, dan moet ik eigenlijk elke snippet apart aanklikken om te kijken wat de snippet precies doet. Een overzicht van de uiteindelijke CSS kan hierbij helpen.

Echt, +1 voor dit voorstel idd! Gewoon even een complete CSS met alles wat je geactiveerd hebt. Dat kan als een enkel tekstvlak (dan wel met comments ertussen zodat je weet uit welke snippet het komt) of gewoon de code van de verschillende snippets onder elkaar gezet in verschillende tekstvlakken.

[Zeror]

Kanarie schreef op dinsdag 24 september 2019 @ 15:15:
[...]


[...]


Deze beide snippets vind ik top. Ze geven duidelijk aan wat ze doen en ze lossen 2 probleempjes op die ik al langer ervaarde op tweakers.

Ja, maar een bedrijf of een persoon is wel een doelwit en dat lijkt mij niet echt de bedoeling. Houd de snippet dan op zn minst privé.

[ Voor 3% gewijzigd door Zeror op 24-09-2019 15:18 ]

[Kanarie]

Zeror schreef op dinsdag 24 september 2019 @ 15:18:
[...]

Ja, maar iets of iemand is wel een doelwit en dat lijkt mij niet echt de bedoeling. Houd de snippet dan op zn minst privé.

Scheelde mij het zelf tikken van de snippets, erg fijn juist

[AW_Bos]

Zeror schreef op dinsdag 24 september 2019 @ 15:10:
[...]

Dit vind ik anders ook niet kunnen:

https://tweakers.net/inst...omcss/snippets/bekijk/50/

Dit is boycotten van een bedrijf.

Ik zou eerder zeggen: Negeren van een bedrijf. Als jij bedrijf A zo ruk vindt, dan mag je toch een zijstraatje in lopen om er niet mee geconfronteerd mee te worden? Het is je eigen mening immers dat je er geen behoefte aan hebt. Als heel Tweakers dit standaard zou aanbieden voor alle gebruikers, dan zou ik het serieus boycotten noemen.

Over de CSS snippet feature! Ik vind het nu al erg handig
Alleen jammer dat er nu dubbele CSS'en ontstaan.

[ Voor 8% gewijzigd door AW_Bos op 24-09-2019 15:34 ]

[F_J_K]

Xaverius schreef op dinsdag 24 september 2019 @ 15:14:
Aangezien ik zelf geen Custom CSS gebruik was ik nieuwsgierig naar de snippets die anderen gebruiken. Maar omdat ik dus deze functie niet geactiveerd heb kan ik niks zien. Is het mogelijk om voorbeelden van deze snippets ergens te zien of leef ik al jaren onder een steen en heb ik een topic gemist?

Leesvoer: [verzamel] CSS-styles; 'Hoe ziet jouw T.net eruit?' maar nu kan je er ook 'gewoon' een in https://tweakers.net/instellingen/customcss/ aanklikken en zien wat er gebeurt

[crisp]

F_J_K schreef op dinsdag 24 september 2019 @ 15:37:


[...]

Leesvoer: [verzamel] CSS-styles; 'Hoe ziet jouw T.net eruit?' maar nu kan je er ook 'gewoon' een in https://tweakers.net/instellingen/customcss/ aanklikken en zien wat er gebeurt

mensen zonder custom css hebben daar geen toegang toe

[F_J_K]

crisp schreef op dinsdag 24 september 2019 @ 15:41:
[...]

mensen zonder custom css hebben daar geen toegang toe

D'oh!

[Gropah]

Zeror schreef op dinsdag 24 september 2019 @ 15:10:
[...]

Dit vind ik anders ook niet kunnen:

https://tweakers.net/inst...omcss/snippets/bekijk/50/

Dit is boycotten van een bedrijf.

Ergens heb je misschien wel gelijk, maar aan de andere kant: er loopt al erg lang een topic over hoe dit bedrijf en om het misschien te weren van de pricewatch

edit & OT:

Top dat dit is uitgerold. Heb even wat aan mijn CSS gezet en 1 ding in een snippet gezet en publiek gemaakt. De rest is allemaal vervangen door snippets van anderen en heb nu vrijwel geen custom css meer

[ Voor 18% gewijzigd door Gropah op 24-09-2019 15:59 ]

[Quakie]

enig idee waarom mijn wijziging niet bewaard wordt onder mijn profiel?

Gebruik stylesheetinstellingen op alle pagina's krijg ik maar niet gesaved

[418O2]

.oisyn schreef op dinsdag 24 september 2019 @ 15:11:
Deze is ook redelijk populair, die treft een specifieke gebruiker: https://tweakers.net/inst...omcss/snippets/bekijk/30/

Ergens vind ik dat dat moet kunnen. Althans, je kan het met custom css nu eenmaal, en die dingen zijn te delen. Anderzijds kun je je afvragen of t.net voor dit soort zaken een platform wenst te bieden.

(En ik weet toevallig dat er mensen zijn die ook zijn forumposts op die manier verbergen)

Je kan je ook afvragen of je zo'n user wel op het platform wil als er zoveel wroeging jegens zijn content is

[crisp]

Quakie schreef op dinsdag 24 september 2019 @ 15:59:
enig idee waarom mijn wijziging niet bewaard wordt onder mijn profiel?

Gebruik stylesheetinstellingen op alle pagina's krijg ik maar niet gesaved

Goede vraag, en nee geen idee maar gaan we uitzoeken

Edit @Quakie zo te zien krijg je een syntax-error warning voor je eigen custom css bij het opslaan:
{quote}CSS: Syntax error in CSS: Identifier expected. Got “} ” [line no: 2]{quote}
Een beetje een vage melding want volgens mij is de syntax prima (waarschijnlijk dus een bug in de door ons gebruikte parser), maar is wel op te lossen door iig de div#sponsored als selector weg te halen (want die mag je niet gebruiken ) en de comment weer te vervangen door display:none

De foutmelding valt hier helaas niet zo op door de plaatsing daarvan onder de gebruikte snippets... Daar moeten we dus waarschijnlijk nog naar kijken

[ Voor 51% gewijzigd door crisp op 24-09-2019 16:30 ]

[stuiterveer]

.oisyn schreef op dinsdag 24 september 2019 @ 14:31:
Ik gok omdat ie al in gebruik kan zijn door anderen.

Persoonlijk vind ik het niet een heel goed idee dat aanpassingen automatisch bij iedereen van toepassing zijn. Mocht een schrijver van een populaire snippet ineens mot krijgen met de crew en uit rancune een body { display:none !important; } in zijn snippet zetten dan is de hele site ineens plots onbruikbaar voor heel veel mensen.

Of, wat minder opvallend, hij krijgt ruzie met een andere user en hij maakt al zijn posts onzichtbaar.

Ik voorzie zelfs een groter risico: iemand verandert de CSS later om afbeeldingen te laden vanuit een extern domein wat tracking in de hand kan werken.

Ben daarom vooral ook benieuwd of er maatregelen zijn getroffen om misbruik te voorkomen en:

• zo ja, welke maatregelen;
• zo nee, waarom niet

[crisp]

stuiterveer schreef op dinsdag 24 september 2019 @ 16:29:
[...]


Ik voorzie zelfs een groter risico: iemand verandert de CSS later om afbeeldingen te laden vanuit een extern domein wat tracking in de hand kan werken.

Ben daarom vooral ook benieuwd of er maatregelen zijn getroffen om misbruik te voorkomen en:

• zo ja, welke maatregelen;
• zo nee, waarom niet

url() kan alleen gebruikt worden met plaatjes van ons eigen domein en @import wordt helemaal niet toegestaan in snippets.

[ImNotnoa]

.oisyn schreef op dinsdag 24 september 2019 @ 15:11:
Deze is ook redelijk populair, die treft een specifieke gebruiker: https://tweakers.net/inst...omcss/snippets/bekijk/30/

Ergens vind ik dat dat moet kunnen. Althans, je kan het met custom css nu eenmaal, en die dingen zijn te delen. Anderzijds kun je je afvragen of t.net voor dit soort zaken een platform wenst te bieden.

(En ik weet toevallig dat er mensen zijn die ook zijn forumposts op die manier verbergen)

En als ik een css snippet maak om dat specifieke snippet te verbergen in de lijst met snippets?

[Quakie]

crisp schreef op dinsdag 24 september 2019 @ 16:13:
[...]

Goede vraag, en nee geen idee maar gaan we uitzoeken

Edit @Quakie zo te zien krijg je een syntax-error warning voor je eigen custom css bij het opslaan:
{quote}CSS: Syntax error in CSS: Identifier expected. Got “} ” [line no: 2]{quote}
Een beetje een vage melding want volgens mij is de syntax prima (waarschijnlijk dus een bug in de door ons gebruikte parser), maar is wel op te lossen door iig de div#sponsored als selector weg te halen (want die mag je niet gebruiken ) en de comment weer te vervangen door display:none

De foutmelding valt hier helaas niet zo op door de plaatsing daarvan onder de gebruikte snippets... Daar moeten we dus waarschijnlijk nog naar kijken

Zag inderdaad foutmelding niet. Ik kreeg het niet werkend dus maar alles verwijderd en opnieuw geselecteerd. 👌🏻

[RoestVrijStaal]

Krijgen snippet-schrijvende Tweakers extra karma als hun publieke snippets gebruikt worden door andere Tweakers?
Het zou wel mooi zijn, want delen van snippets heeft iets sociaals/community versterkends.

[ Voor 29% gewijzigd door RoestVrijStaal op 24-09-2019 21:25 . Reden: Motivatie erbij geschreven ]

[crisp]

RoestVrijStaal schreef op dinsdag 24 september 2019 @ 21:21:
Krijgen snippet-schrijvende Tweakers extra karma als hun publieke snippets gebruikt worden door andere Tweakers?

Dat staat wel op onze nice-to-have list, dus wie weet komt dat later nog

[NMe]

Zeror schreef op dinsdag 24 september 2019 @ 15:18:
[...]

Ja, maar een bedrijf of een persoon is wel een doelwit en dat lijkt mij niet echt de bedoeling. Houd de snippet dan op zn minst privé.

Ik begrijp het probleem niet helemaal. Niemand dwingt je om die snippets te gebruiken. En zowel die user als die shop zijn nogal ongeliefd door de manier waarop ze zich gedragen. Met de topics en de reacties in die topics die dat veroorzaakt is stilletjes verbergen beter voor iedereen, lijkt me.

[XWB]

AW_Bos schreef op dinsdag 24 september 2019 @ 15:30:
[...]

Alleen jammer dat er nu dubbele CSS'en ontstaan.

Alleen de hoeveelheid Henk knopjes al

[NMe]

XWB schreef op dinsdag 24 september 2019 @ 23:02:
[...]

Alleen de hoeveelheid Henk knopjes al

Dat effent zichzelf vanzelf uit zodra mensen daadwerkelijk een van de verschillende oplossingen aanzetten. Uiteindelijk staat er dan eentje bovenaan en is de rest onvindbaar.

[johnwoo]

crisp schreef op dinsdag 24 september 2019 @ 16:31:
[...]

url() kan alleen gebruikt worden met plaatjes van ons eigen domein en @import wordt helemaal niet toegestaan in snippets.

Well yes, but actually no.
Zie de PM die ik je net heb gestuurd

[crisp]

johnwoo schreef op woensdag 25 september 2019 @ 00:49:
[...]

Well yes, but actually no.
Zie de PM die ik je net heb gestuurd

Thanks! En uiteraard gefixed

[ImNotnoa]

crisp schreef op woensdag 25 september 2019 @ 10:00:
[...]

Thanks! En uiteraard gefixed

Mijn snippets worden op dit moment gebruikt door nét iets minder dan 300 users.

Stel ik krijg het over een paar maanden op mijn heupen en besluit de code van die snippets te vervangen door:

Cascading Stylesheet:

#layout{
  background-image: repeating-linear-gradient(45deg,purple 20px,indigo 60px,blue 110px,green 160px,yellow 200px,orange 240px,red 290px,purple 320px) !important;
}

#contentArea {
    background: rgba(255,255,255,0.4);
}

div.message {
    background: rgba(255,255,255,0.5);
}

* {font-family:"Comic Sans MS", "Delius" !important}

Dan zijn er dus 300 users die al hun snippets bij langs moeten (en de tegenwoordigheid van geest hebben om te beseffen dat het door zo'n snippet komt + de kennis van CSS) om uit te zoeken welke snippet de oorzaak van hun mooie nieuwe lay-out is.

Als ik deze quote straks wijzig staat er iets als "Imnoa wijzigde dit bericht voor xx%"

Is het een idee om css snippets die voor meer dan ??% gewijzigd worden niet meteen actief worden maar eerst een kleine audit krijgen door een modje o.i.d. ?

[crisp]

Imnoa schreef op woensdag 25 september 2019 @ 10:13:
[...]


Mijn snippets worden op dit moment gebruikt door nét iets minder dan 300 users.

Stel ik krijg het over een paar maanden op mijn heupen en besluit de code van die snippets te vervangen door:

Cascading Stylesheet:

#layout{
  background-image: repeating-linear-gradient(45deg,purple 20px,indigo 60px,blue 110px,green 160px,yellow 200px,orange 240px,red 290px,purple 320px) !important;
}

#contentArea {
    background: rgba(255,255,255,0.4);
}

div.message {
    background: rgba(255,255,255,0.5);
}

* {font-family:"Comic Sans MS", "Delius" !important}

Dan zijn er dus 300 users die al hun snippets bij langs moeten (en de tegenwoordigheid van geest hebben om te beseffen dat het door zo'n snippet komt + de kennis van CSS) om uit te zoeken welke snippet de oorzaak van hun mooie nieuwe lay-out is.

Als ik deze quote straks wijzig staat er iets als "Imnoa wijzigde dit bericht voor xx%"

Is het een idee om css snippets die voor meer dan ??% gewijzigd worden niet meteen actief worden maar eerst een kleine audit krijgen door een modje o.i.d. ?

Bij klachten van gebruikers kan een admin je snippet disablen en vervolgens eventueel verdere maatregelen nemen

Ik zie dit dus niets anders dan andere vormen van misbruik op onze site. Je hoeft m.i. ook niet alles 100% met technische maatregelen op te lossen. In de eerste plaats hebben we gewoon vertrouwen in onze gebruikers

[.oisyn]

Probleem is dat het heel lang kan duren voor je erachter komt dat er iets verborgen wordt gehouden.

[Flamesz]

Als een gebruiker nog niet de 4000 karma ingeleverd heeft om custom css te gebruiken, heb je ook geen inzicht in de custom css snippets die beschikbaar zijn.
Is het mogelijk dat de snippets wel te zien maar nog niet te activeren als je nog niet je karma hebt uitgegeven? Dan krijg ik een beter idee van wat ik precies koop.

[Zeehond]

Flamesz schreef op woensdag 25 september 2019 @ 14:19:
Als een gebruiker nog niet de 4000 karma ingeleverd heeft om custom css te gebruiken, heb je ook geen inzicht in de custom css snippets die beschikbaar zijn.
Is het mogelijk dat de snippets wel te zien maar nog niet te activeren als je nog niet je karma hebt uitgegeven? Dan krijg ik een beter idee van wat ik precies koop.

Het is niet zo dat de 4000 karma punten echt van je profiel verdwijnen. Volgens mij hoef je ze enkel behaalt te hebben en kun je de functie activeren, zoals bij jouw het geval is .

[World Citizen]

Zeehond schreef op woensdag 25 september 2019 @ 16:03:
[...]

Het is niet zo dat de 4000 karma punten echt van je profiel verdwijnen. Volgens mij hoef je ze enkel behaalt te hebben en kun je de functie activeren, zoals bij jouw het geval is .

Check, maar ik kan me wel vinden in @Flamesz .

Ikzelf was me helemaal rot aan het zoeken naar de snippit shop, maar kreeg niks gevonden. Toen maar hier gaan neuzen om te kijken of ik iets niet begrijp.

Ik vond in dit topic wat linkjes naar snippits, maar die lopen dood voor mij.

Ondertussen snap ik dat het eerst geactiveerd moet worden, maar echt duidelijk was me dat niet.

Voorstel
- Standaard ergens voor elke user een knop "CSS Snip Store" die sowieso te zien is.
- Snippit link pagina die mij af heeft gevangen voorzien van instructie.

[Flamesz]

Zeehond schreef op woensdag 25 september 2019 @ 16:03:
[...]

Het is niet zo dat de 4000 karma punten echt van je profiel verdwijnen. Volgens mij hoef je ze enkel behaalt te hebben en kun je de functie activeren, zoals bij jouw het geval is .

Oh echt, aparte soort winkel dan, prijskaartjes zijn voor de sier haha.
Dan zal ik het maar eens activeren, kan ik zien wat voor nuttigs er al gemaakt is.

[.oisyn]

Flamesz schreef op woensdag 25 september 2019 @ 16:28:
[...]


Oh echt, aparte soort winkel dan, prijskaartjes zijn voor de sier haha.

Niet helemaal. Althans, ik weet niet hoe het tegenwoordig is, maar voorheen moest je het weldegelijk kopen met je karmapunten. En met die gebruikte karmapunten kon je dan niet meer iets anders kopen. Je punten in je "portemonnee" is dus niet gelijk aan de karma in je profiel. Maar elk nieuw verdiend karmapunt kwam er ook in je portemonnee bij.

[Hero of Time]

Het was idd altijd zo dat je X karma had en Y kon 'besteden' of eerder 'toekennen' voor bepaalde extra's zoals custom css. Wat Y was, was afhankelijk van je bijdragen de afgelopen Z tijd.

Maar ik vind het dan weer zo raar dat custom css, en daarbij dus ook deze snippet feature, nog steeds 'betaald' is. Er was zo enorm veel kritiek over het nieuwe uiterlijk van de FP en het standaard antwoord was "gebruik maar custom css". De suggesties om het 'gratis' te maken zijn dus niet eens doorgevoerd.

Is er een issue met het uiterlijk, wordt je doorverwezen naar custom css. Nu wordt er met redelijk wat trots snippets aangeprezen en is het nog steeds niet door alle gebruikers te gebruiken. Jammer.

[World Citizen]

Hero of Time schreef op woensdag 25 september 2019 @ 20:12:
Het was idd altijd zo dat je X karma had en Y kon 'besteden' of eerder 'toekennen' voor bepaalde extra's zoals custom css. Wat Y was, was afhankelijk van je bijdragen de afgelopen Z tijd.

Maar ik vind het dan weer zo raar dat custom css, en daarbij dus ook deze snippet feature, nog steeds 'betaald' is. Er was zo enorm veel kritiek over het nieuwe uiterlijk van de FP en het standaard antwoord was "gebruik maar custom css". De suggesties om het 'gratis' te maken zijn dus niet eens doorgevoerd.

Is er een issue met het uiterlijk, wordt je doorverwezen naar custom css. Nu wordt er met redelijk wat trots snippets aangeprezen en is het nog steeds niet door alle gebruikers te gebruiken. Jammer.

Een "incentive"

Ik kan me er wel in vinden. Als je input levert, dan kun je features unlocken.

Dit moedig ik wel aan. Het stimuleert gebruikers om een beetje met de regels mee te spelen en een niveau te houden wat informatief is.

Ik hoop zelfs dat we ooit naar een tijd gaan waar ik een abbo kan verdienen met Karma. Ik lever relatief niet zo veel op in mijn eentje aan advertenties, dus wellicht is het handiger om inzet die waardevol is te belonen met karma en "Diamond features"
(laat ik dit in contex zetten: Ik wil wel meer doen)

Het fotoalbum was voor mij ooit zo een feature. Ik was kennelijk al actief genoeg om het te unlocken, maar indertijd voelde ik wel de stimulatie.

[crisp]

World Citizen schreef op woensdag 25 september 2019 @ 16:16:
[...]


Voorstel
- Standaard ergens voor elke user een knop "CSS Snip Store" die sowieso te zien is.
- Snippit link pagina die mij af heeft gevangen voorzien van instructie.

Ik denk dat dat wel vrij makkelijk te realiseren is. Ik zal het intern eens bespreken

[LA-384]

Ik heb op de frontpage alle elementen verborgen, behalve de nieuwsitems en de poll. Is er een manier om de poll naast het nieuws te krijgen? En welke css code hoort daarbij?

Ik weet dat de frontpage is opgedeeld in blokken, kan ik de blokken van positie veranderen of content naar een ander blok verplaatsen? Dat zou het oplossen volgens mij.

[crisp]

LA-384 schreef op woensdag 25 september 2019 @ 20:50:
Ik heb op de frontpage alle elementen verborgen, behalve de nieuwsitems en de poll. Is er een manier om de poll naast het nieuws te krijgen? En welke css code hoort daarbij?

Ik weet dat de frontpage is opgedeeld in blokken, kan ik de blokken van positie veranderen of content naar een ander blok verplaatsen? Dat zou het oplossen volgens mij.

Dat soort vragen kan je denk ik beter in [verzamel] CSS-styles; 'Hoe ziet jouw T.net eruit?' kwijt

[LA-384]

@crisp Ik had idd al gekeken naar een ander topic waar het beter zou thuishoren, maar was er nooit opgekomen dat bij "lieve adjes" te vinden. Ik had de topicstart ook niet gelezen, mijn fout.

[World Citizen]

By design?

Want ik zou graag documentatie willen meegeven. Beetje ITIL aanpak natuurlijk.
Ow en een hele opmaak met styling is natuurlijk helemaal tof.

[ Voor 14% gewijzigd door World Citizen op 02-10-2019 19:25 ]

[Hero of Time]

Dan gooi je toch comments in de code met '/* blaat */' om aan te geven wat de stukjes code doet? Wie gaat nou zo'n lange beschrijving lezen? Het is meer bedoelt om kort (!) te omschrijven wat het doet, niet om een boekwerk aan documentatie erin te zetten.

[World Citizen]

Hero of Time schreef op woensdag 2 oktober 2019 @ 19:42:
Dan gooi je toch comments in de code met '/* blaat */' om aan te geven wat de stukjes code doet? Wie gaat nou zo'n lange beschrijving lezen? Het is meer bedoelt om kort (!) te omschrijven wat het doet, niet om een boekwerk aan documentatie erin te zetten.

Dat is inderdaad niet eens zo een gek plan.
Dank!

[Hero of Time]

Het is een veel gebruikte 'oplossing' in de programmeerwereld om aan anderen duidelijk te maken wat je met dat stuk code doet. Kijk maar eens in het LA topic voor CSS, je ziet het veelvuldig gebruikt worden. Ik gebruik het veel om aan te geven waar iets wordt aan/toegepast.