[21:38:05] == Content == would conflict with that, right? At least == content == would. [21:38:23] (not a new problem, I know) [21:38:36] yeah, so strtolower() doesn't make it much worse than it already is :P [21:38:55] [21:39:08] prefixing would probably solve it but more bc breaks... [21:39:19] Well, we could fix this by always adding a prefix [21:39:30] SMalyshev: we are breaking b/c anyway. doesn't matter "how much" we break it [21:39:32] we don't want to break existing section links just for the sake of it [21:39:44] the main problem is manually inputting wiki links [21:40:05] do people actually type fragment links? [21:40:06] the prefix would have to "sometimes" be added to whatever comes after the # in the links [21:40:17] also, just like page links, the whole page of this work is to make them human-readable [21:40:31] SMalyshev: they copy from the url, or they copy the section heading. sometimes they type. I do. [21:40:36] #mw-section-Blah is not that readable [21:40:43] the policy for new code is to use an mw- prefix to avoid conflicts with content [21:40:52] why sometimes? we could always add it: #section-Content or #section-Содержание [21:41:21] SMalyshev: unless the prefix is already there. because people cutr it from the url. including the prefix,. [21:41:27] DanielK_WMDE_: you are not a typical case :) [21:41:34] oh... could we use #section#Foo? [21:41:35] I think it's OK for content to own the top level, except for certain reserved prefixes [21:41:35] is that legal? [21:41:45] SMalyshev: so my mother tells me [21:42:11] * TimStarling is trying to figure out if DanielK_WMDE_ is serious [21:42:43] TimStarling: about #section#foo? I'm seriously curious, not proposing it ;) [21:43:00] also, if we removing the ambiguity would be an easy fix, I'd support doing it now [21:43:12] but it probably creates more problems than it selves. [21:43:24] that looks bad, honestly [21:43:29] still, worth exploring, if there is nothing more important to discuss [21:43:53] MaxSem: ##foo ;) [21:44:02] you can have an ID "section#foo" which will become the fragment "#section%23foo" [21:44:08] == #hashtags == [21:46:17] TimStarling: my idea was that this isn't the same as "#section#foo", so it woudl avoid clashes. and people may know to copy and past only from the las #. [21:46:22] but it's a though experiment, not a proposal [21:47:38] to avoid clashes between content and code that is inappropriately using unprefixed IDs? [21:47:56] to avoid these clashes you would like to prefix all fragments? [21:48:24] let's say i'm enteraining the idea [21:48:56] given that "content" and "top" are candidates for clashes on all pages, it doesn't seem to far fetched. [21:49:07] just change those [21:49:22] breaks all the user scripts ;) [21:49:50] these in particular are used a lot. but whatever [21:49:53] 10 minute warning [21:50:04] anything more relevant to discuss than my ramblings? [21:51:15] what are the conclusions? :P [21:51:21] I hope I am making it clear that I am against the idea of prefixing all fragments [21:51:43] +1 [21:52:13] for the record, i'm not advocating it either. but i found the idea worth exploring. forgive me the waste of time [21:52:43] I think it's intrusive, it's an important goal to have nice-looking URLs [21:53:13] I wouldn't mind having a lot of code to support that goal [21:54:10] ok, let's try and summarize. [21:54:18] we have been getting better at prefixing system ids and classes [21:54:24] there were no objections raised against the approach taken [21:54:39] there was some discussionb about function names which can be continued on the patch [21:55:19] did i miss anything? [21:57:32] ok then [21:57:39] #info there were no objections raised against the approach taken [21:57:59] #info there was some discussion about method names which can be continued on the patch [21:58:12] thanks everybody! [22:00:05] one final remark re prefixing: I'm pretty certain Parsoid already protects the mw-* namespace [22:00:31] #endmeeting [22:00:31] Meeting ended Wed Jul 19 22:00:31 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:31] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-07-19-21.02.html [22:00:31] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-07-19-21.02.txt [22:00:31] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-07-19-21.02.wiki [22:00:32] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-07-19-21.02.log.html [22:00:34] gwicke: oh? how? [22:01:02] it encodes the malicious attributes as data attributes instead [22:01:13] let me find the code [22:02:53] gwicke: oh, you mean if someone puts

into the wikitext? sure, but what if they put == mw-foo == into the wikitext? [22:02:58] found https://github.com/wikimedia/parsoid/blob/c014c556b862ae4a23bec6d188919a523e09aa31/lib/wt2html/tokenizer.utils.js#L331, but that doesn't apply to ids [22:03:03] yeah [22:04:01] I don't think Parsoid handles that yet [22:04:17] one way to deal with that gracefully would be to treat it as a duplicate, and append numbers [22:04:29] the same way we already deal with duplicate headings [22:05:43] hehe: there is a todo in https://github.com/wikimedia/parsoid/blob/e1f53602b2f8f0ec9a1765f35a5a5b1c231d526a/lib/utils/DOMUtils.js#L320 [22:06:14] sorry .. what is the issue with ids? .. i just paged in and notice dthis trailing discussion. [22:06:59] subbu: the issue of id conflicts between system (ui) ids & user specified ids / those corresponding to headings came up [22:07:15] parsoid handles that right now .. as far as i know.. let me try an example. [22:07:48] [subbu@earth includes] echo '

foo

\n==data-mw==' | parse.js [22:07:48] .. [22:07:48]

foo

[22:07:48]

data-mw

[22:07:48] .. [22:08:35] that's duplicates, but I don't think it protects ids starting with mw- [22:09:05] or mw[0-9a-f]+ [22:09:18] ah, ok. [22:10:41] subbu: also, == content == clashes. [22:11:05] that was one of the examples that started this sidebar [22:11:27] DanielK_WMDE_, say more, i didn't understand. [22:11:37] or should i read the transcript? :) [22:11:47] is gerrit down? [22:11:58] if we used a prefix like mw- consistently for all UI elements & protected that namespace from user-defined ids, then we could avoid conflicts [22:12:00] mw uses id="content" and id="top" internally [22:12:16] if you have == content == in your wikitext, you get a duplicate id [22:12:32] oh, content is actually a system id. [22:12:46] ok .. is there a list of these "system" ids anywhere? [22:12:47] yeah [22:12:51] besides the mw- prefix? [22:13:04] the legacy ones are fairly random [22:13:05] no, just a handful [22:13:28] i think content and top are still around because changing them would break a lot of 3rd party code that messes with the dom [22:13:32] gadgets & stuff [22:14:07] also styles [22:14:27] don't want to know how badly broken pages that abuse such ids currently look [22:15:10] thankfully they tend to be fixed quickly [22:15:40] can you put multiple ids on a single element? id="foo bar"? [22:15:53] not in HTML [22:16:07] * subbu heads out ... will read transcript later