| 00:11 | <Hixie> | benschwarz: here |
| 00:11 | <Hixie> | benschwarz: commented on the post |
| 01:10 | Hixie | makes some slight changes to the top of the spec |
| 01:10 | jtcranmer | stares cross-eyed at the streams spec |
| 03:15 | <SamB> | Hixie: ... interesting choice of mode for the html spec ... |
| 03:28 | <MikeSmith> | wow that's a lot of green boxes |
| 03:28 | <MikeSmith> | I like how you've gone with the Japanese spelling of "developers" there in the URL |
| 03:46 | <SamB> | fatal: repository 'https://bitbucket.org/ms2ger/anolis/'; not found |
| 03:46 | <SamB> | :-( |
| 04:12 | <Hixie> | SamB: yeah... i think it needs something else... but what we had before was worse, so... |
| 04:12 | <Hixie> | SamB: any ideas? |
| 04:13 | <SamB> | Hixie: not really |
| 04:13 | <Hixie> | :-( |
| 04:13 | <Hixie> | same here |
| 04:13 | <Hixie> | MikeSmith: oops :-) fixed |
| 05:05 | <SamB> | <dt>An end tag whose tag name is "sarcasm"</dt> |
| 05:05 | <SamB> | ;-) |
| 08:01 | <annevk> | Can someone take a look at https://github.com/w3c/web-platform-tests/issues/923 maybe? |
| 08:06 | <jgraham> | annevk: Why? |
| 08:07 | <annevk> | jgraham: seems to be blocking someone attempting to implement minlength |
| 08:08 | <jgraham> | OK. Not sure I know the editing stuff well enough to know theright fix |
| 08:08 | <annevk> | jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=932755 |
| 08:09 | <birtles> | annevk, jgraham: I'm trying to set up a folder for web-animations on web-platform-tests. Do I have to do anything to be able to review pull requests to that folder? |
| 08:09 | <birtles> | I sent a pull request last week (https://critic.hoppipolla.co.uk/r/1302) although I should probably tweak those tests a bit |
| 08:10 | <annevk> | Hey birtles, I don't really know, I think jgraham and/or darobin can set you up |
| 08:10 | <birtles> | annevk: cheers |
| 08:11 | <jgraham> | birtles: You don't need anything to be able to review PRs, although obviously reviewing your own PR isn't normal :) |
| 08:11 | <annevk> | birtles: out of curiosity, how did you guys settle the second vs microsecond debate? |
| 08:11 | <birtles> | jgraham: ok, so maybe I can just ask one of the other editors/implementors to review it |
| 08:11 | <birtles> | annevk: yeah, milliseconds it is |
| 08:11 | <birtles> | it's fixed in the spec, being patched in blink and polyfill |
| 08:12 | <birtles> | annevk: oh *how*, basically we just did what the tag told us |
| 08:12 | <annevk> | birtles: was more interested in the former :-) |
| 08:13 | <birtles> | annevk: former = seconds? what the resolution was? |
| 08:15 | <annevk> | birtles: I was interested in what you settled on, sorry for the confusion |
| 08:15 | <birtles> | k |
| 08:20 | <jgraham> | birtles: Have some review |
| 08:21 | <birtles> | jgraham: thanks! |
| 10:08 | <jgraham> | So you don't actually need user interaction to set the dirty flag on form controls, right? |
| 10:08 | <jgraham> | In which case all the execCommand stuff is unneeded |
| 10:21 | <zcorpan> | setting .value makes it dirty |
| 10:22 | <zcorpan> | but maybe not for checkboxes? |
| 10:23 | <jgraham> | Pretty sure what's already there doesn't work for checkboxes either |
| 10:26 | <jgraham> | In unrelated news, it looks like the unload-a-document tests are now the most unstable web-platform-tests |
| 10:27 | <jgraham> | In gecko at least |
| 10:27 | <jgraham> | (although not *only*) |
| 10:27 | <jgraham> | It looks a lot like the session storage is sometimes dirty |
| 10:27 | <jgraham> | Could replace that with a server-side script I guess |
| 10:28 | <jgraham> | Or maybe just use a unique token for each run |
| 10:28 | <jgraham> | Although I am not really sure this is the problem |
| 10:52 | <zcorpan> | i thought navigation was already interoperable and doesn't need tests |
| 10:53 | <jgraham> | Hmm? |
| 10:55 | <jgraham> | In yet more news |
| 10:55 | <jgraham> | It is very frustrating |
| 10:55 | <jgraham> | There are quite a few tests depending on w3c-test.org |
| 10:55 | <jgraham> | Which need to be fixed |
| 10:56 | <jgraham> | But the rabbit hole goes deeper as some of the tests turn out to believe they are running on port 80 |
| 10:56 | <jgraham> | And fixing this is taking too much time |
| 11:04 | <jgraham> | These dnd tests, for example, are soul-crushing |
| 11:04 | <jgraham> | wilhelm: I blame you :p |
| 11:38 | <zcorpan> | jgraham: http://w3cmemes.tumblr.com/image/32354094056 |
| 11:43 | <jgraham> | zcorpan: Sure, but why did you mention it now? unload-a-document? |
| 11:43 | <jgraham> | Those are websockets tests |
| 11:43 | <jgraham> | Although depend on navigation |
| 11:43 | <zcorpan> | jgraham: yeah |
| 11:43 | <jgraham> | Ah, OK |
| 11:44 | <hsivonen> | annevk: what's the twitter handle for Encoding Standard? I thought @encoding, but it looks like it's not it. |
| 11:44 | <zcorpan> | hsivonen: http://encoding.spec.whatwg.org says it's https://twitter.com/encodings |
| 11:45 | <hsivonen> | zcorpan: thanks |
| 11:52 | <wilhelm> | jgraham: I blame Tarquin! |
| 12:13 | <jgraham> | TabAtkins: Looks like https://critic.hoppipolla.co.uk/r/1364 is one for you once zcorpan has finished it? |
| 12:20 | <zcorpan> | now i wonder why http://w3c-test.org/submissions/927/selectors/attribute-selectors/attribute-case/syntax.html doesn't show up |
| 12:20 | <zcorpan> | MikeSmith: ^ |
| 12:32 | <MikeSmith> | zcorpan: dunno but maybe the script is wedged |
| 12:33 | <MikeSmith> | maybe you don't have the right perms |
| 12:33 | <MikeSmith> | it says you're just Collaborator |
| 12:34 | <MikeSmith> | hmm something borked |
| 12:55 | <MikeSmith> | zcorpan: github logs show the hook ran successfully |
| 12:55 | <zcorpan> | MikeSmith: weird |
| 12:58 | <MikeSmith> | grepping the log file is made more difficult by the fact it's full of binary data |
| 13:01 | <MikeSmith> | hmm log seems to indicate it's not gettin the signature it expects |
| 13:02 | zcorpan | *poof* |
| 13:19 | <annevk> | Haha, my landlord is such a troll. Finally replies after months, asks for a swift reply |
| 14:07 | <zewt> | browsers need an option to force session cookies to be regular persistent cookies |
| 14:07 | <zewt> | the concept doesn't even make sense now, i keep browser windows open for a month at a time, so it just means i have to log into a bunch of random sites for no good reason after i restart the browser |
| 14:08 | <zewt> | that or the browser could persist the session cookies when it restores tabs, i guess |
| 14:45 | <annevk> | JakeA: it seems we forgot about form-action |
| 14:46 | <JakeA> | annevk: As a context? |
| 14:46 | <annevk> | JakeA: yes |
| 14:46 | <JakeA> | annevk: Ahh yes, we need that |
| 14:46 | <JakeA> | annevk: Can you make a ticket for that? |
| 14:46 | <annevk> | JakeA: I guess I'll add it to Fetch and then whenever you sync with Fetch... |
| 14:46 | <JakeA> | annevk: +1 |
| 14:46 | annevk | is reviewing CSP to make sure CSP integrates with Fetch |
| 14:47 | <annevk> | Hopefully that makes it easier down the line to evaluate how SW fits into all this |
| 14:51 | <annevk> | frame-ancestors seems somewhat tricky too |
| 15:25 | <dglazkov> | good morning, Whatwg! |
| 15:33 | <annevk> | JakeA: emailed some questions related to this to public-webappsec |
| 15:34 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#concept-fetch has a placeholder hook for CSP now |
| 15:34 | <annevk> | JakeA: next I guess is placeholder hooks for SW |
| 15:34 | <JakeA> | annevk: This is really cool. I can't imagine the amount of crawling through implementations and specs went into this |
| 15:52 | <smaug____> | annevk: xhr.responseURL isn't in anyway bound to http, right? |
| 15:53 | smaug____ | is reviewing something |
| 15:53 | <annevk> | smaug____: no |
| 15:55 | <annevk> | smaug____: it's the "final request url" basically |
| 15:56 | <annevk> | smaug____: adjusted for redirects and HSTS |
| 15:56 | <smaug____> | annevk: with data: it would be just the url |
| 15:56 | <smaug____> | and so on |
| 15:56 | <annevk> | yup |
| 15:57 | <smaug____> | for some reason the patch limited it to http(s) |
| 15:58 | <annevk> | it'd be interesting to hear why he/she did that |
| 15:59 | <smaug____> | I guess because there happened to be nice helper method to get httpchannel :) |
| 16:00 | <smaug____> | (this might be his second patch or so) |
| 16:00 | <annevk> | Hopefully one day Fetch is actually a module in browsers |
| 16:01 | <annevk> | Servo could do it right |
| 16:01 | <annevk> | And then the other browsers get jealous |
| 16:01 | <annevk> | And then ... and then profit |
| 16:04 | <jgraham> | annevk: Well that doesn't obviously seem to be the way that servo is going |
| 16:05 | <jgraham> | It seems to be relying on some third-party lib for the network bits, and I guess that won't implement Fetch directly |
| 16:06 | <annevk> | jgraham: I think at this point they are probably not implementing much of data/blob/http handling correctly, let alone things like CSP and such |
| 16:06 | <jgraham> | annevk: They aren't, but I don't know of plans to implement their own http |
| 16:08 | <jgraham> | Basically I think no one is really working on the network layer in servo, so expecting it to come out matching specs that people outside the web community might be unaware of seems optimistic |
| 16:12 | <annevk> | Sooner or later they'll run into questions as to how bits of XMLHttpRequest need to work and learn |
| 16:12 | <annevk> | Not too worried about that. The reason Servo can do this is because they don't have extension complexity |
| 16:21 | <jgraham> | Well XHR is supposed to be done this summer by a GSoC student, so we'll see how that pans out |
| 16:27 | <daurnimator> | sigh; so apparently localStorage in Safari private browsing doesn't work |
| 17:34 | <KevinMarks_> | has anyone done a survey of what ids look like on the web in the wild? Like Hixie did for classes? |
| 17:35 | <KevinMarks_> | come to that, what fragment links look like on the web too? I bet the dominant one is just # |
| 17:37 | <paul_irish> | KevinMarks_: for back-to-top ? |
| 17:38 | <KevinMarks_> | no, all the pretend links put in to be overridden by js |
| 17:38 | <paul_irish> | Ah yes. :) For sure. |
| 17:38 | <jory> | I'd be really surprised is something other than '#' turned out to be the choice of most people. |
| 17:39 | <KevinMarks_> | how do you mean, jory? |
| 17:40 | <jory> | In almost every project I've worked on where we've wanted to use anchors but have their behaviour completely dictated by the JS, we've used '#' as the href. |
| 17:40 | <KevinMarks_> | I'm probably being unclear - I meant grepping a decent chunk of the web for links with fragments in, and seeing what the fragments look like |
| 17:41 | <jory> | Ooo, sounds like an interesting study. I'd love to see the results of something like that. |
| 17:41 | <KevinMarks_> | that, combined with a survey of what actual IDs look like |
| 17:43 | <KevinMarks_> | (I'm getting at the fragmention by default idea here) http://www.kevinmarks.com/poemfragmentions.html##cannot+contain |
| 18:32 | <jcgregorio> | KevinMarks: Why the space character as the trigger, aren't there a bunch of characters that are valid after the hash that aren't valid in an ID? |
| 18:33 | <KevinMarks_> | I thought so, but nope. IDs can have anything in except a space |
| 18:33 | <KevinMarks_> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute |
| 18:33 | <KevinMarks_> | see the note in green |
| 18:34 | <KevinMarks_> | you could put %20 in an id I suppose but that's still OK |
| 18:35 | <KevinMarks_> | it's actually the other way round - fewre valid chars in a fragment, but you can escape them reliably |
| 18:36 | <KevinMarks_> | basically, I made up the syntax before reading the specs, then realised that I could make it even simpler |
| 18:37 | <KevinMarks_> | ## makes a URL invalid per http://tools.ietf.org/html/rfc3986#appendix-A |
| 18:41 | <jcgregorio> | wow, that's a surprising, and a pain, space is your only escape hatch |
| 18:42 | <KevinMarks_> | actually, I think it's good and simplifying. |
| 18:43 | <jcgregorio> | well, if you gobble up any space for fragmentations then there's no more escape hatches |
| 18:45 | <jcgregorio> | for example, {} aren't valid in a URI, they were reserved for future expansion |
| 18:45 | <jcgregorio> | and we used them in URI Templates |
| 18:45 | <KevinMarks_> | in fact, you don't even need a space, as you can tell if it's an ID quickly... |
| 18:45 | <jcgregorio> | and in URI Templates = ! @ | and , are reserved for future extensions in URI Templates |
| 18:47 | <jcgregorio> | right, but what if after fragmentations ships someone comes up with another cool idea |
| 18:47 | <jcgregorio> | how would they differentiate between a fragmentation and their cool new thing |
| 18:48 | <jcgregorio> | I would suggest having fragmentations start with +! and leave other fragments that start with +<some other char> as a future extension point |
| 18:52 | <KevinMarks_> | I think #! fragments are already used for various things |
| 18:53 | <jcgregorio> | ok +%, you get the idea :-) |
| 18:53 | <KevinMarks_> | and searching for ! or % is a bit of a weird case |
| 18:53 | <jcgregorio> | +: |
| 18:54 | <jcgregorio> | true, but you could still do it, +!!, if you use ! as your character |
| 19:10 | <JonathanNeal> | KevinMarks_: messed with http://sandbox.thewikies.com/fragmentions/example.html since the changes? jcgregorio: i like what you’re saying about closing all of the escape hatches. |
| 19:10 | <KevinMarks_> | I don't think we are though |
| 19:11 | <KevinMarks_> | currently ID eats all possible fragments iff it exists. Fragmention catches some more cases |
| 19:11 | <KevinMarks_> | still room for other things to catch still more |
| 19:11 | <JonathanNeal> | Hmm, I agree. |
| 19:15 | <KevinMarks_> | we'll only catch ! or * or whatever in a fragment if both someone makes such a fragment AND the body contains that character sequence |
| 19:15 | <JonathanNeal> | I just had not thought of it that way. |
| 19:30 | <jcgregorio> | KevinMarks: what's a case that wouldn't be an id nor a fragmentation? |
| 19:30 | <jcgregorio> | I think I see what you are saying, in that something being an id or fragmentation is context dependent, depending on what's on the page |
| 19:30 | <jcgregorio> | but that's no way to write a spec ;-) |
| 19:31 | <KevinMarks_> | any sequence that isn't in the document |
| 19:31 | <KevinMarks_> | fragmention BTW (i think you're being autocorrected) |
| 19:31 | <Domenic_> | Woah a wild Hixie appears on Twitter! |
| 19:32 | <Hixie> | hm? |
| 19:32 | <Hixie> | i've posted 6 times this month |
| 19:32 | <Hixie> | that's more times than i've posted publicly on g+ in the same time frame |
| 19:33 | <Hixie> | 7 times on twitter in february |
| 19:34 | <Domenic_> | This was the first one that was @-ed to someone I follow |
| 19:34 | <Domenic_> | so the first one I saw |
| 19:35 | <Hixie> | aah |
| 19:35 | <Hixie> | yeah i basically only use it to reply to people |
| 19:35 | Hixie | thinks the 140 character limit is absurd |
| 19:36 | <jcgregorio> | KevinMarks: autocorrected by my own fingers :-) |
| 19:37 | <Hixie> | ok. compare the top of http://www.whatwg.org/specs/web-apps/current-work/multipage/ to the top of http://www.whatwg.org/specs/web-apps/current-work/ |
| 19:37 | <Hixie> | poll: which do you prefer? |
| 19:37 | <Hixie> | bonus question: do you have any better ideas for making this more approachable? |
| 19:38 | <Domenic_> | I prefer the multipage version because it's loaded whereas the singlepage version is still blank ;) |
| 19:38 | <Hixie> | yeah well i mean aside from that :-P |
| 19:39 | <Domenic_> | Hmm this is nicer. Hard to say. |
| 19:39 | <jcgregorio> | Hixie: maybe color code for function? |
| 19:39 | <Hixie> | jcgregorio: good idea. which colours for which buttons? |
| 19:40 | <jcgregorio> | irc, twitter and mailing list in blue |
| 19:41 | <jcgregorio> | file a bug, open bugs, and email the editor in red |
| 19:41 | <KevinMarks_> | jcgregorio: there's already a multistage reolution algorithm here: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document |
| 19:42 | <KevinMarks_> | so before #8, we insert fragmention processing to find the target be searching the text for the decoded fragid and picking the smallest containing element |
| 19:43 | <KevinMarks_> | so you can't currently use "top" as a fragmention |
| 19:43 | <KevinMarks_> | and any other future ones can insert themselves there |
| 19:44 | <Hixie> | jcgregorio: trying that, thanks... |
| 19:45 | <jcgregorio> | Hixie: and all the versions multipage/onepage/pdf/dev as another color |
| 19:45 | <jcgregorio> | sorry, I run out of ideas outside of the three primary :-) |
| 19:45 | <Hixie> | :-) |
| 19:46 | <Hixie> | i tried using https://kuler.adobe.com/create/color-wheel to pick the colours, but they seem kinda ugly |
| 19:46 | <KevinMarks_> | funny how all chat-related things are blue |
| 19:46 | <Hixie> | (using "whatwg green", 3C790A, as the base) |
| 19:47 | <Hixie> | hm, actually, it does kinda work |
| 19:47 | <TabAtkins> | KevinMarks_: Dont' pay any attention to 3986. Read the URL spec isntead. |
| 19:47 | <Hixie> | jcgregorio: http://www.whatwg.org/specs/web-apps/current-work/ |
| 19:48 | <TabAtkins> | KevinMarks_: http://url.spec.whatwg.org/ |
| 19:48 | <KevinMarks_> | fair, TabAtkins, but the same is true there |
| 19:48 | <TabAtkins> | All right, cool. Didn' |
| 19:48 | <TabAtkins> | Just didn't want you looking at the wrong thing. ^^; |
| 19:49 | <KevinMarks_> | a fragment can have http://url.spec.whatwg.org/#url-code-points which don't include # |
| 19:49 | <KevinMarks_> | so my ## is still invalid |
| 19:49 | <KevinMarks_> | derp |
| 19:49 | <KevinMarks_> | even though browsers seem to parse ti happily |
| 19:51 | <jcgregorio> | Hixie: http://tinyurl.com/mh3za2q |
| 19:51 | <jcgregorio> | my attempt at a pallette |
| 19:51 | <Hixie> | jcgregorio: yeah, i was just playing with it again and came to more or less the same one |
| 19:51 | <jcgregorio> | :-) |
| 19:51 | <Hixie> | ok, orange, i guess, for the remaining ones. and green for the versions. |
| 19:53 | Hixie | regens |
| 19:57 | <Hixie> | jcgregorio: http://www.whatwg.org/specs/web-apps/current-work/ look ok? |
| 19:57 | <KevinMarks_> | looks a bit like http://www.wired.com/images_blogs/threatlevel/2009/09/dhs-threat1.jpg |
| 19:58 | <Hixie> | i'd love to find an even better way of doign this |
| 19:58 | <Hixie> | i'm not really happy with it |
| 19:58 | <Hixie> | it's better than the <dl>, but... |
| 19:59 | <jcgregorio> | yeah, I like the idea, but the colors seem a little strong |
| 20:03 | Hixie | tries halving the saturation of each one |
| 20:06 | <Hixie> | no, that doesn't help. maybe halving the lightness... |
| 20:09 | <Domenic_> | Hixie: http://forums.whatwg is not a complete URL |
| 20:09 | <Hixie> | oops |
| 20:09 | <Hixie> | fixed |
| 20:09 | <Hixie> | thanks |
| 20:10 | <KevinMarks_> | no whatwg tld yet? |
| 20:10 | <Hixie> | jcgregorio: what do you think of the current colours? |
| 20:10 | <KevinMarks_> | we're behind .guitars |
| 20:10 | <Hixie> | KevinMarks_: not on this budget ;-) |
| 20:10 | <Domenic_> | current colors seem pretty reasonable |
| 20:11 | <Hixie> | try reloading to make sure you're seeing the current ones |
| 20:11 | <Hixie> | i changed them 3 times in the last 3 minutes |
| 20:11 | <KevinMarks_> | pretty good; the orange is a bit turdy |
| 20:11 | <Hixie> | :-) |
| 20:11 | <Hixie> | KevinMarks_: i don't want to know what you're eating :-P |
| 20:11 | <Domenic_> | "open bugs" sounds like a verb phrase not a noun phrase |
| 20:11 | <jcgregorio> | Hixie: yeah, that's a lot better |
| 20:12 | <Domenic_> | oh hmm these darker ones are interesting |
| 20:12 | <Hixie> | Domenic_: good point |
| 20:12 | <Hixie> | changed to "View Open Bugs" |
| 20:12 | <Hixie> | ok. i'm gonna go with this. |
| 20:12 | <Hixie> | if anyone has any ideas for a more radical change, please do let me know. |
| 20:12 | <Domenic_> | fun times |
| 20:13 | <Domenic_> | do you feel there's value in separating the HTML FAQ from the WHATWG FAQ? |
| 20:13 | <Hixie> | there's an HTML FAQ? |
| 20:13 | <Hixie> | oh you mean the HTML subsectiosn of the WHATWG FAQ? |
| 20:13 | <Domenic_> | Well whatwg.org/faq currently serves as both |
| 20:14 | <Domenic_> | e.g. the HTML spec links to the WHATWG FAQ as "faq" |
| 20:14 | <SamB> | wait, you mean there's a non-HTML section? |
| 20:14 | <Hixie> | nah, i think it's fine. if people have questions about other specs I'm happy for those questions to be in that list too. |
| 20:14 | <Hixie> | we already have too many places to point people to |
| 20:14 | <Hixie> | witness this very long list of buttons |
| 20:14 | <Hixie> | or the whatwg.org home page |
| 20:14 | <Domenic_> | yeah that's fair. |
| 20:14 | <Hixie> | let's not add more :-) |
| 20:15 | <KevinMarks_> | I do have a veggie lasagne that is close to that colour |
| 20:15 | <Domenic_> | I guess things just get a bit confused e.g. "which parts of the spec are stable" and onward inside "The WHATWG Process" are somewhat HTML-specific, whereas the rest of that section is about the WHATWG and Living Standards generally. |
| 20:15 | <Hixie> | yeah that stuff should be cleaned up |
| 20:15 | <Hixie> | feel free to hack at it if you want |
| 20:16 | <Hixie> | i'll get to it eventually otherwise |
| 20:16 | <Domenic_> | When I was reading it for the first time I wasn't clear how much applied to general WHATWG working model vs. HTML only |
| 20:16 | <Domenic_> | I might do that yeah |
| 20:16 | <Domenic_> | do i even have an account? hmm, I've never wanted to add a <meta> tag, so unclear. |
| 20:17 | <Hixie> | e-mail? i'll add you one |
| 20:17 | <Domenic_> | domenic⊙dc |
| 20:17 | <Hixie> | multipage spec is updated, in case anyone lurking was too scared to open the single-page spec but wants to know what we were chatting about :-) |
| 20:18 | <Hixie> | done |
| 20:18 | SamB | wonders about the system requirements of the single-page spec |
| 20:18 | <Hixie> | ok i gotta run before the cafes close. back in a bit. |
| 20:19 | <jcgregorio> | Hixie: the only problem is the illusory dots that appear at the intersections |
| 20:19 | <Hixie> | wow i didn't see those until you pointed them out and now i feel almost ill :-P |
| 20:19 | <Hixie> | yikes |
| 20:19 | <Hixie> | bbl |
| 20:20 | <jcgregorio> | yeah, I didn't see it until I was a little further from the monitor |
| 20:20 | <mathiasbynens> | Hixie: the link to http://validators.whatwg.org/ is broken |
| 20:21 | <SamB> | Hixie: the METAFONTbook has some tips about that ;-P |
| 20:21 | <mathiasbynens> | Hixie: as in, the link works, but the URL doesn’t resolve for me |
| 20:21 | <SamB> | or, well, at least an example |
| 20:37 | <JonathanNeal> | So, on the pros/cons of # versus ## for fragmentions. Pros for # is that its characters are valid, it falls back to ID. Pros for ## is that it is unique, and does not conflict with ID. The con for # is the reserved word "top" and other taken IDs. The con for ## is its invalidity. Thoughts? Disagreements? |
| 20:41 | <jcgregorio> | actually, "con for # is the reserved work "top" and other taken IDs" isn't true because they don't have spaces, right? |
| 20:42 | <JonathanNeal> | jcgregorio: if we made at least one space character a requirement for fragmentions, perhaps. |
| 20:54 | <SamB> | JonathanNeal: what invalidity? |
| 20:54 | <SamB> | I mean, what actually cares? |
| 20:54 | <JonathanNeal> | SamB: page.html##term is invalid because of the ##. The spec and validators care. Browsers do not care. |
| 20:55 | <SamB> | which validotors? regular ones, or just stuff like link checkers? |
| 20:55 | <SamB> | er, *validators |
| 20:56 | <SamB> | JonathanNeal: also is there a thread or a draft this discussion is referring to? |
| 20:56 | <JonathanNeal> | There are at least two, SamB, one is https://github.com/chapmanu/fragmentions |
| 20:57 | <Hixie> | mathiasbynens: thanks, fixed |
| 20:57 | <SamB> | and, er, has anyone mentioned a more powerful mechanism for use on html? |
| 20:57 | <Hixie> | SamB: any idea what the tips are? :-) |
| 21:00 | <SamB> | hmm, what intersections are we talking about here? |
| 21:00 | <zewt> | JonathanNeal: pages might be using ##foo in scripts; don't know how to find out |
| 21:00 | <SamB> | zewt: clearly program the browser to spy on the users |
| 21:00 | <JonathanNeal> | SamB: the other is http://indiewebcamp.com/fragmention |
| 21:00 | <zewt> | duh |
| 21:01 | <zewt> | when I use custom hashes for script navigation i normally run the hash part through encodeURIComponent, which avoids that issue |
| 21:01 | <zewt> | JonathanNeal: if there is some unused part of the URL hash space to be used, i'd strongly question whether it's worth using it up on this feature... |
| 21:02 | <Hixie> | SamB: those on the html spec's new header |
| 21:02 | <SamB> | ah |
| 21:03 | <SamB> | for some reason I was looking at the frontpage |
| 21:03 | <JonathanNeal> | zewt: are you referring to ## versus #? If so, that is an argument in favor of ##. |
| 21:03 | <SamB> | oh, I think these are different dots |
| 21:03 | <SamB> | I don't know how to deal with them |
| 21:03 | <zewt> | i've used #? myself |
| 21:04 | <zewt> | with URLs that look like http://foo.com/server/path?server=data#client/path?client=data (where client/path may be empty) |
| 21:04 | <zewt> | so I get analogous paths and key/values, for both the server (path and query) and client (encoded into the hash) |
| 21:05 | <JonathanNeal> | zewt: in those cases, what is the probability of matching that to text on the screen? |
| 21:05 | <zewt> | no idea |
| 21:05 | <JonathanNeal> | But again, that is a chief argument in favor of ##. |
| 21:05 | <SamB> | zewt: hmm, I guess that makes sense if you've things that you don't want to interfere with caching because the server doesn't use them anyway ... |
| 21:06 | <SamB> | anyway this seems like a dumb fad |
| 21:06 | <SamB> | I want my xpath fragments! |
| 21:06 | <zewt> | well, my concern (wouldn't call it an argument at this point) is whether the feature is useful enough to use up some rare still-unused way of encoding something into the hash (if it is one) |
| 21:06 | <SamB> | maybe not so dumb for text/plain |
| 21:07 | <JonathanNeal> | Or for blogs, or long articles, or anything with text. |
| 21:07 | <SamB> | anyway, it seems like it should leave room for OTHER possible uses |
| 21:08 | <JonathanNeal> | Do you believe ## does this? |
| 21:08 | <SamB> | I mean by having some kind of a name before the, uh, query ... |
| 21:09 | <JonathanNeal> | That is what the second hash provides, no? |
| 21:12 | <SamB> | no! |
| 21:12 | <zewt> | SamB: do you mean making it something like http://foo.com##word=foo, so "##" can be used for other things and not be used up completely |
| 21:12 | <SamB> | yeah |
| 21:13 | <SamB> | preferably allowing one to still have a regular fragment, too, in case you have one of those AJAX sites that needs that to even have the right content ... |
| 21:13 | <zewt> | that's really hard, i think |
| 21:13 | SamB | already wants two fragment identifiers sometimes :-( |
| 21:14 | <zewt> | since there's no standardization about how to parse hash-as-script-data itself, which means we don't know how to pull this extra data off of it |
| 21:14 | <zewt> | could try to define something, but that could be more of a battle... |
| 21:14 | <SamB> | yeah |
| 21:14 | <SamB> | but |
| 21:15 | <zewt> | eg. with my /path?query#path?query scheme, I never put # in the right-hand side (since it always gets escaped, just like it does on the left side), so I could use /path?data#path?data##other-stuff |
| 21:15 | <zewt> | ... but that's just me, heh |
| 21:15 | <zewt> | actually, make the ## a single # in that example |
| 21:15 | <SamB> | well, that's what the spying is for! |
| 21:15 | <zewt> | (the first # of ## is the one in "data#path") |
| 21:16 | <SamB> | hmm, I was figuring you'd only count two # in a row as the extra stuff ... |
| 21:16 | <zewt> | in other words, one way you could define this is "data after the first # in the hash" |
| 21:16 | <SamB> | that seems more likely to be a problem than requiring exactly ## ? |
| 21:17 | <zewt> | rather, "after the first # in the fragment" |
| 21:17 | <zewt> | ("#foo" is the hash, "foo" is the fragment, right?) |
| 21:17 | <Hixie> | well i made a change, but it didn't help with the dots illusion like i hoped it would! |
| 21:17 | <Hixie> | bbiab, meeting |
| 21:17 | <zewt> | possibly |
| 21:17 | <SamB> | hmm, one way to get rid of the dots illusion might be actual dots? |
| 21:18 | <zewt> | it would also mean that if we have more features using that mechanism, we could say http://foo.com#client stuff#word=hello#other_stuff=world |
| 21:18 | <SamB> | Hixie: having a whole screenfull of bright shiny links at the top of the spec seems kind of excessive ... |
| 21:18 | <zewt> | where this feature looks for "#word=" (which might not be the first #thing) |
| 21:19 | <SamB> | zewt: I was figuring use e.g. ##word= |
| 21:19 | <zewt> | maybe |
| 21:19 | <SamB> | but, um, pull them out of the fragment? |
| 21:19 | <zewt> | trying to think if it makes more sense to think of this in terms of fragments or hashes |
| 21:20 | <zewt> | i think it makes sense in hashes (not so much in fragments) |
| 21:20 | <zewt> | that is, as a mental model |
| 21:21 | <zewt> | (again--just to be clear, since it's a bit obscure--the hash of a URL means it includes the delimiting "#", where fragment doesn't ... assuming I'm not getting it wrong) |
| 21:22 | <zewt> | so in terms of hashes, if you have a hash and you want to add a search link to it, you'd say myHash += "##word=" + encodeURIComponent(word) (assuming there isn't one in there already), which makes sense |
| 21:22 | <SamB> | anyway, with such a framework in place -- even if it only supported one such thing in a URL -- it'd be obvious how to allow use of xpath/css ... |
| 21:23 | <zewt> | probably missed part of the conversation, but what's the link to those? |
| 21:23 | <zewt> | oh, for styling the result? |
| 21:23 | <zewt> | (wait, that'd be css but not xpath) |
| 21:23 | <SamB> | no, I meant if you wanted to do that instead of searching for a phrase |
| 21:24 | <zewt> | just a first impression, but ew :) |
| 21:24 | <SamB> | just use ##css= or ##xpath= |
| 21:25 | <SamB> | well what if I want to find a *header* containing specific text? |
| 21:25 | <zewt> | would they have to combine, eg. ##css=h1#text=Intro |
| 21:26 | <zewt> | ("first H1 containing Intro") |
| 21:26 | <zewt> | er ##text |
| 21:26 | <SamB> | I was thinking that one would probably use xpath -- xpath can do that right? |
| 21:27 | <zewt> | i'd avoid xpath like the plague |
| 21:27 | <zewt> | css selectors are way more usable in practice, and it seems nicer that since you really have an "and" query, do the text query the same way (whether or not you're narrowing it further with css) |
| 21:27 | <SamB> | okay, so, how about an image with specific alt or title text? |
| 21:28 | <zewt> | ##css=img[alt="foo"] |
| 21:28 | <SamB> | yeah, I know how to do it; that was a motivating use case |
| 21:29 | <zewt> | i know i don't ever want to use xpath if selectors are available :P |
| 21:29 | <jensnockert> | Xpath is <3. |
| 21:29 | <zewt> | itym 3< |
| 21:29 | <SamB> | well, that's why you'd never want just xpath |
| 21:30 | <SamB> | assuming xpath doesn't have a convenient way to use selectors anyway |
| 21:30 | <zewt> | i'd avoid using xpath in a new platform feature at all; don't add two ways to do something |
| 21:31 | <zewt> | is there a realistic (not overly contrived) example of where it'd need xpath and selectors aren't enough? |
| 21:31 | <KevinMarks_> | you're all missing the point a bit - css and xpath are all about invisible document stucture, which we care about but most authors don't |
| 21:32 | <zewt> | KevinMarks_: not missing the point at all (that's one of my questions--who is the user of this?), trying to understand the goals |
| 21:32 | <KevinMarks_> | whereas fragmentions are about text content, which is what the authros of annotations, commenst and references are thinking about |
| 21:33 | <KevinMarks_> | I wrote up the thought process at http://www.kevinmarks.com/fragmentions.html |
| 21:33 | <zewt> | a css selector feature could allow UAs to have a context menu "link to this place in the document", for example |
| 21:33 | <KevinMarks_> | it came from the Annotations WG, which had a lot of intersting use cases for this |
| 21:33 | <KevinMarks_> | so can fragmentions |
| 21:34 | <KevinMarks_> | er wrokshop, not WG yet |
| 21:34 | <zewt> | (grr, what happened to browsers having a "disable page style" option; this font is hard to read) |
| 21:34 | <KevinMarks_> | the medium version is prettier https://medium.com/everything-branches-out-until/41ef2be9953f |
| 21:34 | <KevinMarks_> | I suck at design |
| 21:35 | <zewt> | (this page is rambling too much, heh) |
| 21:35 | <KevinMarks_> | it's an essay, not a spec |
| 21:35 | <KevinMarks_> | http://indiewebcamp.com/fragmention is more speccy |
| 21:37 | <KevinMarks_> | but playing with the prollyfill and browser extension we have, this works very nicely in UX becasue you can just type #words+to+link |
| 21:37 | <zewt> | really needs a qualifier like we talked about above |
| 21:38 | <zewt> | this feature probably shouldn't require users to type stuff into the URL themselves anyway; better for the UA to do it for them (eg. select text, right click, select "copy link to this text", something along those lines) |
| 21:38 | <JonathanNeal> | KevinMarks_: if someone asks for a “spec” I will link them to iwc then |
| 21:38 | <KevinMarks_> | zewt: of course |
| 21:39 | <zewt> | that is, saying "##text=xxx" instead of "##xxx" isn't a user cost |
| 21:39 | <KevinMarks_> | yes it is |
| 21:39 | <KevinMarks_> | really |
| 21:39 | <zewt> | it isn't, they're not typing it out |
| 21:39 | <KevinMarks_> | some of them are |
| 21:39 | <zewt> | and using up "##" on one isolated feature should be a complete non-starter |
| 21:39 | <KevinMarks_> | assuming "no-one every types html" is how we get xhtml |
| 21:40 | <KevinMarks_> | "using up" is such BS |
| 21:40 | <KevinMarks_> | by that logic, as IDs can contain anything, all fragments are used up now |
| 21:40 | <zewt> | (if "##" is available for use with minimal web compat issues, then let's use it in a way that doesn't pretend this feature exists in a vacuum) |
| 21:40 | <KevinMarks_> | #! is used up by IDs |
| 21:40 | <KevinMarks_> | by your definition of "used up" |
| 21:40 | <zewt> | funny, I didn't give a definition (you did, then claimed it was mine) |
| 21:41 | <zewt> | quit the hyperbole, it doesn't help the discussion |
| 21:41 | <KevinMarks_> | you said this proposal uses up the namespace |
| 21:41 | <KevinMarks_> | I say it doesn't |
| 21:42 | <zewt> | so you're saying you can still use ## for linking to a css selector alongside this feature? seems unlikely |
| 21:42 | <KevinMarks_> | yes |
| 21:42 | <KevinMarks_> | want proof? |
| 21:43 | <zewt> | ##table could mean "find the text table" or "find a <table>" |
| 21:43 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html |
| 21:43 | <zewt> | saying ##text=foo is no more of a cost than query keys (and fits next to them naturally, as a nice bonus) |
| 21:44 | <KevinMarks_> | see 'an element with an id of #b1 |
| 21:45 | <zewt> | not sure what I'm supposed to be seeing |
| 21:45 | <KevinMarks_> | I can link to a phrase with http://sandbox.thewikies.com/fragmentions/example.html#phrases+as+anchors |
| 21:45 | <zewt> | having ##table search for both the string "table" and the first <table> seems bad to me |
| 21:46 | <KevinMarks_> | is ## searching for elements an existing thing, or did you just make it up? |
| 21:46 | <zewt> | what? |
| 21:46 | <KevinMarks_> | or are you using CSS syntax? |
| 21:46 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html##b1 |
| 21:47 | <KevinMarks_> | links to the element with id "#b1" |
| 21:47 | <zewt> | the whole discussion is about the idea of using CSS selectors in the anchor (one possible future feature that might live alongside this) |
| 21:47 | <zewt> | er, in the hash |
| 21:47 | <zewt> | talking about css selectors, not just ids |
| 21:48 | <KevinMarks_> | OK, so that's a separate proposal |
| 21:48 | <zewt> | (not advocating for supporting css selectors like this, rather using it as an example of something that this would get in the way of if done wrongly) |
| 21:48 | <KevinMarks_> | frankly if you want that, go with #$ and just use jquery syntax |
| 21:48 | <zewt> | ugh |
| 21:49 | <zewt> | every new feature shouldn't need to find its own magic sequence of characters (and have to do a bunch of research to figure out the web compat implications, and make URL syntax yet weirder and weirder) |
| 21:49 | <KevinMarks_> | agreed |
| 21:49 | <KevinMarks_> | which is why i want to make this simple |
| 21:49 | <SamB> | that doesn't make sense |
| 21:50 | <SamB> | unless you mean something different by "keep this simple" than I think you mean |
| 21:50 | <zewt> | ##text=search+text##css=table>tr |
| 21:51 | <KevinMarks_> | your argument is that is less weird? |
| 21:51 | <zewt> | the idea that adding "text=" to it is such a burden that any future features should just make up their own magic characters is the sort of non-forward-thinking that lead to the mess of needing "##" in the first place |
| 21:51 | <KevinMarks_> | I say we can get rid of ## |
| 21:51 | <KevinMarks_> | and just use # |
| 21:51 | <zewt> | that isn't weird at all, it's just like the query part of the URL and could probably be parsed with the same code |
| 21:51 | <KevinMarks_> | like http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation |
| 21:51 | <zewt> | well, & vs. ## is different, so not quite that |
| 21:52 | <zewt> | but the key/value scheme should be very familiar to everyone |
| 21:52 | <KevinMarks_> | & is prcessed server-side # is processed client side |
| 21:52 | <zewt> | irrelevant |
| 21:53 | <SamB> | query parameters are in fact sometimes ignored server-side and used only on the client |
| 21:53 | <zewt> | the point of ## is making it possible to use this alongside client-side hashes, at least some of them |
| 21:54 | <zewt> | for example, it could be used (in principle) with Gmail's URLs, which look like mail.google.com/mail/a/b/c#foo/bar |
| 21:54 | <zewt> | resulting in mail.google.com/mail/a/b/c#foo/bar##text=hello |
| 21:54 | <SamB> | I'm thinking something that more than one person can normally access would perhaps make more sense as an example? |
| 21:55 | <zewt> | yeah, thus "in principle" :) |
| 21:55 | <SamB> | maybe groups? |
| 21:55 | <zewt> | (doesn't mean it'd Just Work in every case, and probably wouldn't in many, but using just # would basically never work alongside client hashes) |
| 21:56 | <zewt> | incidentally, this could also be used to maybe fix the problem that you can't use id anchors at all with sites that use # for other things |
| 21:56 | <zewt> | http://foo.com#clientdata##anchor=toc interpreted like http://foo.com#toc would have been used if the clientdata stuff wasn't there |
| 21:56 | <KevinMarks_> | zewt requiring spaces in the fragmention meets all those objections |
| 21:56 | <SamB> | I don't think "client-side" is the term you want to be using though, as plain old fragments are client-side too ... |
| 21:57 | <SamB> | KevinMarks_: nooo it doesn't |
| 21:57 | <KevinMarks_> | these are frgaments |
| 21:57 | <KevinMarks_> | they are still parseable by client code |
| 21:57 | <KevinMarks_> | we just change how they resolve to target a bit |
| 21:58 | <KevinMarks_> | all your examples above have the same issue |
| 21:59 | <KevinMarks_> | I could have an element with id="#clientdata##anchor=toc" |
| 21:59 | <KevinMarks_> | which would mean that it would be the target |
| 21:59 | <KevinMarks_> | or id="#foo/bar" |
| 22:00 | <zewt> | that's the web compatibility question, or part of it: does anyone use anchors with "##" in them |
| 22:01 | SamB | already reported https://bugzilla.mozilla.org/show_bug.cgi?id=978431 about http://simonstl.com/articles/cssFragID.html ... could would happily close that as a dupe of something like what zewt is talking about |
| 22:01 | <KevinMarks_> | OK, ignore the ## |
| 22:01 | <zewt> | then what am I supposed to be answering :) |
| 22:02 | <KevinMarks_> | imagine this bit of the spec http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document |
| 22:04 | <KevinMarks_> | has before item 8, "if fragid is a whitespace-insenstitve match for innertext within the document, the indicated part of the document is the containing element of that innertext" |
| 22:05 | <KevinMarks_> | er, s/decoded fragid/fragid |
| 22:06 | <KevinMarks_> | this doesn't stop any other use of fragments, it just adds some more cases where target is valid and potentially scrolls the document |
| 22:06 | <zewt> | it makes a total mess of other use of fragments, as I said |
| 22:06 | <KevinMarks_> | no it doesn't |
| 22:06 | <KevinMarks_> | only in the same way as IDs do |
| 22:06 | <SamB> | yeah, basically |
| 22:06 | <zewt> | no, far more, as I explained already |
| 22:06 | <SamB> | assuming by IDs you also mean NAMEs |
| 22:06 | <KevinMarks_> | IDs and NAMEs yes |
| 22:07 | <KevinMarks_> | things above 8 in the bit of spec text |
| 22:07 | <SamB> | of course, that was the first use |
| 22:07 | <KevinMarks_> | "top" too |
| 22:07 | <zewt> | if css selectors were added, http://foo.com##table could mean "scroll to the first instance of the word table", or "scroll to the first <table>" element |
| 22:07 | <zewt> | which is a total mess |
| 22:07 | <zewt> | the solution is simple and low-cost: http://foo.com##text=table |
| 22:07 | <KevinMarks_> | it also would mean "Scroll to element with id="#table" like it is now |
| 22:08 | <SamB> | you can sort of understand them not thinking ahead so well at the beginning |
| 22:08 | <KevinMarks_> | scroll to Scroll to element with id="#text=table" |
| 22:08 | <zewt> | new browsers supporting this would never tried to scroll to "#table", obviously |
| 22:08 | <KevinMarks_> | everything you say about this is true of ID already |
| 22:08 | <SamB> | but now that we've already got lots of ideas about what fragments ought to be able to do, *and* conflicts between existing uses ... |
| 22:08 | <zewt> | and this is even more specific--the changes of there being a link to an id "#text=table" is smaller |
| 22:09 | <zewt> | so it both reduces the chance of web compat issues, and allows future features much more easily |
| 22:10 | <zewt> | if the only counterargument is "man, I don't want to have to type #text= once in a while", well... :) |
| 22:10 | <KevinMarks_> | you are making categorical statements about this proposal that are untrue |
| 22:11 | <zewt> | your arguments seem to be of the form "no it's not" and "that's untrue", which nobody can do much with |
| 22:12 | <KevinMarks_> | clearly we do need that survey of existing IDs adn fragments on the web to settle the probablistic arguments |
| 22:12 | <zewt> | anyway, time to go home |
| 22:12 | <zewt> | back in a bit |
| 22:12 | <KevinMarks_> | no, my argument is that IDs already consume the namespace |
| 22:12 | <SamB> | KevinMarks_: longer things are less likely to occur than substrings of them |
| 22:12 | <KevinMarks_> | except fro spaces |
| 22:12 | <Hixie> | SamB: agreed... what do you suggest instead, though? i'm scraping the bottom of the barrel for ideas here :-( |
| 22:13 | <KevinMarks_> | so requiring spaces doesn't collide with IDs |
| 22:13 | <SamB> | is that so? |
| 22:13 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation |
| 22:14 | <KevinMarks_> | decodes the fragid "remote+annotation" to "remote annotation" which cannot match an ID |
| 22:14 | <KevinMarks_> | (that link works BTW) |
| 22:15 | <KevinMarks_> | so the weak fragmentions argument requires a space |
| 22:15 | <KevinMarks_> | the strong fragmentions argument says any text that isn't an ID in the document is fair game as a fragmention |
| 22:16 | <KevinMarks_> | eg http://sandbox.thewikies.com/fragmentions/example.html#of |
| 22:16 | <KevinMarks_> | which may be overbroad |
| 22:16 | <KevinMarks_> | but still doesn't harm IDs |
| 22:16 | <SamB> | and what is so special about fragmentions that makes you think *it* should be so enshrined in the html spec? |
| 22:16 | <JonathanNeal> | what about the argument of using uncharted, presently invalid space, like ##? |
| 22:17 | <JonathanNeal> | SamB: same reason hash anchors are represented, access to content. |
| 22:17 | <KevinMarks_> | zewt says he wants that for all kinds of magic jquery style CSS stuff in some hypotherical future |
| 22:18 | <KevinMarks_> | SamB there is a huge use case for referring to text remotely |
| 22:18 | <KevinMarks_> | *text* not structure |
| 22:19 | <KevinMarks_> | effectively every reference to another work can be represented as a quotation from it |
| 22:19 | <KevinMarks_> | google is the existence proof |
| 22:20 | <KevinMarks_> | https://www.google.com/search?q=%22If+you+get+the+right+ones+in+the+right+order%22 |
| 22:20 | <KevinMarks_> | is a better anchor for the play text I'm referring to than a URL |
| 22:22 | <KevinMarks_> | heh, and my fragmentions page is now #4 for it on google |
| 22:23 | <KevinMarks_> | ten words is enough to identify that quote globally |
| 22:23 | <KevinMarks_> | 4 is probably enough for a given document |
| 22:24 | <KevinMarks_> | except for villanelles |
| 22:24 | <SamB> | that doesn't give your idea a divine right to this syntax ... |
| 22:24 | <KevinMarks_> | http://www.kevinmarks.com/poemfragmentions.html##Do+not+go+gentle+into+that+good+night.+Rage,+rage+against+the+dying+of+the+light. |
| 22:24 | <KevinMarks_> | not arguing that |
| 22:25 | <KevinMarks_> | standards are documentation, not legislation |
| 22:25 | <KevinMarks_> | I contend that this is useful, we're shipping it on the web in various places |
| 22:26 | <TabAtkins> | KevinMarks_: "all kinds of magic jquery style CSS stuff" is a misstatement. The idea of using selectors in the frag to find an element has a long history. |
| 22:27 | <KevinMarks_> | TabAtkins: got some spec text or proposals I can link to from http://indiewebcamp.com/fragmention#Related_work? |
| 22:27 | <TabAtkins> | http://simonstl.com/articles/cssFragID.html |
| 22:27 | TabAtkins | http://www.w3.org/community/cssselfrags/ |
| 22:27 | TabAtkins | https://bugs.webkit.org/show_bug.cgi?id=100841 |
| 22:28 | <KevinMarks_> | thanks! |
| 22:28 | <TabAtkins> | I literally just googled for "selectors in fragment" |
| 22:28 | <TabAtkins> | There are a bunch more. |
| 22:28 | <KevinMarks_> | yes, lots of prior art |
| 22:28 | <KevinMarks_> | all of which are complicated as heck |
| 22:29 | <KevinMarks_> | and thus wouldn't collide |
| 22:29 | <KevinMarks_> | :D |
| 22:30 | <TabAtkins> | What do you mean by "complicated as heck"? |
| 22:30 | <TabAtkins> | Simon St Laurent's last proposal is "example.com#css(.foo)" |
| 22:30 | <KevinMarks_> | I mean #css(div[class~="content"]:nth-child(2)) |
| 22:31 | <TabAtkins> | It's exactly as complicated as your selector is. |
| 22:31 | <zewt> | the thing samb and I explained it extraordinarily simple |
| 22:31 | <KevinMarks_> | is not in namespace contention with #more+complicatd |
| 22:31 | <SamB> | KevinMarks_: yes, it is |
| 22:31 | <zewt> | is not a parsable sentence |
| 22:32 | <KevinMarks_> | or rather it is already in contention with IDs |
| 22:32 | <zewt> | please restate your argument against "##text=foo", because I don't understand it |
| 22:32 | <SamB> | well, okay, not insofar as it has no parens in it, but ... |
| 22:33 | <zewt> | "##" is a hack to work around the unextensibility of the hash; if that works (isn't blocked by web compat), we should do it in a way that only has to be done once and can be reused |
| 22:33 | <zewt> | (the single-# thing I'm pretty certain is a non-starter for web compat reasons) |
| 22:33 | <KevinMarks_> | can we separate these two |
| 22:34 | <KevinMarks_> | I am interested int the web compat reasons |
| 22:34 | <KevinMarks_> | because that is the heart of this |
| 22:34 | <KevinMarks_> | can you explain how this breaks web compatibility |
| 22:34 | <SamB> | the web compat reasons are that it's going to be a pain to find and verify ONE piece of syntax to steal |
| 22:35 | <KevinMarks_> | can you rephrase that in less lodded terms please |
| 22:36 | <KevinMarks_> | you are saying this will collide with something? |
| 22:36 | <zewt> | if you have a link http://foo.com, and there's an ID "credits", what does http://foo.com#credits mean? |
| 22:36 | <KevinMarks_> | it means go to ID credits |
| 22:36 | <zewt> | you either have a web compat issue (it breaks links to the credits), or you're unable to do a text link to the string "credits"; both are bad |
| 22:36 | <KevinMarks_> | IDs win over text |
| 22:36 | <SamB> | (or, well, maybe I was going in the wrong direction ...) |
| 22:36 | <KevinMarks_> | what does http://foo.com#credits+ mean? |
| 22:37 | <zewt> | so you want a text-search-link feature that doesn't work if the page happens to have an ID with the word the user wants to link to? |
| 22:37 | <KevinMarks_> | it no longer matches that ID |
| 22:37 | <zewt> | what? that's gross |
| 22:37 | <SamB> | indeed, very gross |
| 22:37 | <zewt> | hope that's not a serious suggestion heh |
| 22:37 | <KevinMarks_> | absolutely |
| 22:37 | <zewt> | ... |
| 22:37 | <KevinMarks_> | it's what I have working |
| 22:37 | <zewt> | sorry, too insane for me to even know how to reply |
| 22:37 | <KevinMarks_> | this is how I know i'm safe |
| 22:37 | <SamB> | it doesn't really matter all that much what you have working |
| 22:38 | <KevinMarks_> | you all think this is insane, because you haven't seen it on the web |
| 22:38 | <KevinMarks_> | hence no collisions |
| 22:38 | <zewt> | no, we think it's insane because it's an ugly, nasty hack (even uglier than ##, and far less functional) |
| 22:38 | <SamB> | you have to sell it to the browser vendors ... |
| 22:39 | <KevinMarks_> | I'm hearing emotion words, not arguments |
| 22:39 | <KevinMarks_> | "ugly, nasty" is cognitive dissonance |
| 22:39 | <zewt> | we've already responded to everything you've said, and you've given little to no useful response |
| 22:39 | <KevinMarks_> | you haven't responded |
| 22:39 | <zewt> | ... |
| 22:39 | <zewt> | okay, i'm done for now :) |
| 22:39 | <TabAtkins> | Note that Media Fragments claims a relatively safe portion of the fragment syntax space just by assuming that "foo=..." is safe to claim. |
| 22:40 | <KevinMarks_> | I say that fragments with spaces in don't collide with IDs |
| 22:40 | <TabAtkins> | video.mp4#t=5s, for example. |
| 22:40 | <SamB> | TabAtkins: I heard they specifically excluded HTML though? |
| 22:40 | <TabAtkins> | We should probably make sure that everybody claims fragment syntax in the same way. |
| 22:40 | <KevinMarks_> | media fragments explicitly exclude htmls |
| 22:40 | <zewt> | TabAtkins: my suggestion is http://foo.com#ignored##key=value, because that can coexist with many client-side uses of the hash |
| 22:40 | <TabAtkins> | SamB: Not too relevant. SVG does the same thing. |
| 22:41 | <KevinMarks_> | this can coexist with client-side uses of the hash |
| 22:41 | <zewt> | (samb's originally, I think) |
| 22:41 | <SamB> | KevinMarks_: in the same link? |
| 22:41 | <KevinMarks_> | what? |
| 22:42 | <KevinMarks_> | where did "in the same link" come from? |
| 22:42 | <TabAtkins> | Actually, SVG uses "#foo()" form. |
| 22:42 | <SamB> | zewt: well, you came up with the key=value idea; my thinking was just that there should be some sort of a name to indicate which new thing ... |
| 22:42 | <TabAtkins> | zewt: Yeah, I prefer using = over function syntax. |
| 22:42 | <SamB> | KevinMarks_: see the example above? |
| 22:43 | <KevinMarks_> | I do, yes what does it represent |
| 22:43 | <zewt> | fwiw, i think it could be defined simply as "the string #text= followed by characters other than #", with no higher-level "parse out key/values" algorithm |
| 22:43 | <zewt> | ##text |
| 22:44 | <SamB> | KevinMarks_: difficult to say; it's rather meta |
| 22:44 | <TabAtkins> | I think it's fine to claim #text= |
| 22:44 | <zewt> | TabAtkins: i think that's extremely bad |
| 22:45 | <TabAtkins> | Why? Pretty sure it'd be safe to claw that out of the ID space. |
| 22:45 | <zewt> | it's the space for scripts to stash stuff in the hash that I'm more concerned about |
| 22:45 | <KevinMarks_> | you're all fighting for the ID space. Mine doesn't collie with it at all |
| 22:46 | <KevinMarks_> | and scripts stuffing things in the hash aren't going to collide except in documents discussing those scripts |
| 22:46 | <KevinMarks_> | and only if they use spaces |
| 22:46 | <TabAtkins> | KevinMarks_: Orthogonal concerns. Even if we decided to use a different syntax like ##foo, we'd still want to make sure it's possible to use more functions than just "match text". |
| 22:47 | <KevinMarks_> | TabAtkins: how does this stop that? |
| 22:47 | <KevinMarks_> | it's possible to use more functions than just "match ID" now |
| 22:47 | <TabAtkins> | Everyone's been over that. Making "##foo" be the "search for 'foo' text" syntax claims the entire syntax space. |
| 22:47 | <Hixie> | what's the problem y'all are trying to solve? (sorry, not been paying attention so far) |
| 22:48 | <SamB> | as you can see, there are a lot of people who want various pieces of this action; it's best if we can come up with something that avoids people having to worry about stepping on eachothers toes in the process ... |
| 22:48 | <KevinMarks_> | ID already claims the entire syntax space |
| 22:48 | <SamB> | KevinMarks_: yes, well, if we're going to steal some we need to do it properly |
| 22:48 | <TabAtkins> | Hixie: Trying to solve the problem of multiple specs wanting to put things in the fragment space. |
| 22:48 | <KevinMarks_> | if you manage without colliding with IDs, you'll manage with this |
| 22:49 | <KevinMarks_> | Hixie: the fragmentions idea |
| 22:49 | <zewt> | "we already have a collision with IDs" != "we should stuff whatever unstructured stuff we want in the hash and not care about making things worse" |
| 22:49 | <Hixie> | TabAtkins: ah, a time-honoured problem for people to try to solve :-) |
| 22:49 | <TabAtkins> | KevinMarks_: There's a difference between "No real IDs use an = character" and "No one will ever want to search for an = character" |
| 22:49 | <Hixie> | KevinMarks_: fragmentations idea? |
| 22:49 | <SamB> | Hixie: no, fragmentions |
| 22:49 | <Hixie> | (in practice, the fragid space in HTML docs is page-defined, and entirely under the control of the page) |
| 22:49 | <TabAtkins> | Frag-mentions. |
| 22:49 | <SamB> | it's a portmanteu (however that's spelt) |
| 22:50 | <Hixie> | frag-mentions? |
| 22:50 | <zewt> | Hixie: http://foo.com##text=hello linking to the first text match of "hello" (using one of the syntaxes we've discussed) |
| 22:50 | <Hixie> | oh, linking to a text match |
| 22:50 | <Hixie> | interesting |
| 22:50 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation |
| 22:50 | <zewt> | (obviously, the web compat and hash namespace issues are biggies) |
| 22:50 | <TabAtkins> | (Probably actually pre-filling the browser's Ctrl+F UI.) |
| 22:50 | <SamB> | http://indiewebcamp.com/fragmention links to several related things ... |
| 22:50 | <Hixie> | yeah you don't want to do that using fragids, pages can already use that space for whatever purpose they want |
| 22:50 | <KevinMarks_> | a single word is a problem |
| 22:50 | <KevinMarks_> | multiple words isn't |
| 22:51 | <TabAtkins> | Hixie: So the idea so far is to lean on ## as the introducer syntax. |
| 22:51 | <KevinMarks_> | hang on |
| 22:51 | <KevinMarks_> | I'm backing off ## |
| 22:51 | <zewt> | we're not :) |
| 22:51 | <KevinMarks_> | and being more ambitious |
| 22:51 | <KevinMarks_> | IDs cannot contain spaces |
| 22:51 | <KevinMarks_> | so http://sandbox.thewikies.com/fragmentions/example.html#remote+annotation |
| 22:51 | <KevinMarks_> | means what now? |
| 22:51 | <SamB> | KevinMarks_: it might be possible to use that space but it would be more annoying to would-be linkmakers |
| 22:51 | <Hixie> | KevinMarks_: fragment identifiers aren't limited to IDs |
| 22:51 | <TabAtkins> | Your idea means I can't search for a single word. |
| 22:51 | <Hixie> | and "+" in fragment identifiers means "+", not " " |
| 22:52 | <zewt> | TabAtkins: he wants you to put a dummy space at the end |
| 22:52 | <TabAtkins> | Oh, bleh. |
| 22:52 | <KevinMarks_> | not in every browser I've tried it |
| 22:52 | <zewt> | my reaction too |
| 22:52 | <TabAtkins> | That doesn't work either. |
| 22:52 | <SamB> | dummy space isn't even actually possible |
| 22:52 | <TabAtkins> | I might be searching for a word prefix. |
| 22:52 | <SamB> | browser removes it |
| 22:52 | <TabAtkins> | I do that in the Ctrl+F UI regularly. |
| 22:52 | <SamB> | I don't know if fragmentions can even search for word fragments |
| 22:52 | <astearns> | the part of the URL that contains the fragmention is the fragmention container, so it will have to be called the fragmentiontainer |
| 22:52 | <SamB> | astearns: lol |
| 22:52 | <SamB> | you win |
| 22:52 | <zewt> | anyway, ## solves (or attempts to solve) a number of problems, including possibly improving the situation we have today where you can't use both #anchors and script-data-stored-in-the-hash at the same time |
| 22:53 | <KevinMarks_> | Hixie, click that lint |
| 22:53 | <KevinMarks_> | *link |
| 22:53 | <SamB> | zewt: ## is at least a good stand-in for a solution |
| 22:53 | <KevinMarks_> | I don't actually care about the single word case |
| 22:53 | <zewt> | SamB: making http://foo.com#clientdata##id=foo behave like http://foo.com#foo does today seems to solve it pretty well |
| 22:53 | <Hixie> | KevinMarks_: what about it? |
| 22:54 | <KevinMarks_> | because my use case is robust anchors to text content |
| 22:54 | <astearns> | KevinMarks_: the single word case seems like a huge use case to me - I'm annotating this word to mention that it's mispelled |
| 22:54 | <KevinMarks_> | so multiword is better |
| 22:54 | <zewt> | SamB: it doesn't fix it automatically (the site may need to adjust parsing to handle it, or know how to preserve the ##extra stuff in the URL), but it gives them a *way* to do it, which today doesn't exist at all |
| 22:55 | <KevinMarks_> | astearns: in practice you give search phrase |
| 22:55 | <SamB> | can I point out that I think I'm extremely likely to want to link to something other than the first occurance? |
| 22:55 | <KevinMarks_> | which is why you use more words |
| 22:55 | <Hixie> | fragment identifiers are a reserved space for use by the page, you can't add UA logic there beyond what's there already |
| 22:55 | <zewt> | SamB: i'm inclined to punt that as a use case for a possible future "css selectors in the url" proposal |
| 22:55 | <SamB> | zewt: I was sort of assuming we'd want to roll out browsers segregating that stuff from .fragment as the first step |
| 22:56 | <JonathanNeal> | KevinMarks_: for the sake of argument, if ## is used, what are the next concerns? < Hixie, TabAtkins |
| 22:56 | <KevinMarks_> | http://www.kevinmarks.com/poemfragmentions.html##occurs+more |
| 22:56 | <Hixie> | otherwise you'd break e.g. fragmention.js |
| 22:56 | <KevinMarks_> | I'm not adding more UA logic |
| 22:56 | <Hixie> | oh |
| 22:56 | <KevinMarks_> | I'm just expanding the ability to express "the indicated part of the document" |
| 22:56 | <TabAtkins> | ...which is UA logic. |
| 22:57 | <Hixie> | o_O |
| 22:57 | <Hixie> | i'm confused |
| 22:57 | <zewt> | Hixie: the web compat problem is important, but it's not obvious to me that having (eg.) "##id=foo" jump to <div id=foo> isn't web-compatible enough |
| 22:57 | <Hixie> | do you want UAs to change behaviour or not? |
| 22:57 | <SamB> | Hixie: well, presumably we could key off of "#" "#" ID "=" ? |
| 22:57 | <TabAtkins> | UA logic being "anything the UA does for you", as opposed to "something that in-page scripts do". |
| 22:57 | <Hixie> | there are pages that take the fragid and do stuff with it |
| 22:57 | <Hixie> | stuff like "draw it on a canvas" |
| 22:57 | <zewt> | i've written many of them myself :) |
| 22:57 | <Hixie> | or "send an e-mail" |
| 22:57 | <Hixie> | or whatever |
| 22:57 | <SamB> | Hixie: I want the URL parsing to change, and hide this from old pages |
| 22:57 | <KevinMarks_> | I want UAs to change behaviour. I am arguing that this does not in any way affect the other uses of fragments by client code |
| 22:58 | <Hixie> | oh well if you want to change URL parsing, that's a different matter |
| 22:58 | <KevinMarks_> | and this would not affect them |
| 22:58 | <zewt> | SamB: i just thought about that a little, but changing that is scary... |
| 22:58 | Hixie | will leave fighting changing the url parsing spec to anne |
| 22:58 | <KevinMarks_> | I want to add a step between 7. and 8. here http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document |
| 22:58 | <Hixie> | KevinMarks_: yeah, you can't do that |
| 22:58 | <Hixie> | KevinMarks_: that breaks pages that use the fragment identifier |
| 22:58 | <SamB> | zewt: well, it seems impractical to expect every JS app that uses fragments to change |
| 22:58 | <zewt> | SamB: for example, if saying document.location.protocol + document.location.hostname ..... + document.location.hash no longer reconstructs the URL |
| 22:58 | <KevinMarks_> | how? |
| 22:58 | <SamB> | which seems like the alternative? |
| 22:58 | <Hixie> | KevinMarks_: you could do it the way SamB suggests |
| 22:59 | <Hixie> | KevinMarks_: and change the url parser |
| 22:59 | <SamB> | zewt: hmm |
| 22:59 | <zewt> | SamB: (because part of the hash is no longer inside .hash) |
| 22:59 | <KevinMarks_> | hear me out, Hixie |
| 22:59 | <SamB> | I'm not sure if I'd want to change .hash |
| 22:59 | <Hixie> | KevinMarks_: suppose a page takes the fragid and draws it on a canvas |
| 22:59 | <KevinMarks_> | OK |
| 22:59 | <Hixie> | KevinMarks_: you've just made that page have wacked behaviour for certain fragIDs |
| 22:59 | <SamB> | Hixie: assuming it has words on it |
| 23:00 | <KevinMarks_> | no more than if there is an ID in the page that matches it |
| 23:00 | <Hixie> | SamB: right |
| 23:00 | <zewt> | Hixie: it seems okay if the new feature doesn't work on 100% of pages, as long as it doesn't break existing pages/links (or whatever small percent of breakage vendors are OK with) |
| 23:00 | <Hixie> | KevinMarks_: right, but they already know about that |
| 23:00 | <SamB> | KevinMarks_: but it would KNOW about the IDs |
| 23:00 | <Hixie> | KevinMarks_: so they already have to deal with it |
| 23:00 | <Hixie> | zewt: there's 100s of trillions of pages. unless the number is 0, the number is probably too high. |
| 23:01 | <SamB> | the best case here is if we can make this work even for pages that already use their fragments in script |
| 23:01 | <zewt> | trying to contrive actual web breakage: a site might use a weird not-base64 binary encoding in their hash, which could end up encoding some binary blob to a string including "##text=hello" |
| 23:01 | <zewt> | s/actual/potential/ |
| 23:01 | <SamB> | we at least need to avoid actually BREAKING such pages |
| 23:01 | <zewt> | that page would break if .hash changed, but it might not if .hash stays the same (which I'm pretty sure it should) and it just causes the browser to try to scroll to "hello" |
| 23:02 | <KevinMarks_> | so we're back to what I said originally - is there a good survey of existing IDs and fragment URLs in the wild? |
| 23:02 | <KevinMarks_> | like Hixie did for classes? |
| 23:02 | <SamB> | hmm, what do typical .hash-using pages in the wild actually DO with their .hash strings? |
| 23:02 | <Hixie> | KevinMarks_: such a survey wouldn't help, what you need is an inspection-based examination of pages that use location.hash |
| 23:02 | <KevinMarks_> | 'cos that's how you settle "you might break this carefully constructed edge case" argument |
| 23:02 | <zewt> | SamB: probably everything conceivable :P |
| 23:02 | <JonathanNeal> | I’d still like to know from Hixie or TabAtkins what happens if we just use the ## space, as those are presently invalid, and let browsers honor the invalid ##term as they already would when <div id="#term">. |
| 23:03 | <Hixie> | JonathanNeal: nothing is invalid in a fragid |
| 23:03 | <zewt> | invalid as an @id link doesn't mean you can't put it in the fragment at all |
| 23:03 | <SamB> | unfortunate truth :-( |
| 23:03 | <JonathanNeal> | Hixie, ah, cool, and what are your thoughts on reserving some of that space for targeting elements by text? |
| 23:03 | <SamB> | the "nothing is invalid" bit, I mean |
| 23:03 | <zewt> | i think he just gave his thoughts :P |
| 23:03 | <SamB> | JonathanNeal: no that's not cool :-( |
| 23:04 | <KevinMarks_> | A fragment must be zero or more URL units. http://url.spec.whatwg.org/#url-code-points does not include # |
| 23:04 | <JonathanNeal> | SamB: so I’m clean, you are saying that anything using a hash to search for text on a page, regardless of the syntax, is not cool? |
| 23:05 | <SamB> | Hixie: oh did you see the link to http://simonstl.com/articles/cssFragID.html yet? |
| 23:05 | <KevinMarks_> | so #%23foo is needed to produce a decoded fragid of "#foo" |
| 23:06 | <Hixie> | JonathanNeal: retroactively reserving space is usually a lost cause |
| 23:06 | <Hixie> | KevinMarks_: maybe in theory, but not in practice |
| 23:06 | <SamB> | Hixie: obviously based on our discussion we're not sure that's a good plan for the actual syntax, but the things it allows one to *represent* seem useful ... |
| 23:06 | <KevinMarks_> | which is what we found |
| 23:06 | <KevinMarks_> | though some UA's converted ## into #%23 notably colloquy |
| 23:06 | <SamB> | KevinMarks_: you may have found a bug in the URL spec |
| 23:07 | <Hixie> | SamB: yeah, xpointer is one of the big over-engineered ways to solve this problem. and it doesn't solve it. :-) |
| 23:07 | <Hixie> | (and it went nowhere) |
| 23:07 | <zewt> | as a terrible logical-extreme case, do you think "##0271a91a-86a0-4773-b042-eb535834e0d8=hello" would be web-incompatible? |
| 23:07 | <SamB> | Hixie: it would help if we had a way to actually *use* it |
| 23:07 | <SamB> | I mean in a link |
| 23:07 | <Hixie> | anyway i don't want to be the stop energy in the room here, i mean, if you guys can figure out a way to do it, go for it :-) |
| 23:07 | <KevinMarks_> | there are variations of complex queries going back to 1998 that didn't work |
| 23:08 | <Hixie> | zewt: it would break the script i mentioned earlier, yes |
| 23:08 | <KevinMarks_> | the simple one goes right through the gap |
| 23:08 | <Hixie> | zewt: (unless we change url parsing to hide it from .hash) |
| 23:08 | <SamB> | hmm, my next crazy idea is to invent a new Unicode character especially to start one of these babies |
| 23:08 | <SamB> | that probably doesn't actually work though |
| 23:08 | <Hixie> | zewt: (though then we break the scripts that concatenate, as you mentioned) |
| 23:09 | <SamB> | hmm, FWIW, I think it's acceptable if a script tries to reconstruct its URL and loses the extras |
| 23:09 | <zewt> | Hixie: sorry, which script? (what I'm looking for is how it could have web compatibility issues, given that no link on the web contains that text) |
| 23:09 | <KevinMarks_> | http://zesty.ca/crit/draft-yee-url-textsearch-00.txt |
| 23:09 | <SamB> | I don't think the IETF is in charge of URLs anymore, KevinMarks_ |
| 23:09 | <zewt> | (I'm willing to make the leap of faith that no URL on the web contains a UUID that I just generated) |
| 23:10 | <zewt> | i guess we might be talking about different parts of web-compatible, too |
| 23:10 | <SamB> | zewt: oh, the one with the canvas that draws its fragment identifier |
| 23:11 | <zewt> | SamB: but no links actual exist with that string in it |
| 23:11 | <KevinMarks_> | got a link for drawing fragids on canvas |
| 23:11 | <KevinMarks_> | ? |
| 23:11 | <KevinMarks_> | I can see if the chrome plugin breaks it |
| 23:12 | <zewt> | you might create a link in the future that wouldn't work, but there's a big difference between breaking links that someone creates after the feature is deployed (they try it and simply notice it didn't work) and breaking ones that already exist (that's what I think of for "web compat") |
| 23:12 | <KevinMarks_> | agreed |
| 23:12 | <KevinMarks_> | I don't think this breaks links |
| 23:12 | <KevinMarks_> | thats where we keep going in circles |
| 23:12 | <SamB> | Hixie: anyway, personally I either won't want to link to words on that page in the first place, or can live with the silly things it decides to draw on its canvas when I do ... |
| 23:12 | <Hixie> | zewt: http://damowmow.com/playground/demos/fragment-identifiers/002.html##0271a91a-86a0-4773-b042-eb535834e0d8=hello |
| 23:12 | <KevinMarks_> | samB quite |
| 23:13 | <zewt> | Hixie: but that's not breaking links that exist today (putting aside web IRC logs of this discussion), since nobody's creating links using that feature (since it doesn't exist yet) |
| 23:13 | <Hixie> | zewt: it means you can't use that feature on that page |
| 23:13 | <zewt> | right |
| 23:13 | <zewt> | that seems different than "web compatibility" as I understand it |
| 23:13 | <SamB> | Hixie: yeah, true, which is bad :-( |
| 23:14 | <zewt> | the feature doesn't work with the page, but the page itself isn't broken |
| 23:14 | <Hixie> | zewt: that seems pretty lame if we can't come up with a feature that works on all pages |
| 23:14 | <SamB> | but "can't use it on that page" > "can't use that page because of it", obviously |
| 23:14 | <zewt> | the web can be pretty lame (you know that better than me :), but "we can't do this feature perfectly" is usually not a good reason to not do it at all |
| 23:14 | <Hixie> | well it means that if you actually WANT to display "#0271a91a-86a0-4773-b042-eb535834e0d8=hello", you can't do it, because it would jump to the word "hello" |
| 23:14 | <SamB> | Hixie: yeah, that was why I said we should try to allow this along with a fragment ID, and preferably along with other ## .. = stuff |
| 23:15 | <KevinMarks_> | it would jump to it and display it |
| 23:15 | <zewt> | right |
| 23:15 | <SamB> | Hixie: yeah |
| 23:15 | <Hixie> | SamB: yeah, changing the url parsing to add a new component to urls seems like a prereq to making anything like this work, imho. but i don't know how plausible even that would actually be. |
| 23:15 | <zewt> | messing with location.hash is scary as hell, heh |
| 23:15 | <SamB> | Hixie: yeah, exactly my thinking ... |
| 23:16 | <KevinMarks_> | I'm all Eppur Si Muove on this working |
| 23:16 | <SamB> | I'm not really sure if it should be included or excluded from location.hash |
| 23:16 | <zewt> | SamB: that sounds like the implication from what hixie said, though |
| 23:16 | <Hixie> | if we change the url parsing, it should be excluded |
| 23:16 | <Hixie> | otherwise you haven't changed url parsing |
| 23:16 | <zewt> | it'd have to not be in location.hash if you want that canvas page to "just work" |
| 23:16 | <KevinMarks_> | empirically, being able to link by text content is really handy |
| 23:17 | <Hixie> | i updated the spec header again, btw. made it way tighter. |
| 23:17 | <Hixie> | and added a gradient |
| 23:17 | <Hixie> | can't wait to see the reaction of all the other whatwg spec editors when they wake up and find their specs have changed! |
| 23:17 | <SamB> | what API would be appropriate for accessing that portion of the URL for at least those things that the browser doesn't grok yet? |
| 23:17 | <Hixie> | KevinMarks_: i dunno, i think it's a bit of an esoteric feature in practice |
| 23:17 | <zewt> | (i don't know if any pages parse out document.location.href and ignore .hash, anything doing that is probably a lost cause) |
| 23:17 | <zewt> | SamB: document.location.hashhash |
| 23:18 | <SamB> | KevinMarks_: people have certainly been after such a thing for text/plain for ages |
| 23:18 | <KevinMarks_> | quite |
| 23:18 | <SamB> | zewt: well, but what would the "type" of that be? |
| 23:18 | <SamB> | [(String, String)] ? |
| 23:18 | <SamB> | Map String String ? |
| 23:18 | <zewt> | not sure, seems not hard to define but probably not worth brainstorming at this point |
| 23:18 | <KevinMarks_> | the html5 spec is liberally sprinkled with ids so you can link to almost any bit of it |
| 23:19 | <KevinMarks_> | and that is hugely useful |
| 23:19 | <SamB> | KevinMarks_: indeed |
| 23:19 | <SamB> | not necessarily any bit you'd want to, but ... |
| 23:19 | <KevinMarks_> | being able to do that for any web document is great |
| 23:19 | <zewt> | changing url parsing and document.location makes this seem like a much bigger, heavier, more dangerous feature, compared to its value |
| 23:19 | <KevinMarks_> | it doesn't change .location |
| 23:20 | <SamB> | while we're on that topic, shouldn't there be some kind of browser UI for finding a nearby anchor? |
| 23:20 | <KevinMarks_> | only target |
| 23:20 | <zewt> | sigh |
| 23:20 | <JonathanNeal> | Hixie: I would point to http://indiewebcamp.com/fragmention#Related_work and http://en.wikipedia.org/wiki/Fragment_identifier#Proposals are decent arguments against it being esoteric |
| 23:20 | <SamB> | and making a you a URL for it? |
| 23:20 | <zewt> | it does in a big chunk of the discussion for the last page |
| 23:20 | <SamB> | zewt: last page? |
| 23:20 | <JonathanNeal> | s/are/as |
| 23:21 | <zewt> | the entire "change URL parsing" discussion is about changing .location |
| 23:21 | <KevinMarks_> | yes, the ## stuff |
| 23:21 | <KevinMarks_> | that's why I say YAGNI on that |
| 23:21 | <Hixie> | JonathanNeal: Put it this way. I have never heard non-web-heads (i.e. "real users") ask for this feature. |
| 23:21 | <zewt> | please don't make up abbreviations on the spot and expect others to guess what they mean |
| 23:21 | <SamB> | oh, I get it, "<zewt> it does in a big chunk [...]" is a response to "<KevinMarks_> it doesn't change .location" |
| 23:22 | <zewt> | SamB: sometimes one wishes for threaded IRC :P |
| 23:22 | <Hixie> | bbiab |
| 23:22 | <SamB> | Hixie: why should only "real users" get features? |
| 23:22 | <KevinMarks_> | you weren't in the Annotations meeting i was |
| 23:22 | <SamB> | zewt: YAGNI isn't made up on the spot? |
| 23:23 | <SamB> | it's in vera; no idea why not foldoc |
| 23:23 | <Hixie> | SamB: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 |
| 23:23 | <SamB> | Hixie: point |
| 23:25 | <KevinMarks_> | this workshop: http://www.w3.org/2014/04/annotation/ |
| 23:25 | <zewt> | my overall take is that changing URL parsing and document.location is a big, scary change that dwarfs the value of the change; the feature not working on a few pages that use hashes in unusual ways is lame but bearable (and expected--the "##" idea wasn't expected to work in every case); if people decide it's not bearable, better to drop it than to mess around with something so fundamental |
| 23:25 | <KevinMarks_> | was where I heard use case after use case of people wanting more robust anchors into the web |
| 23:25 | <SamB> | hmm |
| 23:26 | <zewt> | my main issue with regular anchors is I can never find them; if browsers had a "copy link to this page at the most recent anchor" (so I didn't have to go hunt down a TOC link or open the inspector) they'd be a heck of a lot more usable |
| 23:26 | <KevinMarks_> | yes |
| 23:26 | <zewt> | that would help a lot without any platform changes |
| 23:26 | <KevinMarks_> | but being able to point to the text is better |
| 23:26 | <SamB> | for a moment I was pondering actually trying to allow xlink, but then I was like "but what would be in the address bar?" so yeah not going to work ... |
| 23:27 | <KevinMarks_> | because that is what they are trying to do |
| 23:27 | <SamB> | zewt: yeah, I just mentioned that above |
| 23:27 | <KevinMarks_> | and in this case the address bar is very clear |
| 23:27 | <SamB> | "shouldn't browsers have UI to find a handy anchor and make you a link" |
| 23:27 | <SamB> | that's a paraphrase |
| 23:28 | <KevinMarks_> | they are referring to the text not the anchor |
| 23:29 | <KevinMarks_> | In effect, we can make you an anchor for what you select |
| 23:30 | <SamB> | anyway, the amount of work involved here would make it an absolute requirement that any such change allow a whole namespace of such things, not just this one "fragmentions" |
| 23:30 | <zewt> | we understand the difference |
| 23:30 | <SamB> | KevinMarks_: I was talking about better UI to make links that work today |
| 23:30 | <SamB> | and, well, probably also last decade |
| 23:31 | <SamB> | by which I mean ~2004, not 2009 |
| 23:31 | <KevinMarks_> | so we'll stick to shipping a page of js that makes the browsers capable of doing this now then |
| 23:31 | <SamB> | KevinMarks_: which of course makes you part of the problem |
| 23:32 | <SamB> | in the sense that your scripts toes are among those that would need to be avoided in order to make such a change |
| 23:32 | <KevinMarks_> | not if you make this change... :D |
| 23:32 | <SamB> | well it sure won't happen quickly |
| 23:34 | <JonathanNeal> | SamB: actually, I hate that problem too, so when I wrote the script, I built in a feature test. |
| 23:34 | <SamB> | Hixie: so, um, does it make much difference what syntax he tries to use for this fragmentions thing? i.e. would it be better to use something like ##text= with the usual query-encoding? |
| 23:34 | <SamB> | JonathanNeal: how does it test for the feature? |
| 23:34 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html#phrases+as+anchors |
| 23:35 | <JonathanNeal> | SamB: what you could fault me for is making a feature test for a feature that doesn’t exist. The best I could do is search window.location for a fragmention property. |
| 23:35 | <zewt> | you could probably write to .hash and see if the location changes, but that'd be pretty intrusive |
| 23:35 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html#readable+shortcuts |
| 23:35 | <SamB> | JonathanNeal: pretty confident about the name, huh? |
| 23:36 | <JonathanNeal> | in the same way that .hash is a partial, decoded version of .href, .fragmention is a partial, decoded version of .hash. |
| 23:36 | <KevinMarks_> | you could see if target already matches what you were going to change it to? |
| 23:36 | <JonathanNeal> | SamB: like I said, fault me for that. |
| 23:36 | <TabAtkins> | zewt: Yeah, don't mess with .hash at all. |
| 23:36 | <TabAtkins> | Just let .hash continue to reflect the entire hash, then have another k/v dict populated from the ## values, like the current .query. |
| 23:37 | <SamB> | JonathanNeal: actually, I guess it's best if you don't really go anywhere near before some kind of consensus to use it would happen? |
| 23:37 | <JonathanNeal> | TabAtkins: that is what I tried to do, effectively. (see above comment) |
| 23:37 | <zewt> | TabAtkins: hixie's concern is that the feature wouldn't work on pages that use the hash literally (as in the "print the hash to a canvas" page) |
| 23:37 | <SamB> | s/near/near ##/ |
| 23:37 | <TabAtkins> | zewt: What I just said *should* work on pages taht use the hash literally. |
| 23:37 | <zewt> | i don't think that's web compat, though (or at least, not "web backwards-compatibility", which is the direction I usually think of it in) |
| 23:37 | <TabAtkins> | That's why I suggested it. ^_^ |
| 23:37 | <zewt> | TabAtkins: not sure what you meant, then |
| 23:37 | <TabAtkins> | If you want to use the hash literally, you just look at .hash. |
| 23:37 | <KevinMarks_> | http://sandbox.thewikies.com/fragmentions/example.html#include+the+entire+text |
| 23:37 | <TabAtkins> | Which is *the entire hash*, as it is today. |
| 23:38 | <JonathanNeal> | SamB, that’s an interesting point, though, if one of us had not made a proof of concept, I’m curious where the discussion would have gone. |
| 23:38 | <SamB> | TabAtkins: obviously whether to include it in .hash would merit further study |
| 23:38 | <KevinMarks_> | those last few links are all calls for linking to text |
| 23:38 | <zewt> | TabAtkins: the example was http://damowmow.com/playground/demos/fragment-identifiers/002.html##0271a91a-86a0-4773-b042-eb535834e0d8=hello |
| 23:38 | <SamB> | hmm, this fragmentions thing does not work with script disabled ;-P |
| 23:38 | <zewt> | TabAtkins: or to get rid of the weird example I made: http://damowmow.com/playground/demos/fragment-identifiers/002.html##search=hello |
| 23:39 | <zewt> | TabAtkins: the feature would continue to be printed to the canvas, since the ##stuff still shows up in .hash |
| 23:39 | <KevinMarks_> | JonathanNeal: I agree - your implementation made it clear that this worked and was useful |
| 23:39 | <TabAtkins> | Yeah, that would give a .hash of "#search=hello". (Or "##search=hello", I forget whether .hash includes the initial #.) |
| 23:39 | <zewt> | TabAtkins: i think we can live with that, FWIW |
| 23:39 | <SamB> | so, would it be stupid to set up telemetry for ## ? |
| 23:39 | <TabAtkins> | Whatever it does today. |
| 23:39 | <TabAtkins> | But it woudl also give a .hashQuery of {search:["hello"]} or whatever. |
| 23:40 | <TabAtkins> | zewt: So yeah, what you said. |
| 23:40 | <SamB> | TabAtkins: hmm, so we don't want to allow repeated keys then? |
| 23:40 | <SamB> | or ordering between keys |
| 23:40 | <zewt> | TabAtkins: the ##text= idea was meant to 1: avoid collisions with links that already exist today, and 2: give programmers a way to use both this feature and their own stuff in hashes at the same time |
| 23:40 | <JonathanNeal> | TabAtkins: today the hash contains the #, so, location.hash = 'hello'; location.hash // '#hello' |
| 23:40 | <TabAtkins> | SamB: Note the value is an array, just like for query values. |
| 23:40 | <SamB> | oh |
| 23:40 | <SamB> | nevermind |
| 23:40 | <zewt> | not to make this new feature work on every page, which it definitely won't |
| 23:40 | <TabAtkins> | zewt: Not sure how waht you're saying is relevant to what I said. |
| 23:41 | <SamB> | oh, well, that would still not allow different handling of ##text=foo##css=:bar and ##css=:bar##text=foo |
| 23:41 | <SamB> | not that the former would ever make much sense ... |
| 23:42 | <TabAtkins> | SamB: The URL object does track those differently, I think. |
| 23:42 | <zewt> | SamB: i'd totally avoid repeated keys, the APIs you end up with for a multidict are uglier than for a simple dictionary for incredibly rare cases |
| 23:42 | <TabAtkins> | (Or if it doesn't, then probably we dont' need that for hash queries either.) |
| 23:42 | <SamB> | zewt: hmm |
| 23:42 | <zewt> | (and even rarer for this stuff, at least for the potential uses we've discussed so far) |
| 23:43 | <zewt> | basically this breaks the URL into three major parts: stuff for the server (path, query), client-side stuff for scripts (part of the hash), and client-side stuff for the browser (this stuff) |
| 23:43 | <SamB> | (oh, btw: where I said XPath above I must have been thinking of XLink) |
| 23:43 | <SamB> | zewt: browser or polyfill |
| 23:43 | <zewt> | actually backing up, i'd start with: just expose this as a string |
| 23:44 | <KevinMarks_> | JonathanNeal's script works fine with http://damowmow.com/playground/demos/fragment-identifiers/002.html |
| 23:44 | <SamB> | zewt: hmm |
| 23:44 | <KevinMarks_> | though you'd have to enter a lot of lines to see it do something |
| 23:44 | <SamB> | zewt: so like .hashhash ? |
| 23:44 | <zewt> | seems like a given that you want a string anyway (for reconstructing the URL in various ways); the real question is whether you *really* need a browser-parsed version of it (which I'd really leave off from this discussion, that's a detail) |
| 23:44 | <SamB> | would be a string |
| 23:45 | <SamB> | zewt: point, yes |
| 23:45 | <zewt> | (we're already pretty far ahead of things talking about exposing it in location at all) |
| 23:45 | <SamB> | you don't REALLY need a browser-parsed version |
| 23:45 | <JonathanNeal> | zewt: re: "URL into three major parts", it already is, remember that #anchor will do something in your browser if you have <div id="anchor">. |
| 23:45 | <JonathanNeal> | Sorry if you meant that and I just misunderstood you. |
| 23:46 | <zewt> | JonathanNeal: sort of, but that's not a distinct part of the URL vs. script stuff |
| 23:46 | <KevinMarks_> | o_O |
| 23:46 | <JonathanNeal> | It is as distinct as hash search, no? At least, my library was written to do exactly what browsers do for hash anchors. |
| 23:46 | <KevinMarks_> | exactly |
| 23:47 | <KevinMarks_> | ID already owns this namespace |
| 23:47 | <zewt> | today there's no way to differentiate between "the client's own special magic stuff in the hash" and "platform features in the hash" |
| 23:47 | <KevinMarks_> | except the bit with spaces in |
| 23:49 | <zewt> | nope, because pages can already put spaces in the hash for their own use |
| 23:50 | <zewt> | of course, they can also put "##text=foo" in the hash, but one is less likely than the other |
| 23:50 | <SamB> | http://url.spec.whatwg.org/#api seems kind of strangely-indented |
| 23:51 | <KevinMarks_> | I love that my use case is a categorical collision and yours is a statistical argument |
| 23:51 | <SamB> | KevinMarks_: huh? |
| 23:52 | <KevinMarks_> | if fragmentions had to have 10 words in, would you be happy then? |
| 23:52 | <KevinMarks_> | 4? |
| 23:52 | <zewt> | to restate: "http://foo.com#post10##text=foo"; gives script authors a way to encode their own data into the url for AJAX/history API use ("post10"), and also use text search (or ID links, or other things) in the same URL; no other proposal so far does that |
| 23:53 | <KevinMarks_> | that's not a use case |
| 23:53 | <zewt> | ... |
| 23:53 | <SamB> | zewt: and with ##css=, we could finally link to individual form controls in mediawiki preferences |
| 23:54 | <SamB> | (or ##anchor or whatever) |
| 23:54 | <KevinMarks_> | I say "lots of people want to link to the text of pages" you say "some mythical developer wants to combine the history api wiht text search |
| 23:54 | <zewt> | wow, I've never been called mythical before |
| 23:55 | <SamB> | KevinMarks_: trust me, there are pages people will want to do this on that are not made up |
| 23:55 | <zewt> | because I'd sure like to be able to write history API pages without breaking ID links, but it's not possible |
| 23:55 | SamB | goes looking for some apple docs ... |
| 23:55 | <KevinMarks_> | aaron added fragmentions to media wiki in about 20 minutes |
| 23:55 | <KevinMarks_> | it's handy |
| 23:55 | <SamB> | KevinMarks_: that won't do what I just said though |
| 23:56 | <SamB> | especially considering that that part of the UI is multilingual |
| 23:56 | <KevinMarks_> | yes it does: http://indiewebcamp.com/Special:Preferences##New+signature |
| 23:57 | <KevinMarks_> | you have to sign in, mind |
| 23:57 | <SamB> | what if I have my UI set to klingon or something |
| 23:58 | <SamB> | (obviously not actually klingon, and not actually me, but it does turn out that klingon has an ISO code and everything) |
| 23:58 | <KevinMarks_> | whats the iso code for klingon? |
| 23:59 | <SamB> | I think it's tlh |
| 23:59 | <SamB> | anyway, consider e.g. https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/Introduction/Introduction.html#//apple_ref/doc/uid/TP30001066 |
| 23:59 | <KevinMarks_> | what's kn? |
| 23:59 | <KevinMarks_> | that looks like klingon |
