Best practise for hiding variables in HTML tags

Best practise for hiding variables in HTML tags.

I noticed that the Gallery Accordion use the following in a div tag:
yuiConfig=''

Code:

<div id="item1" class="yui-accordion-item yui-accordion-item-closable" yuiConfig='{"alwaysVisible":true, "contentHeight":{"method":"fixed", "height":150}}'>

This was how I did it in the old days; but it seems like that was made a taboo a while back, when page validation of XHTML became important; thus making us store setting in obscure places in tags; which I found CSS style tag "content" was a safe place to hide things til Opera decided to render not only the after and before attributes but the "content" tag itself; which I complained about on deft ears.

I have been battling with a way to make my pages XHTML compliant so they can be verified with w3c validation tool http://validator.w3.org/; this example will not validate; so my question is; what is the best way to handle this problem?

With YUI 3 out; it seems like this problem needs to be addressed better; it seems that even though this page doesn't validate with this custom tag, it shouldn't effect anything else; but not knowing how search engines look at custom tags, its easy to assume too much; especially when web masters want all their pages to validate and now we are asking them to add custom tags that will break their page validation they cling so tightly to.

Ultimately I was hoping that they would add custom tags to HTML elements in the next version HTML; but that did not happen.

Hi Jeff,

In general we discourage the use of custom elements and attributes.

If you are unable to include data as JS for whatever reason, I suggest following the direction of HTML5: http://dev.w3.org/html5/spec/Overview.h ... -attribute.

This boils down to adding a new attribute with the prefix "data-".

Maybe its just http://validator.w3.org/ that doesn't like custom Attributes
Attribute "data-rev" is not a valid attribute

Quote:

In general we discourage the use of custom elements and attributes.

I agree; but as in the case I mentioned; you are not able to get away without using them; so my question is what is the best way to do it.

I ask this question for a specific problem I am trying to work out; I'm working on a Tooltip Widget, using the example code and adding to it, so that I can have images, links and a pop up web browser and other things I'd like; like sound bytes; now as you can image, I need a way to add these to my markup. In my last version I was using Caridy's Bubbling Library, Tooltip and Sound Manager to do this; now the push to 3.x, I decided to wrap this all in one widget; although I must admit I don't have this bubbling idea down in 3.x, I don't see any examples that shed any light on it for me, so like I said, I'm using the Tooltip example for 3.x to start with.

For example: the A tag has several possibilities; I could hide them in href, using a hash #, then parse it out; or use the rel or rev tag; although these will pass validation, is it a best practice; no; but in my case, what is?

I have used all kinds of methods to try to be compliant with the w3c validator; it seems to me that this issue may not be able to be solved from a HTML standpoint, till w3c acknowledges this need and adds it to their validator. Having to tell people who add content to a web site, that they need to use JavaScript to use this feature, when it reality they don't really understand how to use HTML tags, and JavaScript is just a thing that programmers use; isn't much of an option; so I still have to use a tag to hide the information in.

From the stand point of the end user who will use this widget, it needs to be transparent, they just need to know how to pass in parameters; now I'll admit that this can be easily done in a javascript, and then it would be a BP; although it would also be more work for the end user and a learning curve some might not want to take; so maybe doing both would be a better solution; I'd just like to get a few more opinions on the matter.

Hey Jeff,

The code that you see in the gallery is not code produced by YUI Core Team, but from external contributors. In this particular case, "Iliyan Peychev" is the owner of the code, and you can open a ticket for that particular module here:
viewforum.php?f=102

I'm working on porting some of the bubbling library pieces to yui3. I just started with node-accordion (a lightweight accordion version). "bubbling" and "dispatcher" will be the other two components that I will release thru the gallery, but I'm still planing them. Eventually they will make it :-)

About this particular use-case, my approach on that is:

1. Use CSS when possible to define certain visualization rules (eg. height: 150, the use the initial height as the fixed height for the element)

