User Details
- User Since
- Aug 5 2019, 7:51 PM (246 w, 2 d)
- Availability
- Available
- LDAP User
- Anne Tomasevich
- MediaWiki User
- ATomasevich (WMF) [ Global Accounts ]
Yesterday
Some notes:
- We'll need to add a design spec to this task
- If this task is implemented by someone outside the Design System Team, we can talk about splitting up the acceptance criteria to make the work more manageable. For example, a Codex volunteer could implement the functionality, but then someone from the Design System Team could add the new demos
Thu, Apr 18
Thanks for providing this updated design! I've responded below to the open questions in the task description.
This would represent a breaking change for some components. For example, if we change the Message component's dismissButtonLabel prop from required to having a default value of 'Dismiss', that prop can no longer be relied upon to enable the dismiss button. We would need to add a new boolean prop, useDismissButton, to do this. We probably should have done this from the beginning, but it seemed redundant at the time. IMO, this seems like a good case for Codex 2.0.0.
Wed, Apr 17
Mon, Apr 15
Thu, Mar 28
In our theme's publish.js, a helper function from JSDoc,getAncestorLinks()[1], is used to generate the link markup for the title elements. Note that publish.js's getAncestorLinks() returns helper.getAncestorLinks(), which returns an array of link markup for each title section.
I think option 2 is the most intuitive and grammatically correct, with the least gray area.
@CCiufo-WMF I think we should move this task to the backlog Up Next. This is a subset of the font-size decisions we need to make, and recent discussions have led us to pursue options for desired design behavior first, which can then be followed by deciding how to implement the behavior. Handling font-size tokens is part of that latter decision. We may want to find another way to represent the font-size discussion work on our sprint boards, but IMO this task is specific to one decision and can be backlogged for now. I'm hoping we can get back to it in a sprint or two, once we've made more headway on the design decisions.
Wed, Mar 27
Tue, Mar 26
See T361048 for the TablePager evaluation task
Mar 25 2024
@Sarai-WMDE I discussed table pagination with the DST engineers today and we came up with some more option questions, even beyond what you and I had discussed earlier. One big blocker may be the translatable label thing - this really does demand a solution like the one proposed in T345386, so that users don't have to pass in numerous translated strings that are the same across most projects. Because of this, and the general complexity here, we think pagination should be removed from the MVP scope and tackled as a separate feature post-MVP. I still strong believe that we should build the pagination UI for consistency's sake, and to prevent Codex users from having to replicate it across projects, but I think we should complete the rest of the Table component first, then tackle pagination as a new feature.
Mar 21 2024
@Sarai-WMDE please do combine them, thanks!
Mar 19 2024
I think option 2 is the "correct" way to do this. The 14px context is specific to Vector, so I think the demos of our components in a 14px context should just be displayed in Vector itself. I think this is important for 3 reasons:
- Philosophical reason: it keeps Codex, including the docs site, skin-agnostic. Having a font-size switcher on the docs site seems cluttered and confusing to me.
- Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.
Mar 18 2024
@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?
Mar 14 2024
Mar 13 2024
@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.
Mar 12 2024
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: