Dev Diary Ep8 - Q&A / Building a Grid Layout

Elements Dev Diary
1

Hey Weavers,

This week we start by answering some forum questions and follow up with copying a grid layout on the fly from a website selling expensive 3d lampshades! It’s a bit of a long one, but has lots of nuggets of information in it.

Just a heads-up: There’s a bug in the demo video where the selection sometimes doesn’t update when I choose it via the node tree, it kinda threw me while recording. It’s nothing major and we’re already fixing it, such is life with pre-release software :wink:

We love feedback!

Remember, we’re building Elements in the open so we can get feedback as we go. We want to make sure we’re building the product everybody here wants (including us). Share your ideas and feedback in the comments below.

Your feedback is invaluable; together we can build the best web design app on the Mac!

I’ll be back next Tuesday as usual.

Thanks,
Dan & Team Realmac

4 Likes
2

Thanks @dan for the update and answering our questions. It’s lovely to see how the app is evolving. The ‘no peek’ kitten was a nice touch. :slight_smile:

I was looking at the Elements → Layout elements well, which currently includes; section; container, etc. Any chance of adding header, footer, main, and aside to this group? Often I find it makes more sense in my head to use the semantic elements to help differentiate the various regions by their roles on the page.

Speaking of ‘roles’, are you planning on adding support for WAI-ARIA roles at some point in the future in Elements?

3 Likes
3

I also like the sound effects @dan makes when he is moving elements around on the screen. Whomp, pow, boom… it helps the web building process. :grin:

Great video showcasing the power yet ease of use that Elements is going to bring.

Also damn, those lampshades should be made out of gold for that price. :face_with_spiral_eyes:

3 Likes
4

Now that you mention it. I’m not sure I have seen any semantic elements. I just assumed they are there. I prefer having access to all of them, but certainly all the elements required for a fully functioning accessible website. This is legally required today, thus the reason I assumed it is baked in.

This is an older article on accessibility, 8 years old, but one I have found to be easy to understand and the data so far has proven to be timeless.

1 Like
5

Great work. I have a few questions…

  1. Can we adjust independent cells within a grid to break the uniform look? Example: 1 cell spanning wider, different margin, padding, etc?
    (a) Also will there be ways of adjusting the Z-Index and offsetting to put elements in a custom position? ie: raise to overlap other items.
  2. Like mentioned in the video I am super eager to see what you have in store for menu bars. Having a lot of control will be a make it or break it feature, as the menu area of a site is so used and important. When do you think we’ll see the look at this? Also, with the menubar any plans to do sticky menu with translucent and background blur effects?
6

Hello, will we be able to participate in the beta version?

7

Great stuff. When you were previewing in Safari a little Realmac notice slid in from the bottom right. Presumably that is something we can turn off?

I was curious about the actual figures for mobile browsing vs desktop and found this.

Based on the latest statistics:

Globally, mobile holds a market share of 59.9%, desktop 38%, and tablets 2.11%

In the US, web traffic is split nearly evenly between mobile (49%) and desktop (48%)

Mobile users tend to spend less time on websites, with an average visit duration ranging from 704 to 775 seconds, compared to desktop users who spend between 996 seconds

As of January 2024, mobile traffic holds a share of about 65.65%, desktop at 32.67%, and tablets at 1.67%

I was surprised at tablet usage. But a roughly 50/50 distribution mobile/desk for web traffic was heartening. But some AI genius came up with these stats and they seem contradictory at times so go figure…

Doing great RealMac team - I’m buying the first round.

1 Like
8

“Doo, doo doo” :heart_eyes:

1 Like
9

Will these grids be able to be configured as you would a Bento styled grid?

10

How embarrassing, I didn’t even notice I was doing that :joy:

1 Like
11

Totally not embarrassing, I do it too during Office Hours sessions. It adds emphases to the presentation. :grin:

1 Like
12

This came up the other day, and I was chatting to @bon about it. It might be that we add a drop down menu in the “section” Element settings so you could specify what type of “section” it is, i.e header, section, article, aside — is that what you’re after?

I’ve personally now looked into ARIA recently (@bon is more knowledgable on this)… but… making sure Elements produces and outputs semantic code is something keen to get right.

I envisage we’ll be able to make greater strides in this area once users get their hands on a beta of Elements!

1 Like
13

As I replied to @bryanrieger above, would it work for you if we added a way to specify what a section was, i.e. header, section, article, aside?

The more details you can give us about how you see this working the better, we can then make sure we meet the needs of what you guys want!

14

Yes, 100% - I’ve covered this in previous developer diary videos, here’s a couple of screenshots (linked to the actual video).

CleanShot 2024-03-06 at 2 .48.12@2x

CleanShot 2024-03-06 at 2 .48.48@2x

Both of those videos are a little old and things have changed since then to be even more powerful, but hopefully that meets the needs of what you were after.

