Scott Borrowman
Scott Borrowman
KPCKevin Powell - Community
Created by Scott Borrowman on 9/10/2024 in #front-end
Question about Vuejs and disabled links
I'm currently doing an ADA assessment on a project that is failing on their disabled links because the html rendered is <a disabled="disable"> instead of <a disabled> As far as I can tell, this is how Vuejs renders it because even if I change the <a v-bind:disabled="disabledValue"> to just hard code the <a disabled> Vuejs still seems to change it to <a disabled="disable"> Does anyone know if this is just how Vuejs handles its boolean attributes and if so is there a way around it? I've never used Vuejs before so I'm assuming I'm just missing something.
36 replies
KPCKevin Powell - Community
Created by Scott Borrowman on 8/12/2024 in #front-end
Question about web components
I'm working on a project that will require being able to add a bunch of different components to the page at any given time so the plan is to try to use web components. I'm having a debate with my coworker, however, on the best way to set them up and hoping anyone might know the pros or cons of one way compared to the other. My argument is that everything should be built inside a singular class constructor with all the logic built into it. So something like an accordion would look like this and the class would loop through each details tag to set up all the logic needed
<accordion-list>
<details>
<summary></summary>
<div></div>
</details>
<details>
<summary></summary>
<div></div>
</details>
</accordion-list>
<accordion-list>
<details>
<summary></summary>
<div></div>
</details>
<details>
<summary></summary>
<div></div>
</details>
</accordion-list>
My coworker thinks it should be broken up into multiple class constructors so each unique function is separated from the whole. Something like this so each part has it's own logic and then a "master" class on the accordion-list that pulls in all the other parts
<accordion-list>
<accordion-group>
<details>
<accordion-summary>
<summary></summary>
</accordion-summary>
<accordion-dropdown>
<div></div>
</accordion-dropdown>
</details>
</accordion-group>
<accordion-group>
<details>
<accordion-summary>
<summary></summary>
</accordion-summary>
<accordion-dropdown>
<div></div>
</accordion-dropdown>
</details>
</accordion-group>
</accordion-list>
<accordion-list>
<accordion-group>
<details>
<accordion-summary>
<summary></summary>
</accordion-summary>
<accordion-dropdown>
<div></div>
</accordion-dropdown>
</details>
</accordion-group>
<accordion-group>
<details>
<accordion-summary>
<summary></summary>
</accordion-summary>
<accordion-dropdown>
<div></div>
</accordion-dropdown>
</details>
</accordion-group>
</accordion-list>
The second way just seems like way too much bloat and a pain to make sure every thing can talk to each other. Does this come down to a personal preference thing or is there legitimate benefits for one way or the other?
4 replies
KPCKevin Powell - Community
Created by Scott Borrowman on 7/26/2024 in #front-end
Running into an issue while messing with the allow-discrete for animation feature
I'm need to build a collapsable alert message and thought I would try to mess with transition-behavior: allow-discrete; to switch the alert message to display none when it's collapsed. The issue I'm running into is going back from display none to display block. I want to delay that animation a few milliseconds but it seems like the delay is ignored for display. Does anyone know if delay doesn't work with allow-discrete? I've tried using @starting-style to set it's display to none but that seems to be preventing it from going back to display block. Here is an example of what I'm doing. It looks fine when it collapses but switching back to the default state causes the text to wrap before the animation ends because it is immediately switching back to display block instead of being delayed until the alert grows to full width. https://codepen.io/shborrowman/pen/YzopWXE
6 replies