tried to give the above mentioned Action a go and recognized, that it stops the Externalize (Tim) and Advanced Inline Style (Re)mover (Max) from doing their job(s). Any chance to fix this or do I miss here something basically?
Could you furthermore spent some words on how to use that data-: = : stuff or point me to an example where I can have a look on for a better understanding?
ahhh - might the reason be that both ext-actions do not recognize those new HTML5 elements so they therefore quit the job? So I should drop those lines Tim and Max?
Hi Thomas,
Can you please send me a very simple (the simpler the better) Freeway file that shows the HTML5 and Externalize Actions not working together? I’ve tried a few documents here and they appear to work as expected.
When you say data stuff do you mean the data url scheme?
Regards,
Tim.
On 24 Jul 2012, at 08:14, Thomas Kimmich wrote:
tried to give the above mentioned Action a go and recognized, that it stops the Externalize (Tim) and Advanced Inline Style (Re)mover (Max) from doing their job(s). Any chance to fix this or do I miss here something basically?
Could you furthermore spent some words on how to use that data-: = : stuff or point me to an example where I can have a look on for a better understanding?
Hi Thomas,
Thanks for the clarification. I’m using a slightly modified version of the latest Externalize Action and after a quick test it appears to work OK with Walter’s HTML5 Element Action. I’ll take another look with your sample file when it arrives.
Hi Thomas
The Advanced inline style mover may not work because its doing something pretty dramatic to the item its attached to so anything that effected that tag matt mean it won’t work… if you were to image The actions takes a normal div removes the id if needed, adds a class of your choosing, adds more classes if you want then moves the style to the head if you wish and references the first class to that style. It also allows you to drill down further say an image within a div to add a class to that and move that style to the head again if you wish. This all revolves around the user telling the action what the item is e.g. a div or img tag and moving the styles from that item, so if something changes the tag to an html5 tag then no it won’t find the relevant item and it’s associated styles
I havent tested the inline style mover at all, with the HTML5 actions but I will have a look to see where its all falling down
Hi Walter,
It just occurred to me after reading Max’s last email on this thread that your HTML5 Element Action may be better off using fwTitle to simply rename the item in question rather than cloning it and destroying the original as it currently does. If the Action runs late enough in the publishing process you should be able to pick up all of the changes made by other Actions on the page.
Regards,
Tim.
Hi Walter,
Essentially fwTitle allows you to rename a specific targeted tag to whatever you like. The benefit is that if you change a div to a footer (for example) you can then search for (and find) the footer element in the tag stream later on in the publishing process. You also don’t need to move attributes from your old tag to the new one.
Hi Walter,
Essentially fwTitle allows you to rename a specific targeted tag to whatever you like. The benefit is that if you change a div to a footer (for example) you can then search for (and find) the footer element in the tag stream later on in the publishing process. You also don’t need to move attributes from your old tag to the new one.
New version of the Action is done and posted, thanks again to Tim. Please see if 0.4 does anything differently w/r/t Externalize and the other similar Actions.
Walter
On Jul 24, 2012, at 3:57 PM, Walter Lee Davis wrote:
Thanks, Tim, that’s very helpful!
Walter
On Jul 24, 2012, at 3:35 PM, Tim Plumb wrote:
Hi Walter,
Essentially fwTitle allows you to rename a specific targeted tag to whatever you like. The benefit is that if you change a div to a footer (for example) you can then search for (and find) the footer element in the tag stream later on in the publishing process. You also don’t need to move attributes from your old tag to the new one.
so Tim am I correct if I say that I need your slightly modified version, too? Cause current stat is, that nothing changed - will mean “no externalizing styles” or the other way round:
Externalize is creating the external stylesheet, but keeps FW’s inline styles.
Maybe it’s the language barrier, but are you saying that using the new version 0.4 of my Action, along with Externalize or Advanced Inline Style Mover, there is no change in the issue that the box positioning styles are not being moved out to the external stylesheet or head of the page?
If so, I believe the place to look would be those style-moving Actions, to see if they are only looking for instances of the ‘div’ tag and only acting on those. Their definition of ‘div’ would need to be expanded to include the other block elements described in HTML5.
Walter
On Jul 25, 2012, at 5:24 AM, Thomas Kimmich wrote:
Thanks Walter,
so Tim am I correct if I say that I need your slightly modified version, too? Cause current stat is, that nothing changed - will mean “no externalizing styles” or the other way round:
Externalize is creating the external stylesheet, but keeps FW’s inline styles.
Maybe it’s the language barrier, but are you saying that using the new version 0.4 of my Action, along with Externalize or Advanced Inline Style Mover, there is no change in the issue that the box positioning styles are not being moved out to the external stylesheet or head of the page?
Dead right!!!
If so, I believe the place to look would be those style-moving Actions, to see if they are only looking for instances of the ‘div’ tag and only acting on those. Their definition of ‘div’ would need to be expanded to include the other block elements described in HTML5.
That’s what I assumed somewhere in my entry.
But Tim said something about a modified Externalize action which I don’t have at the moment so I’ll wait for him to tell you more.
Hi Thomas
I have just tested this, using Walters new HTML5 action and I am having no problems using all three actions together.
I added the html5 action to a new page of a new document
then created a div added a blue border, so I could see it.
applied the html5 element action to that element and gave it a new tag of nav
4 applied the Advance inline style mover and adjusted the tag type to nav because thats what the tag is being converted to by the html5 element action and added a class to it. (as per normal)
Applied the externalise action an licked the move all head styles to an external style sheet
The result is the html5 action works correctly along with the externalise and the AISM acton
HTML TAG TYPE = HTML5 element (name) so the use of AISM is (hopefully) clear and fixed now but not Externalize cause in fact it still doesn’t remove the inline styles from HTML5 tags.
Hi Thomas,
I’ve added support within the Externalize Action for the HTML5 elements that the HTML5 Element Action can create; article, aside, canvas, datalist, details, figcaption, figure, footer, header, hgroup, nav, output, section, as well as the existing divs. http://www.freewayactions.com/test/externalize/
Regards,
Tim.
On 25 Jul 2012, at 15:01, Thomas Kimmich wrote:
HTML TAG TYPE = HTML5 element (name) so the use of AISM is (hopefully) clear and fixed now but not Externalize cause in fact it still doesn’t remove the inline styles from HTML5 tags.
I’m extremely hesitant to do everything in one Action, preferring to specialize and combine Actions to meet individual cases, rather than build a one-size fits none super-solution. I would like to see the style movers behave consistently and pull positioning out of all elements that need that treatment. I would also like to be able to target the page stylesheet in an Action, rather than moving all these styles to a second stylesheet or to the head of the page.
A note to the other Action writers, take a look at my current incarnations of the CSS3 Corners and Shadow Action for a way to build styles based on common attributes, rather than persisting with ID-based styles that only apply to single elements, and thus lead to massive duplication in the stylesheet. The names of these generated styles are something only a mother could love, but they do make it clear what is being applied where. Might be something to consider.
Walter
On Jul 25, 2012, at 8:45 AM, Thomas Kimmich wrote:
Hi Walter I must be missing something.
have you added a class based assigning convention to your css3 rounded corners? or did I mistake your meaning?
I thought you were advocating something like the css3 Gradient and RGBa actions were you can use a class rather than an id and therefore add that class to another item… is that what you meant or is it some more cleverer than that.