How to remove a css link from the html header.

How can I remove a css link form my html head that is not used by that html file. The only way I can see is to right click the html file in the design pane and goto properties. From the dialog I can then type a new head text but it doesn't show the existing head so I need to retype everything from scratch. Also since you can't copy/paste more than a single line of html that won't work either. Certainly there must be a better way that I am missing.

You can't at this time. Hopefully we will get this possibility in the near future as it's been asked for numerous times. For now you just have to do one of 2 things.

  1. Live with it.
  2. Create an export script to do it for you on export.

You'll need to get assistance for the export script elsewhere, I don't have any knowledge of how to use that feature of BSS.

Just checking if this issue was ever addressed since then.

Yes you can now uncheck CSS and JS files that you don't want included in a page. :)

I see. That's great news. Thank you.

On a related note, is it also possible to completely skip <head> section for a particular page?

no, why would you even want to do that? a web page "needs" the head section to know how to display the site.

Part of a larger problem. This will get somewhat lengthy, but hopefully someone from the BSS team could make something out of it. Here we go:

I'm writing my front-end stuff using Laravel Blade templates (HTML on steroids). Blade uses a concept called template inheritance in which we define a master/base HTML that defines the structure of our website (navigation menu, left/right panes, footer etc.) and several content HTML files, which provide the actual stuff of that page. This saves us from writing the same HTML over and over in every page and also makes it very easy to make structural changes.

Blade provides two server-side tags named @section and @yield that define where a particular piece of content page will be placed in the master page. Works like this:

Master page

<html>
    <head>
        <title>App Name - @yield('title')</title>
    </head>
    <body>
        @section('sidebar')
            This is the master sidebar.
        @show

        <div class="container">
            @yield('content')
        </div>
    </body>
</html>

Content page

@extends('layouts.app')

@section('title', 'Page Title')

@section('sidebar')
    @parent

    <p>This is appended to the master sidebar.</p>
@endsection

@section('content')
    <p>This is my body content.</p>
@endsection

OK. Enough background. So I'm using BSS to design my front-end. Whenever I want to make a change, I just go to BSS, make changes, export the stuff and just replace existing files in my actual front-end. It generally works since Blade is mostly HTML, but there are a few key problems that make the job a bit more tedious than it should be: * Firstly, those server-side tags are not supported in BSS. I'm currently working around it by using Custom Code elements. This approach works correctly, although not as clean as built-in elements (e.g. have to keep track of starting/ending tags etc.) * Output files have html extension. I'm using a PowerShell script to bulk-rename them to .blade.php. BSS allows running post-export scripts, so this step can be managed elegantly. * The fact that BSS treats all pages as standard HTML pages and creates <html>, <head> and <body> tags. There is no concept of component pages (so to speak) in BSS, which could just store sections of HTML instead of full HTML pages. There is no simple workaround for it. I have to manually remove this stuff every time from my content pages after export. This also answers your question as to why I want to remove <head> section.

Now I understand that that BSS was probably not supposed to be used like this, but the fact is that most of the web applications that use one of those popular frameworks (Laravel, React, Vue, Angular) need some sort of post-export manipulation to shape the raw HTML correctly.

The Export Script feature provided by BSS is one step in the right direction, but falls short of providing true element level control. My suggestion is to allow users to write small Javascript functions that BSS would call at more granular levels. For example, BSS could invoke callback functions:

  • Export_started
  • Page_started (ref output_file_name)
  • Element_generated(ref string content)
  • Page_saved(string path)
  • Export_completed

Those ref parameters (sorry, couldn't resist my C#, LOL) indicate that the called script should be able to modify the incoming value and BSS would then use that modified value in the export.

All this will still be an optional/advanced usage, leaving the standard use of BSS intact, thereby not affecting existing users and their work.

Hopefully the BSS team would do some brainstorming about it and make something concrete from it. This will take BSS to new heights and make it easily integrate into the regular development cycle of professionals, where front-end design keeps evolving over the life of the project and people need to go back to BSS, make changes and then bring them back into their actual server-side/client-side code. Using this approach, they'll not have to hand-edit the output every time.

Well over my head there sorry lol. I would suggest you put something in the Ideas section, if you haven't already, and reference this thread. I don't guarantee anything since this app is so far designed for setting up your base website pages, but can't hurt to ask.

Use Beautiful Soup which is a html parser. You can run it on the exported html files and remove, change, add anything you want....all with a python script.

@Jo: Thanks. Yep I thought I was going too far for a forum post. Thanks, I'll try to create an idea.

@Twinstream: Thanks for the info. Yes, that and many more things could be done. I could probably write some PowerShell script and call it from BSS Export setting. I even recall that I wrote a small console application in C# at one stage, to specifically modify some of the HTML generated by BSS. While that's OK, it isn't generic enough. With the suggestion I provided, BSS will become part of the full development cycle. People would be able to come back to BSS, make some changes, spit out new HTML directly into their project folders.

I'll try to post an idea for the team to check if it's worth the effort. From technical point of view, it shouldn't be hard at all to implement. Depending upon how they have designed BSS code base, it shouldn't be more than a few hours of work. Worth the reward I'd say.