Skip to content

CSS Option Treats Everything As CSS #93

@tajmone

Description

@tajmone

Not really a bug in PMLC itself, but a potential cause of bugs in the generated HTML files.

When invoking PMLC 3.1.0 with command PML_to_HTML and option --CSS_files followed by a directory, PMLC then treats any file within that directory as if it was a CSS file, regardless of its extension (or lack thereof), so in the generated HTML file you have something like this:

<meta name="generator" content="PML 3.1.0 (www.pml-lang.dev)" />
<title>Style Sheet Demo Document</title>
<link rel="stylesheet" href="css/demo.html">
<link rel="stylesheet" href="css/extended.html">
<link rel="stylesheet" href="css/pml-default.css">
<link rel="stylesheet" href="css/pml-default.css.map">
<link rel="stylesheet" href="css/pml-default.scss">
<link rel="stylesheet" href="css/pml-print-default.css" media="print">
<link rel="stylesheet" href="css/pml-print-default.css.map" media="print">
<link rel="stylesheet" href="css/pml-print-default.scss" media="print">

This is extremely inconvenient for any developer, since it forces them to specify CSS files individually, whereas it would be convenient to just pass a folder path and expect PMLC to selectively include only files with the .css extensions.

Having a folder with CSS files only is counter intuitive for a developer, since Sass files, along with generated CSS maps for debugging stylesheets are usually kept in the same directory. So, the idea of having a "pure CSS folder" is rather naive, and in any case there's always the risk of end users forgetting some file behind, or temporary and system files (often hidden from the end user) in that folder ending up in the generated HTML being linked as a stylesheet.

In other words, it makes sense that PMLC should natively filter directory contents by the .css extension, and accept any individually specified file as is, regardless of its extension. This is IMO a sensible default, since it applies reasonable file-extension conventions for folder contents filtering, without preventing custom extensions being explicitly used for individual files.

Right now, passing a folder path doesn't seem neither practical nor safe, for it only makes sense if the folder contains CSS files only — which is rarely the case, and hard to guarantee since temporary files (including hidden files) can easily end up there, especially since browsers tend to create temporary files next to the CSS stylesheets when accessing the advanced developer tools (e.g. Chrome).

Blindly linking to any files in the CSS target folder could even potentially result in accidentally revealing personal data, or divulging source files (e.g. if the toolchain tracks the linked stylesheets to post-process them, etc.).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions