Google Chrome 90 laat gebruikers links naar gemarkeerde tekst delen

Google Chrome 90 krijgt een functie waarmee gebruikers een stuk tekst in een webpagina kunnen markeren, en vervolgens een link delen die naar dat gedeelte van de website verwijst. De functie was sinds vorig jaar al beschikbaar in de testversie van Chrome.

De functie wordt momenteel uitgerold naar de desktop- en Android-versies van Chrome, laat Google weten in een blogpost. Google Chrome voor iOS krijgt de feature op een later moment. De functie is nog niet beschikbaar voor alle Chrome-gebruikers. Tweakers heeft de functie nog niet kunnen testen in de releaseversie van de webbrowser.

Gebruikers kunnen de functie gebruiken door een stuk tekst te markeren, daarop te klikken met de rechtermuisknop, en vervolgens op 'Link naar markering kopiëren' te klikken. Gebruikers kunnen deze link vervolgens doorsturen naar andere Chrome-gebruikers. Wanneer zij de link openen, worden ze automatisch naar het specifiek gemarkeerde stuk tekst gestuurd, in plaats van naar het begin van de pagina.

Deze functie is niet geheel nieuw. Google bracht eerder al een Chrome-extensie uit, genaamd Link to Text Fragment. Deze extensie biedt vrijwel exact dezelfde functionaliteit. Dezelfde feature werd vorig jaar al toegevoegd aan de Canary-versie van Chrome. Nu de feature in de webbrowser zelf zit geïntegreerd, hoeven gebruikers echter niet langer extra dingen te installeren om de functie te gebruiken.

Google brengt verder een nieuwe pdf-viewer voor de Chrome-browser uit in versie 90. Deze krijgt een nieuwe weergavemodus die twee pagina's toont. De toolbar wordt ook vernieuwd en laat gebruikers inzoomen, snel van pagina wisselen, en opslaan of uitprinten met een enkele knop. De blogpost noemt verder prestatieverbeteringen in Chrome, die de ontwikkelaars in versie 89 al hebben doorgevoerd.

Afbeelding via Google

Reacties (45)

[xoniq]

Hoe gaat dat als iemand vanuit Chrome een dergelijk iets deelt, maar ik bijv Safari of Firefox gebruik? Die zal - lijkt me - niet weten wat ie ermee moet qua de positie van dat stukje tekst..

[Tassadar32]

Volgens mij word de tekst in de url verstopt met een parameter. Safari of andere browsers zullen dit negeren.

[Peter]

Deze functionaliteit is op basis van het Text Fragments standaardisatie voorstel. Microsoft is een voorstander van de functionaliteit, waar Safari vragen heeft, maar geen sterke bezwaren. Naarmate gebruik toeneemt zal het voor andere browsers interessanter worden om ook ondersteuning toe te voegen. Browsers die geen ondersteuning bieden zullen dit gewoon negeren.

[elmuerte]

En dit is de manier waarop Google hun macht misbruikt om een "standaard" er door te drukken.
Er zijn nog vele issues open op dit proposal: https://github.com/WICG/scroll-to-text-fragment/issues
Maar nu Google het gewoon in gaat voeren zal de rest (en de standaard) moeten volgens op de manier waarop Google het geïmplementeerd heeft.

[Peter]

Microsoft heeft ten tijde van Internet Explorer 5.5/6 ongelooflijk veel functionaliteit geïntroduceerd. Apple heeft die rol daarna opgepakt met de grafische HTML5 APIs: Canvas API, Transforms, Animations. Mozilla heeft met hun werk voor Firefox OS de grondlegging gelegd voor veel van de moderne device APIs. Google heeft nu het stokje overgenomen, waarbij de deelname van andere browsers actiever is dan ooit tevoren.

De verschillende browsers hebben verschillende motivaties en doelgroepen, en je ziet dit terug in waar ze investeren. We (Google/Chrome) hebben een flink proces om dit op een verantwoordelijke manier te kunnen doen, en doorgaans gaat dat goed. Er zijn ook voldoende voorbeelden waarbij we onze rommel opruimen waar het niet goed gaat .

