-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Phantom border #412
Phantom border #412
Conversation
5c0e94b
to
793ecc8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rtfeldman there are some points which I need for you comment/opinion, could you pay little bit more attention for those please?
src/Css.elm
Outdated
-} | ||
wavy : Value { provides | wavy : Supported } | ||
wavy = | ||
Value "wavy" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed wavy
value, because it's related with text-decoration-style
which hasn't implemented yet and I thought it can confuse a contributor who will implement it. Should we keep changes or come wavy
back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to leave it. It already happens that implementors run into things that have already been implemented (e.g. left
is reused in several places), so I think this should be fine!
|
||
## Border Color | ||
|
||
@docs borderColor, borderColor2, borderColor3, borderColor4, borderTopColor, borderRightColor, borderBottomColor, borderLeftColor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm little bit worry about the docs structure but this kind of approach the most logical and clear by my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This grouping seems fine to me! 👍
src/Css.elm
Outdated
type Supported | ||
= Supported | ||
type alias Supported = | ||
Never |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Little proposition for making phantom types more phantom :) Like never before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually there are more variants:
- If we don't want that user will describe phantom types of
Value
with bothNever
andSupported
type Supported = Supported Never
- We may not use any special type, just empty tuple. Error messages keep same.
dotted : Value { provides | dotted : () } dotted = Value "dotted"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nice feature of having Supported
be a union type that doesn't expose its constructor is that other modules can't instantiate it. This limits how other modules can use it, which in this case is desirable!
On the other hand, Never
and ()
can be instantiated outside this module (by using Basics.never
and ()
, respectively), which means we're potentially giving up guarantees around how these values can be constructed, without necessarily knowing what those guarantees are are or why we're giving them up. 😅
To make a long story short, I definitely want to leave this as-is! 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway we will never expose constructor of Value
. It means that nobody can reproduce something like that Value "transparent"
event we expose Supported(..)
e49d185
to
1f9b26a
Compare
@rtfeldman issues have been completed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thank you so much @owanturist!!! 😍
|
||
borderStyle ridge | ||
|
||
Similar to `groove`, but reverses the color values in a way that makes the element appear raised. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the concise descriptions on these! 😻
Hi @rtfeldman! I'm glad to show
border
properties as a part of #392 here. Please take a look.Checklist
Value
is an open record with a single field. The field's name is the value's name, and its type isSupported
. For examplefoo : Value { provides | foo : Supported }
Style
accepts a closed record ofSupported
fields, which always includesinherit
,initial
, andunset
because all CSS properties support those three values! For example,borderFoo : Value { foo : Supported, bar : Supported, inherit : Supported, initial : Supported, unset : Supported } -> Style
phantom-types
branch, notmaster
!