Improve support of CSS based border-width properties

[JoshMarler]

Our current border-width support is fairly basic and just strokes a rectangle around a view. It is difficult to add border lines and specific edges. i.e.:

---

Item 1

Item 2

We should implement an equivalent to CSS's border-width props: https://developer.mozilla.org/en-US/docs/Web/CSS/border-width

The implementation of this should follow suit with the like of ScrollView's properties where "meta-props" are split into their naive C++ equivalents. See ScrollView.ts and the unpacking of scollbar-color into scrollbar-thumb-color and scrollbar-track-color.

[JoshMarler]

Note for any that might consider picking this up. I am currently working on this change so please let me know if you've also started working on this.

[olidacombe]

@JoshMarler I've got my eye on a few things including this, but totally snowed under so no collision here ;)

[JoshMarler]

Heh! Cool cool. Good If I take this then? Just adding the following:

border-left-width border-right-width border-top-width border-bottom-width

border-left-color border-right-color border-top-color border-bottom-color

border-bottom-left-radius border-bottom-right-radius border-top-left-radius border-top-right-radius

border-width border-color border-radius

@olidacombe, I suspect you and I have very similar feature desires from what I have been seeing! Might be worth ensuring we both start adding cards to the project now that I think about it.

https://github.com/nick-thompson/blueprint/projects/1

@nick-thompson , maybe we should request that contributors open the relevant card on the board and mark in progress so that we avoid duplicate work and can track which issues are being actively worked on?

[olidacombe]

@JoshMarler yes please go for it! Using a bit of project management machinery seems like a very sensible idea to me. My immediate feature desires revolve around performance and developer quality-of-life (I think the latter especially will be key to adoption post beta). Some are ridiculously trivial and yet I think would make a big impact on say pure js devs being drafted in on a project.

[JoshMarler]

@olidacombe , Sounds awesome! Would be super interested to hear what you have in the pipeline particularly around performance as I've some work in mind to reduce garbage collection overheads etc. I'm working with blueprint on embedded targets so this of paramount concern to me. Unsure if you are on Discord but we have a blueprint channel/server going which Nick and I are usually active on daily. Might be worth coming over at some point so we can all sync up plans etc.

[olidacombe]

@JoshMarler sounds great, I haven't used it before and didn't manage to find the channel. My username is easy exceptionally easy to guess from my github handle if there's any kind of invite mechanism.

[JoshMarler]

@olidacombe, Try this: https://discord.gg/Ve7MYDSb

[nick-thompson]

Yea I'm definitely guilty of not applying the best project management here 😇

I'm not loving the way Github's project board syncs with the Issues list either, it has so far ended up feeling like a separate thing to manage to try to keep track of the work. I'm wondering if perhaps we can achieve better project management by focusing on, and improving the process around Github Issues?

Specifically:

• Document every feature request, bugfix, or change with an issue
• Issues that have been assigned to someone should be considered "in progress"
• Issues with no assignee are free to claim
• If you don't see an issue for some work you're planning, open one so that we can mark an assignee and avoid duplication
• Priority can be established by way of effective labels
• Timelines can be established by way of effective milestones

What do you think? Then with that we close down the Github Project tracker here and use only the issues?

[JoshMarler]

@nick-thompson , Yeah I like this. Succinct and easy to follow. Think this is probably worth adding as points in the README Contributors section.