2. Use rel or class to pass thru certain configuration arguments. (eg class="yui-accordion-conf-always-visible")

3. Use data-* for complex data structure like json (eg. data-conf="{value:1}")

Hope this help to clarify some points here.

Best Regards,
Caridy

The fault, though, is not Iliyan but mine. Sorry.

Satyam

YUI Forum (for caridy) escribió:
> Hey Jeff,
>
> The code that you see in the gallery is not code produced by YUI Core
> Team, but from external contributors. In this particular case, "Iliyan
> Peychev" is the owner of the code, and you can open a ticket for that
> particular module here:
> viewforum.php?f=102 <http://yuilibrary.com/forum/viewforum.php?f=102>
>
> I'm working on porting some of the bubbling library pieces to yui3. I
> just started with node-accordion (a lightweight accordion version).
> "bubbling" and "dispatcher" will be the other two components that I
> will release thru the gallery, but I'm still planing them. Eventually
> they will make it :-)
>
> About this particular use-case, my approach on that is:
>
> 1. Use CSS when possible to define certain visualization rules (eg.
> height: 150, the use the initial height as the fixed height for the
> element)
>
> 2. Use rel or class to pass thru certain configuration arguments. (eg
> class="yui-accordion-conf-always-visible")
>
> 3. Use data-* for complex data structure like json (eg.
> data-conf="{value:1}")
>
> Hope this help to clarify some points here.
>
> Best Regards,
> Caridy
>
> Visit Topic:
> http://yuilibrary.com/forum/viewtopic.php?f=18&t=1520&p=4851#p4851
> <http://yuilibrary.com/forum/viewtopic.php?f=18&t=1520&p=4851#p4851>
>
> -----------------------------------------------------------------
> Do not reply to this email. It is a one-way only email address.
> All messages sent to this address will be ignored.
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.698 / Virus Database: 270.14.47/2478 - Release Date: 11/03/09 08:36:00
>
>

Thanks for everyone's help; I now have the answer I was looking for.

I posted a bug report here:
http://yuilibrary.com/forum/viewtopic.php?f=102&t=1526
Although I didn't have an issue with this Widget and was just using it as an example for something I was doing.

I decided that the HTML 5 "data-" is a good standard and I'll use it; one day it will validate; but for now it is a standard; one that I think the Widget designers should follow.

jflesher wrote:

... the HTML 5 "data-" is a good standard and I'll use it; one day it will validate; but for now it is a standard; one that I think the Widget designers should follow.

Implemented in Accordion ver. 1.06:
http://yuilibrary.com/forum/viewtopic.php?p=5176#p5176

We presently have a kind of cumbersome and somewhat inconsistent pattern we follow based on fake attributes for any configuration where custom classes won't suffice.

I hadn't heard about the data- attribute pattern, thanks a lot for pointing that out. Does anyone have any sample code for automatically pulling configuration out of such an attribute and feeding it to the configuration of a widget?

I'm thinking, for MyWidget, which descends from some base class, with MyWidget.NAME = 'foo', the initializer would look for a boundingBox with data-foo-config set, parse its value as JSON, and set the mywidget's attributes from the result.

Hey Peter,

Check these links:
http://ejohn.org/blog/html-5-data-attributes/
http://www.w3.org/html/wg/html5/#custom

Best Regards,
Caridy

rainhead wrote:

I'm thinking, for MyWidget, which descends from some base class, with MyWidget.NAME = 'foo', the initializer would look for a boundingBox with data-foo-config set, parse its value as JSON, and set the mywidget's attributes from the result.

That is one possible solution.

You may also read data-* attributes in MyWidget.HTML_PARSER property.
For each property in HTML_PARSER, read its data attribute and return the value.
In this way, you will have single place, where you load configuration data and you may also load it from different sources - data-* attribute, fake class name, custom attribute, CSS.

You may see both solutions implemented here.

Jeff Flesher