[Pro] Changing the PageDiv element

Is there a way to change the PageDiv element from a div to an HTML5 element, like a section?


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,
Not without using an Action or post processing the page code once the publish has happened. The PageDiv is a bit of a hidden element as the application doesn’t make reference to it in the site panel or elsewhere in the UI. Here’s a quick page Action that should do what you want;
http://www.freewayactions.com/code/?f=PageDiv-to-HTML5-Element.fwaction

Keep an eye on how it plays with other Actions that may also want to modify or extent the PageDiv. You may need to change the point at which the Action runs in the publishing cycle (line 34) if other Actions try and run after this and can’t locate the PageDiv. You can also add other element types to the action-popup menu on line 5 should you need to.
Regards,
Tim.

On 11 Mar 2014, at 07:06, The Big Erns wrote:

Is there a way to change the PageDiv element from a div to an HTML5 element, like a section?


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi guys,

long thought about this and don’t want to add too much confusion, but I think this operation could end up in invalid code semantically spoken.

The “section” is not a generic container but I think the #PageDIV is and you would end up in nesting them (probably) during your further design process (except the PageDIV is the only section you plan).

Using proper DIVs seems to be old fashioned these days regarding HTML5 but I declare them as well matured and still my strongest weapon for structuring content.

Cheers

Thomas


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I’ve been thinking a long time on it too, Thomas… and I very much welcome
input on this idea.

You’re right - the div is an innocuous structure semantically. It really
has no semantic value… appropriate for visually structuring content but.
Though it’s not even always needed for that It doesn’t hurt anyone, and I
honestly use it all the time. I’m just trying to get this particular one to
work harder for me.

Most of the time, my layouts are super basic and work like this -

  header
  div (content)
  footer

Of course, all this is wrapped in our harmless PageDiv div. Yawn.

I may also insert semantically self-contained content with the page
content. To capitalize on the HTML5 semantic architecture, it’s my
understanding I need to use a sectioning element like or

to indicate this is separable but grouped content.
  header
  div (content)
  --section or article
  ----header
  ----div (content)
  ----footer
  footer

And that is how I understand how to make modular semantic structure. But
what about the page level semantics - I didn’t indicate they were
semantically grouped… should I have?

It seems to turn out that they are understood as an implied semantic group
or section. But implied sounds half-assed to me, so I decide to wrap them
in a sectioning element to make my intention more formal. At least by my
thinking.

  section
  --header
  --div (content)
  --footer

So now I am trying this deliberate approach with regard to my semantic
structure. Not critical maybe, but less half-assed. Maybe.

With Freeway Pro, everything is wrapped in the PageDiv - which is an actual
div. All it does is group the page items and declare their starting
position. Harmless.

But does it have to be a div? Why can’t it also be my semantic initiator?
It can still group the page items and set position, but can’t it also
formalize that its content is related and not random? That no inference as
such is necessary?

I can’t say for sure that this process is bow-tie proper semantics, but I
think it may be. And by making the harmless PageDiv do something besides
sit there like a dummy while I add extra unnecessary code, make me feel
like I’m saving the planet.

And that’s basically my reasoning - but I’d be very excited for some
discussion on it. I can think of potential drawbacks when it comes to
legacy browsers, but those thing just need to die already.

Am I living my semantic dream, or creating a potential nightmare?
Everybody… go!

long thought about this and don’t want to add too much confusion, but I
think this operation could end up in invalid code semantically spoken.

The “section” is not a generic container but I think the #PageDIV is and
you would end up in nesting them (probably) during your further design
process (except the PageDIV is the only section you plan).

Using proper DIVs seems to be old fashioned these days regarding HTML5
but I declare them as well matured and still my strongest weapon for
structuring content.


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Browsers, since the year dot, have always dealt with tags they don’t understand in the exact same manner – by ignoring them and treating them as an unstyled inline element. HTML5Shiv, which is built into Freeway 6 (or hacked in with my HTML5 Action to earlier versions) gets the browsers used to the new block-level elements through a combination of JavaScript and CSS, and is compatible with browsers as creaky-old as IE5. I don’t think you have to worry about the browsers rendering these new block-level elements as anything other than a DIV, which at some level, they are.

Walter

On Mar 12, 2014, at 4:54 AM, Ernie Simpson wrote:

I can think of potential drawbacks when it comes to
legacy browsers, but those thing just need to die already.


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options