-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
f78f246
to
1d59578
Compare
src/TipBox.vue
Outdated
border-radius: 6px 6px 0 0; | ||
} | ||
|
||
.content-wrapper { |
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.
While this is a class, in MarkBind, we also use this name as an ID to wrap the entire webpage. To avoid confusion, use tipbox-body
instead?
src/TipBox.vue
Outdated
@@ -50,12 +65,15 @@ | |||
type: String, | |||
default: '' | |||
}, | |||
heading: { | |||
header: { |
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.
Potential breaking change (some people might have already started using the new heading
feature, which means their site will break immediately). My suggestion is we support both first while deprecating heading
.
src/TipBox.vue
Outdated
div.box-heading > * { | ||
margin-bottom: 0; | ||
} | ||
</style> |
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.
Newline
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.
Also just curious, is there a reason why we are using a separate <style>
section?
Thanks for looking through it! Will update the relavant sections The separate Is this a good solution to theme specific styles as well?
An alternative is to hardcode another layer of stylesheets based on which is currently in use, which can make it clearer which styles were changed / added from bootswatch styles, but it may add some unnecessary complexity to the code |
Ok let's do it in a subsequent PR then. We strife for simplicity for now. |
1d59578
to
b5132ef
Compare
b7b1032
to
ee33884
Compare
ee33884
to
579de6b
Compare
Updated styles as discussed MarkBind/markbind#999 Added a thin horizontal divider when used with |
579de6b
to
f61a637
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.
The code itself looks fine to me 🙂 I tried to use your template to build a site to test the feature, but the table looks broken on my end:
This is with the vue-strap.min.js
build from this PR, and MarkBind checked out from the branch in MarkBind/markbind#1025.
Do you mind testing out the template again to see if the error is reproducible on your environment?
@@ -80,10 +85,16 @@ | |||
return this.type === 'none' | |||
}, | |||
isSeamless() { | |||
return toBoolean(this.seamless); | |||
return !this.light && this.seamless; |
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.
Just wondering if we should fail hard or emit an error message if both light
and seamless
is present. It feels like it might make debugging easier for the user when trying to figure out why the output might not be what he is expecting.
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.
Just wondering if we should fail hard or emit an error message if both
light
andseamless
is present. It feels like it might make debugging easier for the user when trying to figure out why the output might not be what he is expecting.
I think emitting an error message is a good idea, we could that in the new componentParser
in MarkBind easily
We could do this in a seperate PR with warnings for deprecated attributes in one go as well, something like "Add warning messasges for inconsistent component attributes"
perhaps
I don't mind updating MarkBind/markbind#1025 for the light vs seamless thing alone first though, let me know which would be better 😄
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.
If it's not a lot of effort, it would be great to add that in before we merge that in 🙂
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 would be better that we write a common utility to check for this. Since both #129 and this have the possibility of inconsistent attributes. I can either include it in my PR, although I'm more inclined that it'd be in a seperate PR altogether.
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.
Adding a common utility in a common PR after both these PRs are merged and applying it to all the new changes at once sounds good to me. Let's open an issue to track this.
Perhaps we can leave some // TODO
s to indicate where these checks should happen to make it easier for the person working on this issue.
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.
Perhaps we can leave some
// TODO
s to indicate where these checks should happen to make it easier for the person working on this issue.
Updated MarkBind/markbind#1025 with it
Thanks for looking through this! I just tried it again on MarkBind/markbind#1025 as well, it appears as is in the gif. |
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.
So it turned out that VSCode was doing some autoformatting that messed up my files 🙃It looks pretty good to me, just a few more questions.
@@ -80,10 +85,16 @@ | |||
return this.type === 'none' | |||
}, | |||
isSeamless() { | |||
return toBoolean(this.seamless); | |||
return !this.light && this.seamless; |
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.
If it's not a lot of effort, it would be great to add that in before we merge that in 🙂
src/TipBox.vue
Outdated
headerContent() { | ||
return this.header || this.heading; | ||
headerBool() { | ||
return this.$slots._header; |
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.$slots._header
seems to be an object. headerBool
feels like a misnomer here. I think we should either keep it as headerContent
, or make it return a boolean.
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.
Also, we seem to have two different naming conventions for this component: isXXX
vs xxxBool
. Should we stick to one of them?
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.
Also, we seem to have two different naming conventions for this component:
isXXX
vsxxxBool
. Should we stick to one of them?
Hmm, I followed the convention in panelBase.js
for this, as its a little strange to call it isHeader
. I could change it to hasHeader
if preferred though!
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.
If it's not a lot of effort, it would be great to add that in before we merge that in 🙂
I can't comment in the above comment for this strangely 😕
I removed toBoolean
as our docs dosen't show using light/seamless="false"
, and
this.light
is also used directly for lightStyle
( light="false"
= truthy )
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.$slots._header
seems to be an object.headerBool
feels like a misnomer here. I think we should either keep it asheaderContent
, or make it return a boolean.
fixed 👍
case 'success': | ||
case 'tip': | ||
return 'border-sucess text-success alert-border-left'; | ||
return 'border-success text-success alert-border-left'; |
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.
Good catch 👀
f61a637
to
dc90a15
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.
LGTM :)
Box headings are anchored to the top right corner of the box. Such a heading style causes the box content to overflow at times. Using the new seamless option with the light option causes unintended output as well. Let’s enhance the box component heading style, using a separate top horizontal section instead, fixing the content overflow. In addition, let’s support markdown parsing for the header, which pairs Nicely with the new support for various icon sizes. Lastly, let’s give the light option priority over the seamless option if both options are mistakenly used.
dc90a15
to
154a1e3
Compare
Rebased on latest, no changes |
What is the purpose of this pull request? (put "X" next to an item, remove the rest)
• [x] Enhancement to an existing feature
Fixes MarkBind/markbind#962
Requires MarkBind/markbind#1025
What is the rationale for this request?
What changes did you make? (Give an overview)
Change box headings to use slots for markdown parsing added in Implement box markdown header attributes parsing markbind#1025
Fix display issue with seamless and light boxes being used together
Provide some example code that this change will affect:
Template of the header wrapper
Testing instructions:
Proposed commit message: (wrap lines at 72 characters)
Enhance box component heading
Box headings are anchored to the top right corner of the box.
Such a heading style causes the box content to overflow at times.
Using the new seamless option with the light option causes unintended
output as well.
Let’s enhance the box component heading style, using a separate top
horizontal section instead, fixing the content overflow.
In addition, let’s support markdown parsing for the header, which pairs
Nicely with the new support for various icon sizes.
Lastly, let’s give the light option priority over the seamless option if
both options are mistakenly used.