Using a data-attribute instead of a class?

[jannisg]

Hi!

First of all, I think this plugin is great and I can see myself using this a whole lot when developing front-end templates for various projects.

One thing I think worth discussing is the use of the fixie classname and how this may affect your final output on large templates.

What I mean is this, you might have a lot of fixie classes on elements in your dom which is great in the development stage but when you want to move those templates into a CMS it's time to get rid of all those fixie classes.

Options I see are:

1. Lots of manual clicking and deleting.
2. Regex over the dom removing all instances of "fixie" but this has its own set of issues.

While 2 would be my go-to solution to get rid of those classes the regex could get quite complex because throughout development further classes are likely to be added to fixie elements, and it's not guaranteed that fixie is always the first or last class on an element.

Finding and deleting via regex from all these options would create a pretty complex regex:

<div class="fixie"></div>
<div class="myclass1 fixie"></div>
<div class="myclass1 fixie myclass2"></div>

On line 1 we'd need to remove the class="" as well as fixie the term.
On line 2 we'd only remove the fixie term.
On line 3 we'd remove the fixie term (including the trailing space).

Suggestion: Why not use a data-attribute instead?

Using something exclusive only for use with Fixie would be much easier to match and remove or simply toggle on/off.

<div class="anyclass i want" data-fixie="true"></div>

Now we could safely match the data-fixie="true" term via a regex and 'clean' our HTML document before handover/output/CMS integration without worrying about handing the above mentioned regex matching woes.

Anyway, just some thoughts I wanted to share and see what you guys think of.

[ryhan]

Cool idea!

Two things:

• Stephen suggested using another function call with a series of selectors. https://github.com/rthprog/fixie/issues/5 Tackling the same problem in another way. What do you think?
• In the worst case, removing the script would leave you with some elements with an extra class (which can also be changed).

[jannisg]

I saw that selector series approach post before I posted however I feel that the selectors may work on smaller doms but not necessarily on more complexly structured doms where you might end up with a ton of different #parentElemId .element combinations.

Also thinking about the idea around a data-attr further implementing something along the lines of this could open the door for further interesting options down the line like:

data-fixie="true"       // enables default fixie content on this element
data-fixie="false"      // temporarily disable fixie without removing the attr (for debugging perhaps?)
data-fixie="{ p:1 }"    // 1 paragraph of text
data-fixie="{ w:20 }"   // 20 words
data-fixie="{ s:5 }"    // 5 sentences
data-fixie="{ c:300 }"  // 300 characters

data-fixie="{ p:1, s:2, w:3 }"  
// a series of filler text:
// 1 paragraph followed by
// 2 sentences followed by
// 3 words.
// not sure why anyone would need this but hey… why not, it could be done!

Anyway, I don't want to overcomplicate things with the additional options but using a data attribute would allow those things to possibly be built in easily later with full backwards compatibility to those who might still be using the default data-fixie="true" default method in their documents.

What do you think?

[ryhan]

Good point with the additional options.

Ilteris forked with support for data-fixie (see here https://github.com/icanberk/fixie ), though I feel I would prefer to support both class and data-fixie.

[jannisg]

Wow, that was quick regarding the data-fixie option.

I agree with you though, I don't think the data-fixie init method needs to be the only one. If people prefer (or are more comfortable with) a classname based init approach I see no problem initiating fixie on both, elements with data-fixie attribute (which could have support for options mentioned above) or just the default init using .fixie…

Since it's just a development plugin I don't think we'd need to worry about any overheads that might come from supporting both options.

[ryhan]

Quick update - https://github.com/rthprog/fixie/tree/data-fixie

[wayneashleyberry]

+1 to @jannisg's inline config idea.

not sure how this would fit in, but generally content has a max character / word count. so maybe those config options could be maximums?

[jannisg]

@wayneashleyberry The way I could see this working is this:

// Single Digit: (1) up to 5 words
data-fixie="{ w:5 }"

// Range: 3 - 9 words
data-fixie="{ w: [ 3,9 ] }"

// ! Exactly 5 words
data-fixie="{ w: '5!' }"

The latter obviously depends on how this would be parsed, if we treat is as an object then the whole x! to signify exactly would only work if we make it a string which would be a little annoying to type out every time I reckon when what we actually want to get out of this is a number, we could of course run parseInt( "5!" , 10 ) and still get 5 returned but it doesn't really feel that elegant a solution.

I suppose one could use a range with two equal values? data-fixie="{ w: [ 5,5 ] }" but that seems a bit clumsy.
Or you could use data-fixie="{ w: [ 5 ] }" so if type is array but only 1 value, then use exact count formula?

But in general terms, barring a decision on the exact number method, we could apply the rule:

Given data-fixie="{ w: data }":

If the type of data is a number, then we assume it is an up to call.

If the type of data is an array, then we assume it is a range.

If the type of data is an array with only 1 value, then we assume it is an exact call.

or

If the type of data is a string, we assume it is an exact call.

What are your thoughts on this type of handling?

[wayneashleyberry]

hey @jannisg

the inline config is actually starting to feel a bit verbose to me, especially adding all of those options

maybe fixie itself could have a config where you could define content lengths per element?

fixie.config({
    p: { words: [10, 20], case: 'uppercase' },
    blockquote: { characters: [100], language: 'arabic' },
    pre: { characters: 123, language: 'javascript' }
});

prefer this because it keeps the markup cleaner and allows for potentially more options :)