Het zou fantastisch zijn als je ideeën hebt over hoe dit beter aangepakt zou kunnen worden, ik denk supergraag met je mee!

[jimshatt]

Niet eens Netscape Navigator noemen...

[TheVivaldi]

Of de oude Opera, die in de jaren 90 al een aantal functies introduceerde die we vandaag voor lief nemen.

[batjes]

Het verschil is wel, vroeger had je 3-4 actieve partijen die features aandroegen. Ten tijde van IE 5.5/6 heeft MS inderdaad heel veel aangedragen (waarvan veel is uitgesteld tot HTML5). Maar Mozilla, Opera en Sun droegen ook nog genoeg standaarden bij.

Later is Apple daar bij gekomen en heeft Sun het W3 strijdtoneel verlaten, maar je had nog steeds 4 grote partijen die hun bijdrage leverde en hun mening deelde. Deze partijen hielden elkaar een beetje in balans. Je had aan de ene kant Microsoft en aan de andere kant "de rest van het W3 consortium" muv Apple die hun eigen ding deed/doet. Zo kreeg Microsoft nooit de ontwikkeling van het HTML standaard in handen, ondanks hun ~99% browseraandeel.

Ondertussen neemt Apple de browser markt al jaren niet zo heel serieus, Microsoft is praktisch aan de zijlijn gaan staan en doet ook niet zo veel moeite meer voor standaarden en de browser markt. Die pakken nu Chromium en geven het een eigen sausje. Mozilla is de afgelopen 10 jaar bijna hun hele markt kwijt geraakt aan Google en heeft nog maar weinig directe invloed.

Google is momenteel bijna een alleenheerser voor de HTML standaarden.... Dat is niet gezond en een compleet unieke positie in de browser oorlog geschiedenis. Er is geen tegengewicht meer, alleen Mozilla en die worden gewoon genegeerd door Google.

[GertMenkel]

Klopt, ze stoppen de informatie in het lokale gedeelte van de url (na het hekje) met een speciale prefix (ik de vorm "#:~:text=foo", waar de tekst "foo" wordt gehighlight op de pagina). Firefox, Safari en oude browsers zullen dit voor nu negeren (alhoewel het Mozilla en Apple vrijstaat dit in te bouwen, natuurlijk). Edge, Opera, Brave en Vivaldi zullen het waarschijnlijk gewoon meenemen aangezien ze Chromium-based zijn.

Dit kan nog wel eens een stel webapplicaties slopen die daarvan gebruik maken, maar daar als het goed is, gebruiken die toch de query parameters en niet het fragment van de url.

[TheVivaldi]

Totnutoe werkt deze functie anders nog niet in de recentste Vivaldi-snapshots, ondanks dat die al gebaseerd zijn op Chrome 90.

[xoniq]

Goed punt. De enige manier om het te doen nu ik er zo over nadenk.

[Houtenklaas]

Goeie vraag. Ik verwacht dan iets als: "Alsjemenou, heb jij geen Chrome? Gauw hier klikken dan!" Maar dat is geen goede ontwikkeling als dat zo is, webdingen moeten uniform draaien op alle browsers, maar ik kan me voorstellen dat de grote mannen achter Chrome daar anders over denken. Maar even afwachten hoe dit zit. Chrome versie 90 heb ik inmiddels, maar hier ontbreekt deze feature nog, dat zal wel in een subrelease komen.

[xoniq]

Volgens mij is dit ook echt Chrome 90 -> Chrome 90 inderdaad. Andere (en oudere Chrome) browsers doen dan net als @Tassadar32 al aangeeft, puur de website tonen, en meer niet. Chrome kent dan die argument wel.

[reneflo]

De markering werkt al best een tijdje in chrome nu, weet niet precies vanaf welke versie. Als je bij Google zoeken op een link klinkt wordt dat soms gemarkeerd op die site. Nu wordt het gewoon makkelijker voor gebruikers om zo'n link te maken.

