[Wikitech-l] Scrum of Scrums notes, 2015-02-18
https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-18 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
I was digging and I found that commit you sent - eefe1b13a but you can
see that this commit modified 2 functions: both open and closeElement,
however for some reason the code was removed from closeElement so now
calling openElement('html') would produce empty string, while
closeElement('html') would produce /html and that should IMHO create
HTML code that would only contain closing tags in case that html /
head didn't have any parameters. Actually head, at least on wmf
installation doesn't have any parameters, but it has opening tag,
which is weird. (Perhaps wgWellFormedXml is true by default?)
On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber bvib...@wikimedia.org wrote:
On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com wrote:
Can someone explain the point of these lines to me?
https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
Someone thought it would be clever to reduce page size by a few bytes here
and there. :)
In practice we always have attributes on the html so this would only take
effect on head for this particular case. However there are other bits
which can be more aggressively dropped, such as closing tags for table
parts etc.
Here's the commit that added this and related bits:
https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.
I believe that's also covered, yes. (Keep in mind also that the way the
HTML content model works is that those elements always exist in the DOM;
the tags can simply be omitted from the markup because they are implied by
the surrounding content.)
It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?
I think we still have the well-formed XML mode enabled for
backwards-compatibility?
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com wrote: Can someone explain the point of these lines to me? https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269 Someone thought it would be clever to reduce page size by a few bytes here and there. :) In practice we always have attributes on the html so this would only take effect on head for this particular case. However there are other bits which can be more aggressively dropped, such as closing tags for table parts etc. Here's the commit that added this and related bits: https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323 If these tags are optional, they can be there, so why remove them? If you remove them, you should probably also care about them in closeElement() so that mediawiki doesn't produce html which has only ending tags for html and head. I believe that's also covered, yes. (Keep in mind also that the way the HTML content model works is that those elements always exist in the DOM; the tags can simply be omitted from the markup because they are implied by the surrounding content.) It seems that on WMF installation we don't use anyway as there is head tag. So why is it there? What purpose does it server? I think we still have the well-formed XML mode enabled for backwards-compatibility? -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
I think it's the other way, omiting the html tags is probably correct,
as long as both opening and ending tags are omitted :P so I think the
closeElement function needs a fix
On Wed, Feb 18, 2015 at 10:42 PM, Ricordisamoa
ricordisa...@openmailbox.org wrote:
Uploaded https://gerrit.wikimedia.org/r/191473/ for consistency with
closeElement.
Thanks for reporting.
Il 18/02/2015 22:38, Petr Bena ha scritto:
I was digging and I found that commit you sent - eefe1b13a but you can
see that this commit modified 2 functions: both open and closeElement,
however for some reason the code was removed from closeElement so now
calling openElement('html') would produce empty string, while
closeElement('html') would produce /html and that should IMHO create
HTML code that would only contain closing tags in case that html /
head didn't have any parameters. Actually head, at least on wmf
installation doesn't have any parameters, but it has opening tag,
which is weird. (Perhaps wgWellFormedXml is true by default?)
On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber bvib...@wikimedia.org
wrote:
On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com wrote:
Can someone explain the point of these lines to me?
https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
Someone thought it would be clever to reduce page size by a few bytes
here
and there. :)
In practice we always have attributes on the html so this would only
take
effect on head for this particular case. However there are other bits
which can be more aggressively dropped, such as closing tags for table
parts etc.
Here's the commit that added this and related bits:
https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.
I believe that's also covered, yes. (Keep in mind also that the way the
HTML content model works is that those elements always exist in the DOM;
the tags can simply be omitted from the markup because they are implied
by
the surrounding content.)
It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?
I think we still have the well-formed XML mode enabled for
backwards-compatibility?
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
That patch you made even breaks tests:
https://integration.wikimedia.org/ci/job/mediawiki-core-phpcs-HEAD/13002/console
:)
so either remove a unit test for that feature, or just fix the
closeElement but I don't even know if it's really broken, maybe there
is some more magic on behing that would fix the broken html before it
gets printed out
On Wed, Feb 18, 2015 at 10:47 PM, Petr Bena benap...@gmail.com wrote:
I think it's the other way, omiting the html tags is probably correct,
as long as both opening and ending tags are omitted :P so I think the
closeElement function needs a fix
On Wed, Feb 18, 2015 at 10:42 PM, Ricordisamoa
ricordisa...@openmailbox.org wrote:
Uploaded https://gerrit.wikimedia.org/r/191473/ for consistency with
closeElement.
Thanks for reporting.
Il 18/02/2015 22:38, Petr Bena ha scritto:
I was digging and I found that commit you sent - eefe1b13a but you can
see that this commit modified 2 functions: both open and closeElement,
however for some reason the code was removed from closeElement so now
calling openElement('html') would produce empty string, while
closeElement('html') would produce /html and that should IMHO create
HTML code that would only contain closing tags in case that html /
head didn't have any parameters. Actually head, at least on wmf
installation doesn't have any parameters, but it has opening tag,
which is weird. (Perhaps wgWellFormedXml is true by default?)
On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber bvib...@wikimedia.org
wrote:
On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com wrote:
Can someone explain the point of these lines to me?
https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
Someone thought it would be clever to reduce page size by a few bytes
here
and there. :)
In practice we always have attributes on the html so this would only
take
effect on head for this particular case. However there are other bits
which can be more aggressively dropped, such as closing tags for table
parts etc.
Here's the commit that added this and related bits:
https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.
I believe that's also covered, yes. (Keep in mind also that the way the
HTML content model works is that those elements always exist in the DOM;
the tags can simply be omitted from the markup because they are implied
by
the surrounding content.)
It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?
I think we still have the well-formed XML mode enabled for
backwards-compatibility?
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
Most of browsers would probably handle it OK, but validators not. On Wed, Feb 18, 2015 at 10:45 PM, Petr Bena benap...@gmail.com wrote: Yep That makes me feel like this is bug which everyone overlooked because it's true by default. If you set it to false mediawiki would likely write out syntactically wrong code. On Wed, Feb 18, 2015 at 10:43 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com wrote: (Perhaps wgWellFormedXml is true by default?) It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
Uploaded https://gerrit.wikimedia.org/r/191473/ for consistency with
closeElement.
Thanks for reporting.
Il 18/02/2015 22:38, Petr Bena ha scritto:
I was digging and I found that commit you sent - eefe1b13a but you can
see that this commit modified 2 functions: both open and closeElement,
however for some reason the code was removed from closeElement so now
calling openElement('html') would produce empty string, while
closeElement('html') would produce /html and that should IMHO create
HTML code that would only contain closing tags in case that html /
head didn't have any parameters. Actually head, at least on wmf
installation doesn't have any parameters, but it has opening tag,
which is weird. (Perhaps wgWellFormedXml is true by default?)
On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber bvib...@wikimedia.org wrote:
On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com wrote:
Can someone explain the point of these lines to me?
https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
Someone thought it would be clever to reduce page size by a few bytes here
and there. :)
In practice we always have attributes on the html so this would only take
effect on head for this particular case. However there are other bits
which can be more aggressively dropped, such as closing tags for table
parts etc.
Here's the commit that added this and related bits:
https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.
I believe that's also covered, yes. (Keep in mind also that the way the
HTML content model works is that those elements always exist in the DOM;
the tags can simply be omitted from the markup because they are implied by
the surrounding content.)
It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?
I think we still have the well-formed XML mode enabled for
backwards-compatibility?
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com wrote: (Perhaps wgWellFormedXml is true by default?) It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
Yep That makes me feel like this is bug which everyone overlooked because it's true by default. If you set it to false mediawiki would likely write out syntactically wrong code. On Wed, Feb 18, 2015 at 10:43 PM, Gergo Tisza gti...@wikimedia.org wrote: On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com wrote: (Perhaps wgWellFormedXml is true by default?) It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global user pages deployed to all wikis
Hi Pine, I'm actually the owner of SUL finalization. It is happening in April. The big messaging, rename schema, and a special page listing users that will be affected is coming in a few days and there will be a big update then. You can always follow along on Phabricator.[1][2] Until then, let us continue to congratulate Kunal and cohorts! 1. https://phabricator.wikimedia.org/T37707 2. https://phabricator.wikimedia.org/tag/sul-finalization/ Keegan Peterzell Community Liaison, Product Wikimedia Foundation On Feb 19, 2015 12:56 AM, Pine W wiki.p...@gmail.com wrote: Thanks for the very good news. Dan, can we get an ETA about SUL finalization? Pine On Feb 18, 2015 5:07 PM, Legoktm legoktm.wikipe...@gmail.com wrote: Hello! Global user pages have now been deployed to all public wikis for users with CentralAuth accounts. Documentation on the feature is available at mediawiki.org[1], and if you notice any bugs please file them in Phabricator[2]. Thanks to all the people who helped with the creation and deployment (incomplete, and in no particular order): Jack Phoenix ShoutWiki, Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped with testing it while it was in beta. [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage [2] https://phabricator.wikimedia.org/maniphest/task/create/? projects=PHID-PROJ-j536clyie42uptgjkft7 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global user pages deployed to all wikis
Thanks for the very good news. Dan, can we get an ETA about SUL finalization? Pine On Feb 18, 2015 5:07 PM, Legoktm legoktm.wikipe...@gmail.com wrote: Hello! Global user pages have now been deployed to all public wikis for users with CentralAuth accounts. Documentation on the feature is available at mediawiki.org[1], and if you notice any bugs please file them in Phabricator[2]. Thanks to all the people who helped with the creation and deployment (incomplete, and in no particular order): Jack Phoenix ShoutWiki, Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped with testing it while it was in beta. [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage [2] https://phabricator.wikimedia.org/maniphest/task/create/? projects=PHID-PROJ-j536clyie42uptgjkft7 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
On 19/02/15 08:43, Gergo Tisza wrote: On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com wrote: (Perhaps wgWellFormedXml is true by default?) It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml There was a Bugzilla report and Gerrit change requesting that it be set to false: https://phabricator.wikimedia.org/T52040 https://gerrit.wikimedia.org/r/#/c/70036/ I was against it, partly because of the omitted head tag. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikitech-ambassadors] Global user pages deployed to all wikis
Thanks for all _your_ work seeing this through the finish line as well, Kunal. This is a great first step towards better user profile support, and brings all Wikimedia wikis closer together. -- Erik Möller VP of Product Strategy, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Html.php line 269
I would also recommend against actively trying to emit barely parsing output. Any savings after compression should be rather small, and if only end tags are omitted the DOM will of course still be the same size after parsing. In Parsoid we went to some modest lengths https://github.com/wikimedia/parsoid/blob/master/lib/XMLSerializer.js to produce polyglot markup http://www.w3.org/TR/html-polyglot/, which is both valid XML and HTML5. This has enabled consumers to use either XML or HTML5 parsers, which has proven very useful in practice. For example, this makes it easier to consume this content using PHP's libxml. Doing the same in MediaWiki core is admittedly harder, but I still think that we should follow the robustness principle https://en.wikipedia.org/wiki/Robustness_principle wherever we can. Gabriel On Wed, Feb 18, 2015 at 5:59 PM, Tim Starling tstarl...@wikimedia.org wrote: On 19/02/15 08:43, Gergo Tisza wrote: On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com wrote: (Perhaps wgWellFormedXml is true by default?) It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml There was a Bugzilla report and Gerrit change requesting that it be set to false: https://phabricator.wikimedia.org/T52040 https://gerrit.wikimedia.org/r/#/c/70036/ I was against it, partly because of the omitted head tag. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Global user pages deployed to all wikis
Hello! Global user pages have now been deployed to all public wikis for users with CentralAuth accounts. Documentation on the feature is available at mediawiki.org[1], and if you notice any bugs please file them in Phabricator[2]. Thanks to all the people who helped with the creation and deployment (incomplete, and in no particular order): Jack Phoenix ShoutWiki, Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped with testing it while it was in beta. [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage [2] https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ-j536clyie42uptgjkft7 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] VisualEditor weekly triage meetings – 2015-02-18 – minutes
Here are the minutes for this week's VisualEditor weekly triage meeting on 2015-02-18. *Item 1 – Release criteria* The release criteria at https://phabricator.wikimedia.org/project/sprint/profile/1015/ (note new URL) were considered. It was proposed and agreed that the wording for Qualitative UX testing be changed from Most users to a specific number of 75%, and similarly in Meets specified performance benchmarks, that reasonable was changed to a specific number of 150%. These changes have been made. *Item 2 – Review of fixed tickets since last week* These accepted items were fixed and so will be released in this week's production release unless otherwise noted. … in VisualEditor: - https://phabricator.wikimedia.org/T88650 – Support data-mw.body.id for reference contents - https://phabricator.wikimedia.org/T88148 – class=wikitable wikitable corrupted to class=wikitable - https://phabricator.wikimedia.org/T87161 – Default to not performing sanity checks - https://phabricator.wikimedia.org/T86401 – Cutting and pasting a paragraph causes (only) the last inline template to be replaced by HTML - https://phabricator.wikimedia.org/T74929 – Using browser native interactive spell-check when the changed word in the only item in the paragraph causes endless insertions in Firefox [*fixed in our IME work in January*] - https://phabricator.wikimedia.org/T74398 – Actually run MediaWiki-VisualEditor's tests for MWHeadingNode / MWPreformattedNode - https://phabricator.wikimedia.org/T67873 – Cannot go to the next line of an article after inserting a special character in a block slug and TypeError: Inserted data is trying to close the root node (at index 0) appears [*fixed earlier*] - https://phabricator.wikimedia.org/T65462 – Using browser native interactive spell-check tool causing repeated automatic deletion in Chrome [*fixed in our IME work in January*] - https://phabricator.wikimedia.org/T61748 – Native browser interactive spell-check tool fails to get content into DM, just CE, in Safari [*fixed in our IME work in January*] The fixed tickets represent 83 story points. There are 1020 remaining points in the list of items accepted as of the end of the meeting. … in dependencies: - https://phabricator.wikimedia.org/T88660 – Parsoid Cite: Render missing reflists - https://phabricator.wikimedia.org/T88019 – Transclusion marker meta tags being left behind in some nested extension/transclusion scenarios - https://phabricator.wikimedia.org/T85870 – Parsoid performance analysis - https://phabricator.wikimedia.org/T75955 – RESTBase / Parsoid integration - waiting for parsoid deploy - https://phabricator.wikimedia.org/T69787 – Investigate remaining rtselser errors in parserTest runs *Item 3 – Review of nominated tickets* Nominated tickets accepted: … as corruption stability issues: - https://phabricator.wikimedia.org/T89192 – [Regression wmf-16] Including a template/comment/table/gallery/math node in a slug makes the editor completely unresponsive - https://phabricator.wikimedia.org/T89309 – [Regression wmf-17] Safari - cannot click in any check-box … as performance issues: - https://phabricator.wikimedia.org/T89543 – ve.init.mw.ViewPageTarget.transformPage triggers recalculate style due to $.fn.animate - https://phabricator.wikimedia.org/T89423 – Massive recalculate style triggered by OO.ui.Widget.setDisabled - https://phabricator.wikimedia.org/T89536 – Instrument (i.e., track) additional progress markers for VE load - https://phabricator.wikimedia.org/T89735 – VisualEditor is emitting event timing.ve.behavior.firstTransaction.undefined … as testing issues: - https://phabricator.wikimedia.org/T89075 – Investigate Chrome disconnect failures when running MediaWiki tests on labs slaves … as feature issues: - https://phabricator.wikimedia.org/T88152 – Cite: 'Autofill from URL' initially shows Basic as a type for inserted citation in context menu, then corrects when re-selected - https://phabricator.wikimedia.org/T89352 – Make slugs keyboard accessible again - https://phabricator.wikimedia.org/T76398 – External link interface for link dialogue [high risk area; accepted with provision that we will likely have to modify work based on user testing] - https://phabriactor.wikimedia.org/T76397 – Search interface for link dialogue [ high technological risk area; accepted with lower priority, to be re-assessed later ] - https://phabricator.wikimedia.org/T52036 – Focus highlights for elements using CSS column-count are too tall in Chrome [accepted as a polish issue] - https://phabricator.wikimedia.org/T73085 – Comments in unsafe content locations are not displayed [accepted as a lower-priority issue; needs technological