[jannisg]

@wayneashleyberry Yes, I like the idea of a central config for fixie. Though I would think that this global config would only be good for setting the defaults while element specific data-fixie="data" settings can still override things as needed.

The simple reason being, in any given layout I may generally want each paragraph to be X many words but there will usually be exceptions to this rule where all of a sudden my document has a paragraph I need to fill that needs only half the words or twice as many…

So while I agree that setting defaults is by far a better option that setting the same data setting on every single element, it should be an additional config possibility rather than the only way of setting this data.

Then again you never said not to also have element specific overrides so what am I talking about :)

Another option would be to create global aliases for config sets.

fixie.config {
    sets : {
        small  : { w: [ 20,40 ] },
        medium : { s: [ 3,4 ] },
        large  : { p: [ 1,3 ] }
    }
}

which could then be used as: data-fixie="small".

That might be quite nice too.

[wayneashleyberry]

haha, I totally agree with you @jannisg. you should be able to override the global config per-element.

maybe selectors would be better?

fixie.config({
  p: { words: 32 },
  '.story p': {words: 1337}
});

[jannisg]

Nice idea, though —and this is of course just my personal preference— I like being able to change the classes and markup in the dom separately to JS configurations.

If I change .story to .video-post for example I would now have to also update my JS config for fixie whereas with my sets approach I could rename those classes as I please without ever affecting anything but the markup + CSS while the JS config stuff lives exclusively in the data-attr of the element.

Another potential problem with the selector bound config would be that let's say you add another .story container somewhere on another page (or perhaps even on the same page) in which you do not want the filler copy but the classname should stay, the you'd be forced to either override on a per element basis using data-fixie="false" or rethink the selector string you pass into fixie.config to find one that is unique to one element.

Ultimately this of course comes down to personal coding styles and preferences, and to be honest I don't see a reason why we couldn't include both as options of use in the plugin… I just think the selector based approach might get a little restrictive and too dependent on your markup not changing.

[wayneashleyberry]

mmm, very valid points @jannisg,
@rthprog do you want to chip in?

[ryhan]

rthprog/fixie@f5fe164

Fixie will now target child elements, but will never overwrite content.

Example

<body class="fixie">
<p></p>
<p>Hello, here's a link <a></a>
</body>

will cause fixie to add content to the first <p> tag, and the <a> tag.

It will not override the "Hello..." text.

Back to the Original Example

<div class="fixie"></div>
<div class="myclass1 fixie"></div>
<div class="myclass1 fixie myclass2"></div>

The number of mentions of fixie can be reduced by simply adding fixie to a parent element (even <body> for that matter). Only empty elements will be filled with content.

In the end, getting rid of fixie becomes a matter of removing it from a few elements, and removing the script itself.

In regards to data-fixie

I like the idea, especially the ability to further add bounds on length in the future. I believe the right solution is to support both class and data-fixie.

That said, I do believe that this update significantly reduces the number of times fixie would be inserted into a document. Thoughts?

[wayneashleyberry]

@rthprog I'm super happy with how fixie handles child elements and the new init method as well

i'm mostly using it directly on elements ( fixie('p, img, a, article'); etc )

but agreed, data-fixie would be nice as well :)

I think this thread has become more about other config options though, word counts etc

[jannisg]

@rthprog I think the thought behind parent element class targeting empty child elements is good, though, and this is an admittedly contrived example, would we still need a way to selectively disable empty child elements from time to time?

Given this markup as an example, what would the body.fixie class fill?

<body class="fixie">
    <div class="wrap">

        <header>
            <h1>
                <a href="#" class="logo"><img src="logo.png" alt="" /></a>
            </h1>
            <nav>
                <ul>
                    <li><a href="#"></a></li>
                    <li><a href="#"></a></li>
                    <li><a href="#"></a></li>
                    <li><a href="#"></a></li>
                </ul>
            </nav>
        </header>

        <div class="main" role="main">
            […my content…]
        </div>

        <!-- Blank .push for the sticky footer, see: http://ryanfait.com/sticky-footer/ -->
        <div class="push"></div>
    </div>

    <footer>
        […footer content…]
    </footer>
</body>

Would fixie fill only direct children from the selector it was applied to, so in the above example nothing would be filled? Or would fixie try to fill the empty .push element for instance?

[eskimoblood]

@jannisg It will fill all empty child, sub child, sub sub childs and so on. So in your example all the anchors in the list will be filled also div with the class push

[jannisg]

@eskimoblood Right, in which case I think this is not a very robust approach… think of people using the "icon module" for example which would rely upon empty elements like this:

<i class="icon icon-large icon-tweet"></i>

An then use CSS to apply the correct sizing and background image (or content: "";) to the element.

I understand that you'd obviously use a much more fine grained approach then putting a single class on the body element but my point remains, there is a need for some kind of manual off switch in my opinion.

[ryhan]

Suggestion: As an alternative to data-fixie=false, what about a class no-fixie that switches off fixie unless a child is specifically targeted?

[eisenivan]

@rthprog no-fixie would be a great addition in my opinion.