[supersnathan94]

Google amp regelt dit voor je. Daarmee werkt die highlighting ook in Safari zowel op iOS als op macOS.

Ik vind het een welkome functie voor het internet an sich aangezien je quote’s nu heel specifiek kunt “bronvermelden”.

Het probleem met websites is vaak dat ze geen pagina’s kennen in de context zoals een hoek dat heeft. Bladzijde 453 betekent dan gewoon dat je de hele pagina door mag nemen. Met bepaalde artikelen en blogs is dat gewoon niet meer te doen.

[reneflo]

Waarom ik Google AMP liever niet promoot: https://www.reddit.com/r/...did_i_build_amputatorbot/

Dan maar liever de highlighting (voorlopig) alleen werkend op Chrome.

[supersnathan94]

Ja ik heb het liever ook niet. Ik AMPuteer hier mijn linkjes ook, maar dat is dus wel waarom dat in andere browsers ook werkt als je via google een pagina opent.

[P_Tingen]

Dat zal waarschijnlijk net zo zijn als met de plugin link to text. Als je deze link gebruikt in chrome:
nieuws: Google Chrome 90 laat gebruikers links naar gemarkeerde tekst delen
of andere chrome-based browsers, kom je bij jouw bericht uit. Firefox negeert het gewoon en toont het begin van het artikel.

[Luftbanana]

Kan iemand uitleggen of de markering "live" wordt uitgevoerd d.m.v. de tekst-zoekfunctie?

Dus stel dat iemand de gedeelde link een uur later opent, en de betreffende pagina bevat ineens een extra alinea met dezelfde tekst. Is je link dan gebroken omdat het naar een ander gedeelte van de pagina verwijst?

[Jorick]

De link blijft prima functioneel alleen wordt de tekst niet meer gemarkeerd. Browsers die geen ondersteuning hebben voor de Text Fragment Identifier negeren het simpelweg en doen er niets mee. Deze functie zou hooguit voor problemen kunnen zorgen bij sites die de fragment identifier #:~: voor andere doeleinden gebruiken maar erg gebruikelijk is dat niet (#! is een fragment identifier die bijvoorbeeld wel veel wordt gebruikt).

[donleo123]

Hij pakt het eerste stuk tekst wat in de url staat. Voorbeeldje.

Dus ja, zal gewoon blijven werken totdat de tekst niet meer overeen komt.

[Reactie gewijzigd door donleo123 op 22 juli 2024 15:56]

[David Mulder]

Voor de duidelijkheid, "het eerste stukje" pakt hij enkel als er verder geen indicatoren zijn welkje je bedoelt. Met bijv. het gebruik van de prefix en suffix indicator kun je een specifieke match selecteren: nieuws: Google Chrome 90 laat gebruikers links naar gemarkeerde tekst delen
In het bovenstaande geval bijvoorbeeld "Google Chrome gevolgd door het woord 'voor'".

[Rafe]

Mogelijk wel, het hangt er van af hie je precies de doeltekst specificeert. Zie https://web.dev/text-fragments/ voor meer details.

[RobinJ1995]

Met andere woorden, ze doen nu wat Microsoft 15 jaar geleden met Internet Explorer deed; Zelf functionaliteit toevoegen op eigen houtje zodat dingen enkel op hun browser werken, in plaats van via de relevantie werkgroepen gaan om er een webstandaard van te maken.

Nu kan je een link delen vanuit Chrome, die enkel vanuit Chrome doet wat die moet doen. Ik maak nog steeds gebruik van het open web. Niet van Google's internet.

[Reactie gewijzigd door RobinJ1995 op 22 juli 2024 15:56]

[Jorick]

