User Details
- User Since
- Aug 5 2019, 7:51 PM (241 w, 13 h)
- Availability
- Available
- LDAP User
- Anne Tomasevich
- MediaWiki User
- ATomasevich (WMF) [ Global Accounts ]
Yesterday
@Catrope I want to clarify what this task covers. I see 3 distinct things that could have descriptions and optional flags:
Is this just one icon, or do we actually need 3?
- Sortable, but unsorted (both arrows)
- Sorted ascending (just the up arrow)
- Sorted descending (just the down arrow)
Documentation for code splitting usage was done with T350792; see https://www.mediawiki.org/wiki/Codex#Requiring_Codex_components_in_MediaWiki_and_extensions and https://www.mediawiki.org/wiki/Codex#Requiring_Codex_component_styles
@Sarai-WMDE is there a use case for aligning the text in a cell to the center? Eric brought up a good point in my patch to introduce a way to align text to the end: perhaps we should include a prop called align that defaults to "start" but has option start, end, and center. Thoughts?
Thu, Mar 14
Wed, Mar 13
@Sarai-WMDE could you please confirm the sort icon functionality I listed in this task?
@Sarai-WMDE I implemented both of these things, but wanted to get your feedback on the results.
Tue, Mar 12
Feedback that would be helpful:
- What do you think of the proposed solutions?
- Are there other potential solutions?
- Does anything need to change on the Figma end, in addition to any changes we might make on the implementation end?
Thanks for this feedback, @Sarai-WMDE! I've implemented items 1-6. For the header min-height, I added a component-level token. There are 2 items I haven't addressed yet:
Mon, Mar 11
Fri, Mar 8
@Sarai-WMDE could you please check out these demos and let me know if you have any design feedback? Thanks!
Thu, Mar 7
FWIW, while the Codex Field component differentiates the label text and description text for fieldsets, they are both contained within the <legend> element - in my research, I found that this was the only reliable way to ensure that, when you tab into a fieldset, both the label and description are read to you. I still think this task needs to be done to allow you to pass in separate things for label, optional flag, and description, I just wanted to make this note about the resulting markup.
Mon, Mar 4
@CCiufo-WMF the latter; we've thrown around some ideas but are far from a solid long-term solution IMO
cc @CCiufo-WMF ^
This introduces a second hack into the Select component code related to supporting CSS custom properties - should we capture the work to create a more sustainable solution in the future somewhere?
Some of this work has been completed in the prototype, but I think a few things will take time:
IMO, creating and refining the tasks will take time, especially refining them to the point where they all have clear acceptance criteria, can be taken on by any developer, and any dependencies are clear.
I'm resolving this task since we've done the exploration and provided a path forward on all the open questions. Anything that is not completely clear yet can be discussed in subtasks of the Table component for each feature. Thanks to everyone who contributed to this work!
@DTorsani-WMF the guidelines you drafted look good to me!
We don't currently support the readonly attribute in the Field component, for 2 reasons:
- The Field component's parts (label, description, help text, message, etc) do not change at all when an input is readonly. There is nothing we needed to do inside the Field component to handle a readonly state.
- Only 2 components support the readonly attribute (TextInput and TextArea), so having a prop for the Field component for readonly could be confusing
Thu, Feb 29
Thanks for the report and the suggested solution, @Jack_who_built_the_house! I've opened a patch implementing this, and cleaning up some other existing solutions that were causing inconsistent behavior.
@Catrope that's a really good point - we will need to offer both options for pagination. I'll update the task description to note this.
I'd recommend including these guidelines in the new form guidelines in the style guide, plus on the TextInput and TextArea pages. readonly is not an attribute that's available for use in the Field component, and it only applies to two kinds of inputs, so I think it would be confusing to include it there.
@Sarai-WMDE after discussing the open issues with the team, I've listed answers for all of the open questions in the task description. I think sorting was the biggest question mark after our last meeting, and it does seem like we agree that we shouldn't implement support for sorting logic in the Table component as part of MVP. Please check out the resolutions listed in the task description and let me know if you have further comments!
Thanks @Catrope, this is super helpful. I agree that 1A makes sense for MVP and we could pursue 2B post-MVP if we want to. 2B does feel better than 2A because it keeps the dev experience consistent whether you're using sorting or not.
Wed, Feb 28
@Catrope do you have any experience with table sorting in MediaWiki? Curious if you have any thoughts on my last comment.
Supporting sort inside the Table component, in a way that would work across all languages, would be extraordinarily difficult. We should consider whether there is a reliable way to do this (like a library we could use) and how sort is handled in existing tables in the Wikiverse. Ultimately, we can do one of these options:
Tue, Feb 27
In the open questions I asked if pagination and sorting logic (i.e. determining which items to show and in what order) should be supported in Table, but I see now that they are totally separate issues. Pagination logic should be relatively easy to support in Table.
- Passing in table data
I've opened a proof-of-concept patch using background-blend-mode in the CSS icon mixin so we can play around with making it work for all icons
I've tried implementing this for all non-button icons and ran into a problem: the icon element must have a set background color. You can see this in action here, where I've set the background color of the second icon:
Wow, amazing solution—this works perfectly for the Select icon! I agree we should explore implementing this instead of mask-image for all CSS icons. My biggest questions are:
- Could this work with icons in buttons (I'm not sure how it would, since the color needs to change in the Button code when the state changes)? If not, are we okay with using different methods for icons inside and outside of buttons again?
- Can we easily handle night mode, e.g. with a token for the blending mode? Is that even necessary?
Mon, Feb 26
Fri, Feb 23
Early notes on data flow; more on this next week.
Thu, Feb 22
Sorry, this was a misunderstanding on my part