ID Names are rewritten by Blocs to lower case

I am using some external JS code to fix the problem of videos still playing after the modal is closed. After about a half an hour trying to find out why the code wasn’t working I suddenly discovered that Blocs rewrites IDs to lower case … Why?

So “html5Video” becomes “html5video”


Maybe because that’s a convention?

While of that, course makes sense, this is only a suggestion. If I want to name an ID “MyVideo_23” I should be able to - even if it is not an example of “good naming”. After all it’s my code and my software should allow me to use “bad naming” if I choose to do so. As a matter of fact, I don’t know of another software such as Dreamweaver, Pinegrow etc. that rewrites my IDs.

Let me start by saying that I believe if the convention is only for you(the developer), then it’s not much of a convention at all… it’s more of a habit. :wink:

A few points

  1. The specs are different from HTML 4 to HTML 5.
  2. HTML 5 supports everything classes support
  3. BUT that’s all about the browser support and doesn’t tell even half of the story! It’s not only about what browsers can do!

What to consider

Selectors are also there for scripts to manipulate the DOM with. Those scripts come in many languages and may support different conventions. Let’s say I want to integrate tools like tag management systems or create themes for a particular CMS. Conventions can really matter in these cases. I suspect this is the exact scenario Blocs is in. It needs to copy and manipulate those classes and uniformity really helps with that.


In the case of other software, Blocs is unique. and comparing to the other software isn’t really fair comparison. The biggest deal with Blocs is the way it works, not just what you can build. That’s a pretty small trade off for this kind of simplicity and accessibility.

Choose wisely

When you’re trying to get some script to work, an obscure naming convention that’s not working will be difficult to track. and fixing it means changing your markup. That’s not always practical or possible.


Thanks for the link :grin:

I remember being stuck with something not working for ages, until I discovered it was because I had used a ‘_’ in the ID name :rofl::rofl:

Exactly! :grin:

1 Like

Thank you for your Feedback, Whittfield, I agree with all of that!

Actually though, the point I was trying to make was that Blocs changes my code without warning me. I just don’t like it when a software does that without at least telling me. I spent over an hour trying to find out why my script didn’t work, untilI noticed that my ID names got changed.

And while I do agree that comparing Blocs to other software may be unfair, I do think it’s a valid statement to say that things like changing code or the names of things the user names, should at the very least be something the software should tell me about when I do it - especially in light of the fact that Blocs is aimed at people like me who don’t really code that much. (a coder would never name his IDs in a non-conform way ?)

Besides that, Blocs doesn’t show the changed ID name in the ID field even after it has been changed. See screenshot:

If Blocs wants to force me to conform to naming standards, that’s OK, just let me know …

For example: I try to enter an invalid ID name: The background of the ID field in Blocs changes color (light red?) … like this:

Hi @gary,

I wasn’t aware of this behavior, this is a very valid point and I agree with you!

But I wonder what’s the best way to handle this? I think alerts will be too obtrusive and get annoying. Anyway, good that it’s being discussed now.

Thanks :grin:

I don’t see this as a major issue in the normal scheme of things. There are many reasons why someone may wish to use different naming conventions in the design environment. I like to use a descriptive ID names when putting a site together. For example, I may use names such as Main Product Specification or Product Features. On a large site it often makes things a little easier. I can do this in Blocs because I know that the application is going to output code in conventional format. Furthermore, if I’m targeting specific ID’s within the design environment, I can see that the ID’s have been changed to reflect convention, either in the layer tree or when selecting a target in the interactions settings.

Clearly, if I was writing scripts that target specific ID’s, I would have to ensure that I stick to standard conventions to be assured that web servers will act properly. Therefore, under such circumstances I would probably use conventional format ID’s even in the design environment. Certainly I wouldn’t assume that because I’ve used an unconventional format in the design environment that an external script is going to be able to use those ID’s. For me its a convenience to be able to use non conventional ID’s - safe in the knowledge that Blocs will make it all work - that’s why I like Blocs.

If it is a major concern for you, maybe you should simply use conventional naming from the word go. That way, there will be nothing for Blocs to correct. You clearly have to use conventional naming when writing your scripts, so It shouldn’t be too difficult to use those same conventions when laying out your Blocs site.

I like to use a descriptive ID names when putting a site together. For example, I may use names such as Main Product Specification or Product Features .

Now that would be cool too, only thing is: If I give an ID a name like BIG**wow, save the file close Blocs and reopen it, the Name in the ID field at the right has been changed to big-wow.

To be fair, Blocs manages the ID’s correctly so that things work. If it didn’t do this, there would be posts about “my modal is working”… or this and that isn’t working.

1 Like

Here yet another example of something I have to code by hand because Blocs changes ID names!

And I can’t even do it using custom attributes because “ID is a reserved attribute” …

BITTE: Norm please consider changing this. Leave ID names the way they are!