Blijkbaar heb je dan gemist dat ze via de Web Incubator Community Group (relevante werkgroep) een voorstel hebben gemaakt (zie ook https://github.com/WICG/scroll-to-text-fragment). Of dit voorstel het uiteindelijk tot webstandaard gaat halen valt nog te bezien maar de eerste stappen zijn gezet.

[enver63]

Dat is dan een voorbeeld van wat Google al jaren doet in W3C; bestaande standaarden (XPointer, 2003) negeren en zelf met iets komen wat minder mogelijkheden heeft maar meer Google-specifiek is. Het is niet helemaal hetzelfde als Microsoft 25 jaar geleden, maar het idee erachter is hetzelfde.

[Jorick]

Hoe is XPointer relevant in dezen? Dat gaat om een aanbeveling met betrekking tot XML en is hier niet van toepassing. En wat is er precies zo Google-specifiek aan dit Text Fragment voorstel, heb je het wel bekeken?

De vergelijking met Microsofts IE van tig jaar geleden begrijp ik ook niet want de situatie met Chromium is diametraal anders. IE was closed-source terwijl Chromium open-source is. Chromium Edge, Brave, Vivaldi en andere Chromium-gebaseerde browsers laten zien dat het project prima functioneert. Als Google iets introduceert of voorstelt dat anderen niet zint dan slopen ze het er uit of kunnen ze het naar hartenlust aanpassen.

[Reactie gewijzigd door Jorick op 22 juli 2024 15:56]

[enver63]

XPointer is relevant, omdat HTML (5) en XML erg op elkaar lijken wat betreft structuur en markup ('mixed content'), omdat ze van dezelfde familie markup talen afstammen. De inhoud van een XPointer is niet uitsluitend geschikt voor XML, maar is bedoeld voor alle XML-achtige markup talen. In dit geval betekent dat, dat XPointer gebruik maakt van XPath om fragmenten te adresseren, en dat werkt ook prima voor HTML. Wikipedia zegt hierover: "The XPointer language is designed to address structural aspects of XML, including text content and other information objects [...]"

Het gaat dus niet erom of Chromium open source is, maar hoe Google met standaarden omgaat. Google wil niet alleen een leidende rol bij het bepalen van standaarden, maar wil deze aan de hele industrie kuunnen opleggen. Als het kan doet Google dat via W3C, en als dat niet lukt via Chromium en een zelf bedacht standaardisatie-comitee.

Verder is er dus al een standaard die voor een zeer groot deel doet wat "Link To Text Fragment" doet, maar het is :not invented by Google", en zo kunnen we weer eens gaan verwijzen naar XKCD 927.

[Jorick]

Dat XPointer en XPath toegepast zouden kunnen worden betekent niet dat het goede oplossingen zijn voor deze use-case. De DOM doorlopen om naar bepaalde tekst te zoeken gaat sneller met een TreeWalker dan met XPath. Bovendien is de TreeWalker route in iedere browser toe te passen terwijl de browser ondersteuning voor XPath op zijn best wisselvallig te noemen is. Welke versie van de XPath specificatie door browsers ondersteund worden is bijvoorbeeld niet duidelijk. En de gekozen text fragment is in lijn met wat er in de Media Fragments aanbeveling staat dus zo'n vreemde optie is dat niet. Als je het mij vraagt zit je spijkers op laag water te zoeken.

[batjes]

Die project groep wordt geleid door:
Chris Wilson, Google.
Yoav Weiss, Google.
Travis Leithead, Google Microsoft.
Léonie Watson, Google.

Hahaha. Nee, goed punt hoor. Een project groep dat gerunt wordt door enkel en alleen voornamelijk Google medewerkers.

[Reactie gewijzigd door batjes op 22 juli 2024 15:56]

[Jorick]

Als je de moeite had genomen om je eigen bron wat beter te bekijken dan kun je zien dat Travis Leithead bij Microsoft werkt en Leonie Watson bij TetraLogical. Daarnaast zijn die vier verkozen door deelnemers van de Community Group, veel democratischer wordt het niet als je het mij vraagt.

Het voorstel dat in de WICG is gedaan is een opmaat naar de Recommendation track waar een W3C werkgroep zich er over gaat buigen. Je doet nu net alsof al die werkgroepen binnen de W3C uit personeel van Google bestaat maar dat is flauwe kul (zie hier). Binnen een werkgroep moet consensus bereikt worden onder de deelnemers dus het is echt niet zo dat Google op eigen houtje standaarden bij de W3C naar binnen kan fietsen.

[batjes]

Ze werkt wel heel veel samen met Google. https://www.tpgi.com/leon...visory-committee-for-amp/
Ook werkt ze met andere projecten bij Google en draagt ze Google medewerkers aan bij het W3.

Travis had ik inderdaad fout, te snel geoordeel op basis van zoekresultaten.

2 zijn dus van Google, 1 praktisch Google en dan 1 van Microsoft.

[TheVivaldi]

Sterker nog: zelfs al zóu het waar zijn, dan blijkt nog steeds dat er voldoende tegenwicht is gezien die verkozen Google-medewerkers dus niet zomaar alles accepteren wat hun 'baas' voorstelt.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 15:56]

