ID's and Classes in Construction

Jeremy, a few days ago suggested. I could open up a new thread around to discuss classes and ID and the problems associated with using just ID’s instead of ID’s and Class as the construction attribute in a little more detail and why this would be useful. so without further ado here goes

So to recap for people who are unsure and this is just, so people can see some of the benefits and issues Please note: these aren’t all the benefits and problems for each attribute type, but it does give a quick basic overview.

ID’s are unique- Each element on your page can have only one ID

  • Each page can have only one element with that ID
  • ID’s can be used in URLs

The advantage for Xway is it can create a style structure that’s based on ID’s, and because it is probably the most important attribute for an HTML item, it can be reasonably sure it’s going to work correctly because each item on the page has a different ID hook… COOL easy peasy.

So what’s the problem with just using ID’s… so to explain that we need to know what classes are good for.

Classes are NOT unique- You can use the same class on multiple elements.

  • You can use multiple classes on the same element.

One advantage is if you have multiple divs as inline items within your page and all that’s different is the text within that box, then the construction styles are the same. Technically you could have a 1000 inline boxes all of them with different text but one overall style rather than 1000 styles.

In reality, this doesn’t really happen in the real world, but the main point is it has the potential to reduce the number of what I will call the construction styles.

The other issue is when it comes to a content management system, which duplicates blocks. For example, a div with a chunk of editable text in it a CMS could potentially repeat that block, and if page construction were to rely purely on ID’s, then the HTML would become invalid. (As mentioned in the ID’s section above: you can have only one id of that specific name on the page.

So here comes the crunch to make things a lot easier Xway just like its predecessor Freeway used ID’s as the main attribute for its construction. But going forward that’s going to cause issues (just like it did for Freeway) when it comes to introducing a content management system.

What some of us in the past have done is written actions that basically swop the ID for a class of the same name, and in some actions, we have introduced the capacity to drop the ID completely, add other classes, rename the id etc. The issues I think all of us that have undertaken that task this is that ist BLOOMING complicated to get to work flawlessly. It really is like trying to catch the proverbial horse after it’s bolted out of the gate. Not only does the action have to change the HTML pages naming items convention, but it needs to write to the styles in the head or in an external style sheet and or in a master page, and or within breakpoints. Honestly, it took us months last time along with a colleague of mine to get that action to work and even then there were certain elements it didn’t work on.

Personally, I would prefer to have the ability to choose if something uses classes as its main attribute, no class or id at all or have a class name of my choosing, via the main programs interface. At least that way we aren’t trying to undo a big portion of the program’s output construction, via an action after its all published.

Anyway, it would be nice to have some feedback from some of the others and their thoughts.

All the best Max

Thanks for the writeup Max.

From a development point of view I can see the attraction of IDs over classes as you should only have to keep keep track of a single item per page with that ID. Multiple items with the same class names, I suspect, are harder to deal with, not only from a tracking perspective but also from a workflow one as well. If you have a host of items that all share the same class, for example, and the user does something to adjust one of those items does the application;
a. create a new style based on the previous class (style1b, style1c etc) or
b. warn the user that they can’t do that and if they want a different border, padding, font style etc they need to create a new style or
c. keep the original style and create a new style for the unique changes (with or without the application sighing disappointedly)

One thing that occurred to me over the weekend while I was contemplating all of this was the Name/ID field in the Inspector. At the moment I think I’m correct in saying that the application assumes the item will have an ID. What if this allowed us to change the item to a class either directly or indirectly? What I was thinking was something along the lines of;
a. create an item and call it ‘item1’
b. create a new item and also call it ‘item1’

The application would then pop a dialog saying;
Hey! Item1 already exists. Would you like this item to share the same style information as ‘Item1’
No Yes
If you click yes then the two items will share the same class name and will use the same identical style. If you click No then you’ll create a unique ID or class for this item.

I think classes are SOOO much more useful than IDs and tend to steer towards ‘utility classes’ (‘.red’ to make something red, ‘.btn’ to make a link a button, ‘.red .btn’ to make a red button!) but I suspect there are a LOT of former FW users who really don’t care what happens under the hood as long as their web site works and makes them look good in front of their boss.

One thing that occurred to me over the weekend while I was contemplating all of this was the Name/ID field in the Inspector. At the moment I think I’m correct in saying that the application assumes the item will have an ID.

Not always - markup items don’t have an ID, for example.

(It’s just markup, and Xway doesn’t wrap it in anything that an ID could be assigned to.)

But generally, yes.

Jeremy

I think that one way you could work this principle into Xway is to consider the notion of “master objects”. Illustrator calls them Symbols, I think. Sketch has another word for them. But the idea is: you draw an item, modify it to your desired look and feel, and then designate it as a master item that can be duplicated over and over. If you go back to the original instance and make some adjustments, they propagate across all of the derived instances.

So that’s the interface for this, from the WYSIWYG side. At an HTML/CSS implementation level, I would happily code that using classnames, and expose that “class style” as a set of attributes that could be modified in one place. If you wanted to add another of these styled items to a page, I could see a palette similar to the Styles palette, with an ad-hoc list of named master elements. Drag a “sidebar1” onto the page, modify the content, and Bob’s your uncle.

Walter

On Nov 11, 2019, at 1:15 PM, Jeremy Hughes email@hidden wrote:

One thing that occurred to me over the weekend while I was contemplating all of this was the Name/ID field in the Inspector. At the moment I think I’m correct in saying that the application assumes the item will have an ID.

Not always - markup items don’t have an ID, for example.

(It’s just markup, and Xway doesn’t wrap it in anything that an ID could be assigned to.)

But generally, yes.

Jeremy

Affinity designer does this too - but you can edit any of the instances and the changes are repeated throughout all the instances in the file. There is a way to turn this off, so only the instance you are working on gets the change. Turn the instance syncing on, and all edited will cascade again, APART from those custom ones on the solo-edited item.

All the best,

Paul Dunning

web design - http://www.pauldunning.com

freeway actions - http://www.actionsworld.com

On 11 Nov 2019, at 22:32, Walter Lee Davis <email@hidden> wrote:

I think that one way you could work this principle into Xway is to consider the notion of “master objects”. Illustrator calls them Symbols, I think. Sketch has another word for them. But the idea is: you draw an item, modify it to your desired look and feel, and then designate it as a master item that can be duplicated over and over. If you go back to the original instance and make some adjustments, they propagate across all of the derived instances.

So that’s the interface for this, from the WYSIWYG side. At an HTML/CSS implementation level, I would happily code that using classnames, and expose that “class style” as a set of attributes that could be modified in one place. If you wanted to add another of these styled items to a page, I could see a palette similar to the Styles palette, with an ad-hoc list of named master elements. Drag a “sidebar1” onto the page, modify the content, and Bob’s your uncle.

Walter

On Nov 11, 2019, at 1:15 PM, Jeremy Hughes <email@hidden> wrote:

One thing that occurred to me over the weekend while I was contemplating all of this was the Name/ID field in the Inspector. At the moment I think I’m correct in saying that the application assumes the item will have an ID.

Not always - markup items don’t have an ID, for example.

(It’s just markup, and Xway doesn’t wrap it in anything that an ID could be assigned to.)

But generally, yes.

Jeremy