Let me know if there’s a specific layout you wanted to create and I can show how that would be done in Elements!

1 Like
15

Hey Dan, Thanks for getting back.

I’m not sure if a drop-down in section is a good idea. is a semantic tag itself, and I think this would be confusing.

In order to keep the list from becoming unruly, perhaps categorize: “Structure” and “Text”. See below.

HTML Semantic Tags for Structure

  • <header>: The header tag defines content that should be considered the introductory information of a page or section

  • <nav>: The navigation tag is used for navigation links. It can be nested within the <header> tag, but secondary navigation <nav> tags are also commonly used elsewhere on the page.

  • <main>: This tag contains the main content (also called the body) of a page. There should be only one tag per page.

  • <article>: The article tag defines content that could stand independently of the page or site it’s on. It does not necessarily mean a “blog post.” Think of it more as “an article of clothing”—a self-contained item that can be used in various contexts.

  • <section>: Using <section> is a way of grouping nearby content of a similar theme. A section tag differs from an article tag. It isn’t necessarily self-contained, but it forms part of something else.

  • <aside>: An aside element defines content that’s less important. It’s often used for sidebars—areas that add complementary but nonessential information.

  • <footer>: You use <footer> at the bottom of a page. It usually includes contact information, copyright information, and some site navigation.

HTML Semantic Tags for Text

The semantic HTML tags for text are HTML tags that—besides the formatting—also convey the semantic function of the text they contain.

Here are some of the most common examples:

  • <h1> (heading): The H1 tag marks the top level heading. There’s usually only one H1 heading per page.
  • <h2> to <h6> (subheadings): The subheadings of various levels of importance. There can be multiple headings of the same level on a single page.
  • <p> (paragraph): A standalone paragraph of text.
  • <a> (anchor): Used to mark up a hyperlink from one page to another.
  • <ol> (ordered list): A list of items that are displayed in a particular order, starting with bullet points. One <li> (list item) tag contains a single item in the list.
  • <ul> (unordered list): A list of items that do not need to be displayed in a particular order, starting with ordinal numbers. One <li> (list item) tag contains a single item of the list.
  • <li> (list item) tag contains a single item of the list. (Only to be used with the <ol> and <ul> tags.)
  • <q> / <blockquote>: A quotation of the text. Use <blockquote> for long, multi-line quotations and <q> for shorter, inline quotations.
  • <em> (emphasis): Used for text that should be emphasized.
  • <strong> (strong emphasis): Used for text that should be strongly emphasized.
  • <code>: A block of computer code.

Note: We’ve only listed some of the most common semantic HTML tags. You can use many others—like <summary>, <time>, <address>, <video>, etc.—to make the content of your website easier to understand. To discover more HTML semantic elements, check out the list of all HTML tags by W3Schools.

CREDIT: Semantic HTML: What It Is and How to Use It Correctly

16

I don’t think it’s a bad idea to have dropdown to specific the semantic tag for a container element. After all those are just divs with certain classes applied to them. Don’t make it too complicated by adding tons of containers with different functions / semantic tags.

17

I have to disagree. Semantic tags are not classes. Classes are used for CSS references, not naming a div. :slight_smile:

18

We can change the name of the div, so it wouldn’t just be a class name.
So don’t worry, whatever we choose to do, we’ll make sure it’s semantically correct!

1 Like
19

I wouldn’t overload the ‘section’ element within Elements as ‘section’ also has semantic meaning in HTML. What we’re really talking about here, as @pumpkin mentioned, is LOTS of different containers, the most generic of which is the trusty ‘div’, with each of the others; section, header, footer, main, aside, article, and nav providing some additional semantic meaning to themselves as a container within the document as a whole.

So, if you were to use a dropdown, which isn’t a bad idea—as having lots of different containers to choose from in the Element panel would probably be confusing for most folks—then I would use ‘div’ for the generic container, and then allow users to select the more semantic variants from the dropdown menu, if so desired.

Headings, paragraphs, lists, block quotes, etc are all more content specific block elements that folks are already familiar from other applications such as Word, Google Docs, etc—so no additional semantics is require there.

Also, in many ways, the in-line elements; a, b, i, q, s, del, ins, strong, em, mark, code, etc are semantic versions of the generic ‘span’ element, which browsers interpret in specific ways, and add styles and behaviours to by default, and users are also familiar with by convention in almost every app. Of course, b and i should be strong and em, but old habits are hard to break. :slight_smile:

Adding semantic elements to Elements in an intuitive and non-confusing way is tricky design problem. I’m sure you and your team will come up with great initial support which can then be iterated with your users.

Now, if you’re planning on supporting web components that changes the conversation a little as the tag names used can be whatever the user (or component developer) wants them to be. Of course, using semantic elements with web components is still a valid option.

1 Like
20

I might be wrong, but I don’t think this would be a typical RW Elements user.