[RobinJ1995]

"We kunnen misschien dit doen, wat denken jullie?" terwijl je vinger al op de lanceerknop gedrukt staat is wel nog nét wat anders.

[jcbvm]

Versie 90 is toch al gereleased?

[Ashketchum22]

Kan toch een subversie voor een main release zijn?
Hij is inderdaad de 15e uitgebracht want ik heb hier de artikel kop nog in beeld dat Google hem gerelease heeft.

[Rutger Muller]

Gaat dit niet linea recta tegen de open principes van het WWW in?

Ik bedoel, het www is zo goed omdat bijv. hyperlinks universeel werken. Browser-exclusieve features – of beter gezegd browser-buitensluitende features – lijken mij een slecht idee. Niet dat dit concept opzich slecht is, maar kan dat niet beter eerste overlegd worden middels het W3C consortium of iets dergelijks?

[Reactie gewijzigd door Rutger Muller op 22 juli 2024 15:56]

[mae-t.net]

Denk het niet, het gaat om een aanvulling die zelf ook open is en als het goed is geen bestaande functionaliteit breekt.

[gimbal]

De ontwikkeling van het web druist sinds web 2.0 al redelijk in tegen de originele principes. Informatie is vluchtig in plaats van persistent, pagina's worden dynamisch opgebouwd met een scripttaal in plaats van dat het statische documenten zijn, css is inmiddels een halve programmeertaal geworden, web api's geven steeds meer toegang tot de lokale machine in plaats van dat de browser een thin client is, etc. etc.

Je houdt vooruitgang niet tegen.

[Rutger Muller]

"Je houdt vooruitgang niet tegen." Mee eens, je kan het slechts proberen wat bij te sturen.

Misschien brengt client-sided AI wel nog een paradigma-verschuiving, omdat je daarmee bijv. "alles" kan gaan blokkeren/transformeren wat je maar wil, als het lokaal gebeurt. Naja niet alles natuurlijk, tracking en dergelijken zijn dan al gedaan. Maar toch. Daarom zal er uiteindelijk ook wel een steeds grotere focus op apps komen te liggen ipv het www, omdat binnen apps adblocking niet mogelijk is (zie waar Youtube en Reddit op aan sturen).

Ik ben benieuwd waar het allemaal heen gaat. Veel gemengde gevoelens .

[Reactie gewijzigd door Rutger Muller op 22 juli 2024 15:56]

[Anoniem: 377399]

dit is gewoon de reïncarnatie van de postit-notes functionaliteit van jaren geleden. je stuurt een link met 'hi-liter functionaliteit' door, waardoor de ontvanger ook door Google kan worden gevolgd

[Prosperot]

Het zal aan mij liggen, maar op mn mac met Chrome Versie 90.0.4430.72 (Officiële build) (x86_64) zit deze functie niet.

[TheVivaldi]

Dat za inderdaad aan jou liggen, want zelfs hier in de recentste Vivaldi-snapshot op basis van Chrome 90.0.4430.58 zit de functie (al werkt 'ie nog niet).

[Bruin Poeper]

Waarom alleen naar links? Het zou ook naar rechts moeten kunnen.

[Randleman]

MSM