As mentioned in the github issue #70 including mixins aren't supported.
Are there any good workarounds or alternative solutions?
Pyjade's implementation of include doesn't support mixins, but "extends" does, although you have to use a "block". So what you could do if you just need to import one file:
extends mixins.jade
block layout
+link("example", "http://example.com/")
mixins.jade:
mixin link(text, url)
a(href=url)= text
block layout
(Answering my own question, because I searched hard before figuring this out myself and thought it could be helpful to others)
Related
Is there any harm if custom tags are used and created based on one's choice?
like the one below
<hello>hi there!</hello>
I tried using CSS
hello{
color:red;font-family:arial;
}
The above code works
I have used the above and also can add CSS. is there any harm of doing this, or the CSS features these won't support?
This is purely out of curiosity so don't suggest CSS edits or solutions please.
Why you can't make up elements
It is not valid HTML. Therefore how it behaves will be unpredictable.
It may work in some browsers, currently, but if any of your users visit your site on a different browser, they may get a totally different experience. Further to that, support could be dropped, or change at any time without warning.
Other options for custom elements
It is actually possible to define your own Document Type Definition (DTD), however that too is not a good idea.
Your best bet is to either stick with normal, well-supported HTML elements (see here for list of valid elements), or to use a web component framework, such as Vue, Angular or React, for custom elements/ components.
Don't forget, that you can add the class attribute (as well as others) to any element for styling, so for your use-case, there isn't any need to have additional elements.
I am hoping that there is some kind of CSS/styling framework that works with strictly semantic markup and leads to relatively small files. The way I see things now, this is another example of the "three options, pick two" iron triangle.
Here's what I mean. I'm looking for:
Some sort of visual styling framework (so I don't have to write everything by hand)
...that works with simple, semantic HTML without any class name pollution just for the sake of visual styling. This is my dumb, stubborn opinion, but I feel markup should always be sparse, simple and semantic. Stuff like this:
<div class="widget">
...and not this:
<div class="widget d-flex p-2 bd-highlight">
...which leads to relatively small file size(s). On their own, frameworks are actually pretty lean. But to stay light-weight, they require declarative markup. Pre-processors, like Sass, allow you to inherit rulesets directly from frameworks really, really easily. So you can do this:
.widget {
#extend .d-flex;
#extend .p-2;
#extend .bd-highlight;
}
But it leads really quickly to absolutely colossal file sizes. The rulesets remain tiny, but the selector lists explodes. I would categorically reject this solution just because of this file-size issue.
My gut tells me my options are either to continue writing CSS by hand (dropping #1) or to start declaring styles in my html (dropping #2).
Does anyone know a way out of this? Am I misusing Sass? Is there another type of framework I don't know about? I'm working with Sass and React, but I'm willing to learn from anything out there.
After digging around quite a bit on this issue, I think that currently there is no sensible way to use a CSS framework with semantic markup without incurring major penalties. I've opted to go with custom CSS for the final build. Some general notes:
Certain frameworks (notably Bootstrap) expose some styling via mixins (#include framework-mixin()). This leads to duplication of rulesets (and thus some bloat), but it is much lighter than what happens when you use #extend for inheritance. However, many core classes are just exposed as regular classes. This means you still face a question of semantic markup or massive file bloat.
It seems most modern frameworks organize their codebase into inheritable chunks. If you are extremely careful to #extend only the exact classes you need, you can end up with (arguably) acceptable file sizes for the final HTML. Rather than including an entire framework css file, consider including only the component files you need. I still found that even these files could grow too huge very easily, but if you are careful, it may work.
What is the most common or accepted way to prioritize between clean html code and clean css code?
As I see it there are two possible approaches…
Either you can go for a html code with minimal markups related to styling. The downside is that the css tend to be a bit messy and perhaps a bit redundant when you for example add similar styling to different objects (which in this approach lacks suitable classes).
The other approach results in a cleaner css code where you have predefined classes for different stylings, think w3.css or bootstrap. This time the downside is that you may end up with a html code that heavily relies on the class attribute of the tags, sometimes the combination of several classes; meaning that the html markup isn’t really separated from the styling.
I realize that there is no definite answer and that the line between the two options are floating. But what is the preferred approach, given that you are not using any precompiled framework?
Edit:
The question is not about inline css. It is about how to think regarding the use of predefined css classes. For example… if you add a class similar to “w3-panel” to some divs then you effectively add some margin in the html code. If you instead target those divs specifically by using selectors you keep the html free of styling.
The former produces cleaner css code and the latter produces cleaner html code. Which route is the most accepted one when not implementing a framework (forcing you to style by adding classes to the html)?
The advantage of the separation is to make it easier to maintain and if you find a css too messy, take a look for SASS or SCSS. And if you are using jQuery to manipulate your CSS, it is easier if you have your definitions in a CSS file. Imho the worst choice you can make is to mix it up - some definitions in CSS and other in the HTML - you may find it useful now, but try to change the site in a few months.
It really depends on your business of application.
If you put styles in same file in html file size would be increasing and it would be getting messy when you added new css each type, but as your css and html are in same file and css is well written and used, page load time would be minimum as html find css in same file.
If you put styles in separate css file, it would be well readable and accessible, you would have separate layer for styles and markup. But each your page load, your included css file would also be load in addition hence increase page load time.
If your application or html page is one time i.e no much furthur additions in future and will be remain same mostly then no need for separe css file.
If your application would be growing or html page being updating quite often, then you should be separate css files.
Personally, I think it is best from the beginning to split the code as much as possible. (HTML for markup, CSS for styling, etc).
Pro(+)
It is easier to troubleshoot
You can scale and later on introduce support tools such as SASS for CSS, etc.
A task can be splitted between persons.
Easier for another programmer to understand the setup of files.
Neg(-)
Take a bit energy to be disciplined and really keep coded splitted.
You sometimes would need a larger monitor to have the splitted codes in parallel view.
Here's a live example
I am attempting to create modules whose markup and CSS never change (e.g. I can use the same module in an utilities, footer, header, etc. section), but I still want the freedom to increase/decrease the size of the module.
Ideally, my CSS would be something like this:
article {
base styles
}
article.sample1 {
custom styles
}
article.sample2 {
custom styles
}
I'm able to adjust the size of the article.login module with this code:
section.utilities > article
or
section.test > article
Article Element (or alternative). I'm using the article element. Is there a better one? I poked around a little on the inter-tubes looking for custom elements (A List Apart, The Worm Hole, and Ajaxian). Should I stick with article, use a different one, or make a custom one?
IE. I haven't been able to test this in IE. I think I have my bases covered with inline-block and background-size, but I'm not sure about child selectors. Do you see any problems supporting this code?
Lastly, is this approach a Bad Idea™? Ultimately, this would allow me to build modules/objects in PHP files which, I'm hoping, will result in rapid development and easy code management.
Update
I wanted to create a custom element (module), but found that to be impractical. The combination of the data attribute and CSS attribute selectors, provide me the tools treat these like custom elements.
<article data-module="helloWorld" />
All modules can be referenced by
article[data-module] { ... }
My .02:
Historically, defining custom elements has always been frowned upon, and, semantically speaking, one should choose one that is closest to their intended goal. This gave way to prodigious use of divs and spans. My personal opion is that the introduction of the article tag is a compromise allowing for highly customizable elements without actually walking out of the HTML box and into the XML one. From the W3C Specification:
The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. W3C Specification
In conclusion - the article is a good choice for this.
It's IE. Expect to spend lots of time writing extremely indirect and possibly totally irrelevant code making use of newer ideas in IE. Most old ideas don't work in IE.
I think this is a good idea. Be careful about your nuimber of modules though as, depending on your server configuration, using php wrappers to house the modules could involve lots of file reading and seek times.
Hope this helps.
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?