> We can't prevent people from digging into "opaque" structures, or > reimplementing render-link for their own code in a potentially > incompatible or may-be-incompatible-in-future way. We can only say that > doing so isn't supported.
When we know that an opportunity to mess with opaque structures/protocols is attractive then we should strive to detect the user messing about in there. >>> Trill. Essentially "symbiosis": the action cannot live without its >>> widget. >> >> Now I could've thought of that... > > Trill, or symbiosis? ;) The former one. :) > However, this is not friendly-URL-compatible. The gold standard for a > friendly URL here is to only record the result item type and ID. For > example, a Trac ticket is reached via /ticket/<ticket#>. Recording > search information makes the URL less friendly, because query-strings > are bad for Googleness. Are they? I'm not so sure of that. IME Google will handle query strings just fine. > So there is a conflict betweenuser-friendliness and Google-friendliness. For me friendly in the context of URLs just means that I can bookmark and copy them easily to others. > I'm not against people providing selectors that accept friendly or > permanent URLs (e.g. the "Link" link on Google Maps). I'm against the > practices of the Internet forcing web developers to cater to search > engines rather than users. Considering our different original interpretations we're on the same page now. >>> I would rather add a little complexity to make it more acceptable and >>> have it on by default. >> >> +1. > > I'm just not sure what that complexity should be. We can't determine > when an action would no longer work, for example. Still not sure where it might happen that a dead URL is invoked; the only case I can think of is having multiple views of a page/widget; but in this case we're fully desynchronized anyway (that's another problem domain). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
