https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #84 from Quiddity pandiculat...@gmail.com ---
1) As I said in comment #6 - the mailto, irc, audio/video, and pdf icons are
frequently useful for:
* Readers to have principle of least astonishment when clicking on links
which often
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Gadget850 ed.pal...@gmail.com changed:
What|Removed |Added
CC||ed.pal...@gmail.com
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #83 from Jon jrob...@wikimedia.org ---
(In reply to Bartosz Dziewoński from comment #81)
So the general agreement is that it was good in the beginning and the change
above was a bad idea.
I don't know how you have determined this
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #80 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 141973 abandoned by Bartosz Dziewoński:
Linker: Add CSS classes to external links to some protocols/filetypes
Reason:
Right.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
Status|PATCH_TO_REVIEW |NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
See Also|
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #82 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 154350 had a related patch set uploaded by Bartosz Dziewoński:
Restore external links icons
https://gerrit.wikimedia.org/r/154350
--
You are receiving this
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Gerrit Notification Bot gerritad...@wikimedia.org changed:
What|Removed |Added
Status|NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #73 from Krinkle krinklem...@gmail.com ---
(In reply to Bartosz Dziewoński from comment #54)
(In reply to Gabriel Wicke from comment #52)
Do we have actual measurements that verify that this benefits total page
view performance
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #74 from ssas...@wikimedia.org ---
Phew .. long discussion. I could have gone either way (selectors or css
classes) till I hit Gabriel and Roan's comments and now Krinkle's about client
burden and code duplication to support
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #75 from Jon jrob...@wikimedia.org ---
The icons for audio, video etc have been gone for some time without any
complaints that I am aware of. Maybe because a lot of these styles are
implemented in MediaWiki:Common.css
Let's not
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #76 from Isarra zhoris...@gmail.com ---
(In reply to Jon from comment #75)
The icons for audio, video etc have been gone for some time without any
complaints that I am aware of. Maybe because a lot of these styles are
implemented
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #77 from Jon jrob...@wikimedia.org ---
Isarra. What was the motivation for putting them in in the first place?
Putting styles in both core and common.css that do the same thing is a terrible
terrible terrible thing and we should at
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #78 from Andre Klapper aklap...@wikimedia.org ---
(In reply to Jon from comment #77)
PS. How can I remove myself from this bug. Since I'm the creator, it doesn't
seem possible.
Sorry, only available in next version:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #79 from Isarra zhoris...@gmail.com ---
(In reply to Jon from comment #77)
Isarra. What was the motivation for putting them in in the first place?
Given that this was orginally added in 2004, I couldn't say. I can, however,
point
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #71 from C. Scott Ananian canan...@wikimedia.org ---
+1 to Roan and Gabriel.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #72 from Gabriel Wicke gwi...@wikimedia.org ---
Re performance, I have not been able to find anything on the web that indicates
that CSS selector performance is a significant issue in practice.
This SO articles seems to provide a
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #68 from Bartosz Dziewoński matma@gmail.com ---
Oh, MediaWiki uses more advanced things for styling (like… LESS?), that was
never the problem. The only problem was unspecified performance issues.
But I really don't feel like
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #69 from Gabriel Wicke gwi...@wikimedia.org ---
One issue I didn't mention yet is editor complexity. Every editor for our HTML
including VE will need to replicate the class logic from the parser. This
includes future
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #70 from Roan Kattouw roan.katt...@gmail.com ---
(In reply to Gabriel Wicke from comment #69)
One issue I didn't mention yet is editor complexity. Every editor for our
HTML including VE will need to replicate the class logic from
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #67 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to Bartosz Dziewoński from comment #66)
As I said before, I'm okay with doing this either way (we can revert the old
patch that removed this feature in Vector), but let's
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #66 from Bartosz Dziewoński matma@gmail.com ---
(In reply to Gabriel Wicke from comment #64)
Looking at the linked CSS [1], to me it seems that the most complex rules
are those matching on file extensions to figure out video /
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #65 from Matthew Flaschen mflasc...@wikimedia.org ---
(In reply to Gabriel Wicke from comment #62)
The .plainlinks class was normally used to mark this up, and applied to all
links inside a content block. How does this work with
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #64 from Gabriel Wicke gwi...@wikimedia.org ---
Looking at the linked CSS [1], to me it seems that the most complex rules are
those matching on file extensions to figure out video / audio / document links.
As those links are not
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #48 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 141973 had a related patch set uploaded by Bartosz Dziewoński:
Linker: Add CSS classes to external links to some protocols/filetypes
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Gerrit Notification Bot gerritad...@wikimedia.org changed:
What|Removed |Added
Status|REOPENED
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #49 from Jared Zimmerman (WMF) jared.zimmer...@wikimedia.org ---
We'll have https (secure) and external link icons in wiki font soon (probably
already) but wiki font isn't in core yet, these issues are related but could be
separate
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
C. Scott Ananian canan...@wikimedia.org changed:
What|Removed |Added
CC|
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #51 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com ---
(In reply to C. Scott Ananian from comment #50)
Hm, Parsoid does not tag links with classes. The only CSS would work fine
for parsoid-generated HTML; the new CSS will
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #52 from Gabriel Wicke gwi...@wikimedia.org ---
We have use cases where uncompressed HTML is sent over the wire (HTML save from
VE), so uncompressed DOM size does matter.
Do we have actual measurements that verify that this
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Gabriel Wicke gwi...@wikimedia.org changed:
What|Removed |Added
CC|
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #54 from Bartosz Dziewoński matma@gmail.com ---
(In reply to Gabriel Wicke from comment #52)
Do we have actual measurements that verify that this benefits total page
view performance in practice?
We don't. Jon provided some
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #55 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to Bartosz Dziewoński from comment #54)
(In reply to Gabriel Wicke from comment #52)
Do we have actual measurements that verify that this benefits total page
view
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #56 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com ---
(In reply to Gabriel Wicke from comment #52)
We have use cases where uncompressed HTML is sent over the wire (HTML save
from VE), so uncompressed DOM size does matter.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #57 from C. Scott Ananian canan...@wikimedia.org ---
@Daniel: long story, but basically gzip compression in HTTP only works in the
download direction. There is no equivalent content negotiation for uploads in
HTTP.
--
You are
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #58 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to C. Scott Ananian from comment #57)
@Daniel: long story, but basically gzip compression in HTTP only works in
the download direction. There is no equivalent content
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #59 from Jon jrob...@wikimedia.org ---
Another reason is styles written in this way are not reusable.
What if we want to use the same audio icon elsewhere?
With an icon-audio selector class we can.
With a selector based on href we
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #60 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com ---
(In reply to C. Scott Ananian from comment #57)
@Daniel: long story, but basically gzip compression in HTTP only works in
the download direction. There is no
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #61 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com ---
(In reply to Jon from comment #59)
Another reason is styles written in this way are not reusable.
I'll add one more reason.
What if we don't want an icon? This should
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #62 from Gabriel Wicke gwi...@wikimedia.org ---
(In reply to Jon from comment #59)
Another reason is styles written in this way are not reusable.
What if we want to use the same audio icon elsewhere?
With an icon-audio
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #63 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com ---
(In reply to Gabriel Wicke from comment #62)
I'd like to see us moving away from descendant selectors and explore OOCSS
[1] as a solution to our CSS mess we have
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
Blocks||61178
--
You
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Bartosz Dziewoński matma@gmail.com changed:
What|Removed |Added
Status|PATCH_TO_REVIEW |RESOLVED
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #45 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 124618 merged by jenkins-bot:
Follow-up: If985b16c – Vector external link change release notes
https://gerrit.wikimedia.org/r/124618
--
You are receiving this
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Nemo federicol...@tiscali.it changed:
What|Removed |Added
CC||federicol...@tiscali.it
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Nemo federicol...@tiscali.it changed:
What|Removed |Added
See Also|
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #43 from Bartosz Dziewoński matma@gmail.com ---
I can tell you that it's customary on sites like Reddit to add a PDF warning
to a description of a link that points directly to a PDF document. (Other file
types don't really come
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #44 from Gerrit Notification Bot gerritad...@wikimedia.org ---
Change 124618 had a related patch set uploaded by Jdlrobson:
Follow up to If985b16c4f682d737683597ed80951c6d6644c8f
https://gerrit.wikimedia.org/r/124618
--
You are
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Gerrit Notification Bot gerritad...@wikimedia.org changed:
What|Removed |Added
Status|NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Steven Walling swall...@wikimedia.org changed:
What|Removed |Added
Summary|Ridiculous number of CSS|Large number of
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #39 from Bawolff (Brian Wolff) bawolff...@gmail.com ---
(In reply to Jon from comment #37)
The world is not breaking. The world of Vector is just going through
turbulence.
I didn't mean to point fingers at any specific event, and
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #40 from Isarra zhoris...@gmail.com ---
(In reply to Jared Zimmerman (WMF) from comment #36)
(In reply to Isarra from comment #34)
We did a beta feature, it was called typography refresh, and little to no
feedback (negative or
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #41 from MZMcBride b...@mzmcbride.com ---
(In reply to Jon from comment #37)
Commits and reverts are cheap.
No. There's almost no evidence to suggest that commits and reverts of this
nature are cheap. There's a ton of evidence to
https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
Matthew Flaschen mflasc...@wikimedia.org changed:
What|Removed |Added
Status|PATCH_TO_REVIEW |NEW
55 matches
Mail list logo
