Tue, Mar 21
Sat, Mar 18
Fri, Mar 17
@Volker_E happy with your comments, was just curious. Still getting used to github review, couldn't see your reply about the added sections and trying to find those comments lead to pseudo-404s. Just wanted to make sure you saw those.
In the mediawiki and apex the proportions of the down triangle as an indicator and as an icon are different.
Wed, Mar 15
Tue, Mar 14
but there might be use cases like colorizing the clear indicator of a CapsuleMultiselectWidget on :hover
Mon, Mar 13
Adding the usage that I could find with details that seemed relevant. Feel free to update and correct.
Sun, Mar 12
Sat, Mar 11
Fri, Mar 10
While OO.ui.DropdownInputWidget would benefit from having support for optgroup, I don't think this particular page needs it. My understanding here is limited, but I feel that the Common delete reasons heading is unnecessary and the functionality of the dropdown would be obvious to the user even without it.
I am happy with @Pginer-WMF's design (similar to FF on Windows). Only on Chrome and Safari on OS X does the heading look disabled, on all other screenshots its bold (correctly so).
Thu, Mar 9
I know that we've already done this once (T154703), but should we wait for a more canonical URL of the styleguide, rather than redirecting to github.io?
There could be two solutions to this, one is to open the calendar widget as soon as the widget gets focus, and the other is to just highlight it and wait for user input (<enter> key) before opening the calendar.
While I understand what you're trying to say, doing this would be equivalent to saying "Insert username" and "Insert password" on Special:UserLogin. This would be incorrect usage of the label.
Thanks for such a detailed bug report @Pastakhov!
While trying to resolve this I noticed that removing items programmatically using removeItems or removeItemsFromData does not call updateInputSize. This works when using the UI because of the mousedown event handler on this.$handle.
@Matanya I am not sure what this means. Could you please add a screenshot, or a link where this is happening?
Not sure if it satisfies all needs, but could consider documentationjs (supports jsdoc) as an alternative too.
Tue, Mar 7
Sun, Mar 5
Tue, Feb 28
With T115860: Show image thumbnail in both steps of mw.ForeignStructuredUpload.BookletLayout resolved, should we remove the Use this image step?
@Pginer-WMF, could you also take a look at this from the perpective of mw.widgets.CategorySelector. Its requirements are listed on T147811: Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget, and specifically in my comment.
I was fiddling with this and made the following changes:
- Reduce the amount of width taken by the labels
- Align the description and the input
- Reduce description text's font size
- Change description text's color to a readable gray - Base30 (#72777d)
Maybe it was just my interpretation of the gif. I thought that clicking on the label made that part editable. But what I first identified as the text caret was probably a glitch of the border appearing. The text cursor and the label becoming surrounded by borders contributed to the confusion making it look like a text field.
I'd be ok for it if we have any indication of there being an issue with this, but I'm not sure there is.
The differentiation between indicators and icons on its own is already in parts confusing
Mon, Feb 27
Fri, Feb 24
Tue, Feb 21
Feb 20 2017
Feb 19 2017
Feb 18 2017
Feb 17 2017
Feb 16 2017
Screenshot of @Quiddity's changes:
Feb 13 2017
Is the screenshot is the description out of date? This is what I see now.
The edit or add and view states on Commons don't look very different in the gadget, or in the current design of the prototype. This might confuse users, especially when if they click Add annotation… from a Wikipedia article and are taken to the add interface on Commons. Instead of having just a small notice on top guiding users to add an annotation, making the entire page dark (or something) might be a good cue to the user that they are in a different state of that page. Here is a crude example:
Feb 12 2017
From the patch:
Feb 11 2017
So IndexLayout has a bunch of methods that use the word card (getCard, removeCard...). In the first step do we also want to add new methods like getTabPanel and issue a deprecation warning when the older method is used? Should we also update all documentation to point to these new methods? I think we should.
The IndexLayout is full of references too cards, card, CardLayout...
That patch only fixes the color in the source. After this gets merged, @siddharth11 could you run bundle exec middleman build once and submit a patch?
I don't think a lot of people reach that page via a search engine. I thought of this change as an aid to the user and not robots.
Feb 10 2017
Feb 9 2017
As far as I understand, the move itself is permanent, the location to which it has moved can change later.
Err, should it be redirecting to the OOUI demo page instead?
Added a .lighttpd.conf file to $HOME and setup a 301 for all pages-
Feb 2 2017
As far as I can tell the Apex theme doesn't generate any constructive (or any other, for that matter) variants for icons. So, clicking on Constructive on the demo doesn't show the user anything useful. @SamanthaNguyen has already started the discussion about the flag itself at T156874: The constructive flag in the OOUI Apex theme should be deprecated in favor of the progressive flag, in the meanwhile, I don't see the harm of removing the button.