I just want to stand on land.
- User Since
- Oct 9 2014, 1:53 AM (193 w, 2 d)
- IRC Nick
- LDAP User
- MediaWiki User
Wed, Jun 20
Fri, Jun 15
Cool, thanks @MarcoAurelio!
I am not sure if this was a conscious decision by @Nirzar, but I definitely remember deliberately aligning it that way. Here is a screenshot from the zeplin mock:
No worries, I had forgotten about it too!
The following now redirect to https://design.wikimedia.org/style-guide/:
Wed, Jun 13
Tue, Jun 12
@Volker_E suggested in a meeting that we could use a <small> tag too. It doesn't make a difference to the screen reader, but would be more semantic.
Not sure what this is.
This sounds like a good DOM structure, but we might need to figure out how to do this correctly.
Mon, Jun 11
Thanks @Jack_who_built_the_house, this is great
Sun, Jun 10
Sat, Jun 9
Fri, Jun 8
Thu, Jun 7
I was just looking at @Florian's patch and I think there are any issues with it, I suppose it just got lost in review queues.
It might prove tricky to implement any accessibility guideline on PopupButtonWidget itself as its in being inherited and used in all sorts of non-tooltip ways — it is a table in Kartographer, colorpicker in RCFilter, as settings panel in ContentTranslation, and a map in UploadWizard.
Wed, Jun 6
I think we can safely skip
Thu, May 31
Wed, May 30
We have different types of Special pages and not all need the same treatment. Pages which primarily show just one form (Upload, BookSources) are alright with form taking up vertical space. Then come the list or report special pages which might (AllPages, ActiveUsers) or might not (BrokenRedirects) have filtering capabilities. The ones with the filtering could surely use something like a collapsible form as you're suggesting.
Thanks for explaining @Volker_E, however when I use the 3rd item the result is:
Tue, May 29
I see some pre-filled content here as of now:
Mon, May 28
May 21 2018
I just remembered that we also have notices, and the help config documentation has the following line:
An idea for a first step towards a solution could be to have a different help trigger in forms (helpInline?), so designers & devs can choose from PopupButtonWidget or inlined labels – such we don't break existing, complex, verbose layouts and still provide a way out.
May 16 2018
Some experimental patches to see results in the demo:
May 14 2018
Yep, in its current form the aria-haspopup is not helping at all, removing it makes sense. Also, re-reading the spec makes me feel that no matter the element (surrounding span or a), this attribute doesn't belong here since the popup isn't a menu, listbox, tree, grid or dialog.
May 11 2018
I am a bit confused, does the content size column in the table in the description refer to .content-box or the .content?
May 7 2018
@Volker_E, just to clarify, our situation isn't the same as the one that you link to, right? The linked code is not a button with title but a button with an image that has a title:
May 5 2018
May 1 2018
Apr 26 2018
Apr 24 2018
Thanks for explaining
Apr 23 2018
I am confused, do we use the oojs-ui from vendor/ or the one in resources/lib?
Apr 20 2018
After switching to MultiSelectField:
Apr 18 2018
Apr 17 2018
It did not work the first time I re-did docker-compose up and en.replica was complaining about volumes (unfortunately I did not save the error). After I prune'd all the volumes and images and up'd again and it worked.
Thanks @dmaza, would it be ok to add that to the README? — https://github.com/wikimedia/InteractionTimeline/pull/83
Apr 16 2018
I did a quick read through of the style guide and found some minor issues. Happy to submit a PR if we think they need to be fixed .
Yikes! Submitted that comment before finishing it. Will add again once I'm ready :)
Apr 13 2018
Apr 11 2018
Added a .lighttpd.conf file to $HOME and setup a 301 for all pages. This (hopefully) shouldn't cause T172834: Tool "styleguide" redirects to GitHub without consent again since we're redirecting to design.wikimedia this time .
Apr 10 2018
A collapsible form similar to RevisionSlider comes to mind.