[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-08-25 Thread Victor
Sorry for late answer, but there are my few coins on custom attributes.

For XHTML solution exists many years - from the beginning of XHTML itself: 
XML namespaces. Define custom attributes in custom namespace, and the 
resulting XHTML page will be perfectly valid. Example (stripped from working 
system):

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xmlns:a=Ajaxify framework 
xmlns:v=Form navigation and validation framework
head
  titleTitle/title
/head
body
  div id=content/div
  a href=content.html a:target=content a:confirm=Update 
content?Refresh/a
/body
/html


Works in almost any browser (IE6+, Opera 9+, Firefox 3.5+, Chrome 10+, 
Safari 4+ - each and every browser currently used by our developers, testers 
and clients), passes W3C validation. The biggest problem was escaping/not 
escaping semicolon in CSS selectors for different selector engines: 
Prototype 1.6 legacy selector and Prototype 1.7 + NWMatcher allows unescaped 
semicolon like $$(a[a:target]), while Prototype 1.7 + Sizzle requires 
backslash $$(a[a\:target]).

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/prototype-scriptaculous/-/4F_HfwnzTicJ.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.



[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-03-28 Thread RobG


On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote:
 On Mar 26, 2011, at 9:37 PM, kstubs wrote:
  Is it bad, or does it make parsing objects unstable if you append
  custom attributes to an HTML tag?  Lets say I want to keep track of
  a number, maybe a customers ID, so I do something like:

  var div = new Element('div', {'customerID':1234});

The issues are inadvertent overwriting of HTML attributes (so you
can't just use any attribute name, you have to be careful) and IE's
mishandling of DOM element attributes and properties.

To get consistency across browsers, you have to read the attributes
using getAttribute and set them (using code) with setAttribute.
Because IE munges attributes and properties, you should only ever use
DOM properties for HTML atributes.

So you need to be careful to distinguish between the two and only use
the appropriate method, which is why it is usually suggested to not
use custom attributes and to use a data object instead, that way you
only ever use one method that is consistent for all browsers.


  which should result in:
  div customerID=1234/div

Should being the operative word. Note that in IE, the div DOM
element will have a property of customerID, but it will not in
Firefox. That sort of inconsistency is why you should avoid custom
attributes and properties.

Perhaps that issue is fixed in IE 9, but it will be a very long time
before you can ignore all other versions of IE on the web.


 HTML5 lets you do this, and pretty much anything else you like, by  
 adding a data- prefix to the attribute name. Have at it.

HTML5 is not a standard, nor is it widely supported yet.


--
Rob

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.



[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-03-28 Thread T.J. Crowder
 Because IE munges attributes and properties, you should only ever use
 DOM properties for HTML atributes.

This is (as I understand it) one part of the rationale for the `data-`
prefix: There aren't any DOM element properties with those names, and
so IE's broken behavior isn't an issue with them. Yes, it does dump
them on the element instance (if you put a data-foo attribute on a
div, the element instance for that div will indeed have a property
called data-foo on it -- prior to IE9), but it's harmless (though as
always, YMMV).

For instance, try this:
http://jsbin.com/ewade3/2

That works fine on IE6, IE7, (I don't have IE8 handy), IE9, Chrome 10,
Safari 5, Firefox 3.6, and Opera 11 under Windows; and Chrome 10,
Firefox 3.6, and Opera 11 under Linux (Ubuntu 10.04 LTS). I don't have
a Mac handy, but it works in Mobile Safari on my iPhone. :-) The IE
checks show that IE6 and IE7 and presumably IE8 (but not IE9, yay) do
dump the data- properties on the element, but you wouldn't look for
them there anyway since no one else does -- stick to `getAttribute`
(or better yet, Prototype's `readAttribute` because of the *other*
insane things IE does with attributes) and you're fine.

  HTML5 lets you do this, and pretty much anything else you like, by  
  adding a data- prefix to the attribute name. Have at it.

 HTML5 is not a standard, nor is it widely supported yet.

True. But there are two very different aspects to HTML5: Codifying and
standardizing the things browsers were already doing and had been
doing forever, and defining new things for them to do. By its very
nature, the first part is widely supported. :-) data- attributes
fall into that category (every browser I've ever seen supported custom
attributes on elements; HTML5 reins it in a bit). I dare say that that
subset of HTML5 is a better specification for HTML in the real world
than the HTML4.01 standard from over 11 years ago. Of course, the
trick with the HTML5 spec is knowing which bits are which. ;-)

-- T.J.

On Mar 28, 7:23 am, RobG rg...@iinet.net.au wrote:
 On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote:

  On Mar 26, 2011, at 9:37 PM, kstubs wrote:
   Is it bad, or does it make parsing objects unstable if you append
   custom attributes to an HTML tag?  Lets say I want to keep track of
   a number, maybe a customers ID, so I do something like:

   var div = new Element('div', {'customerID':1234});

 The issues are inadvertent overwriting of HTML attributes (so you
 can't just use any attribute name, you have to be careful) and IE's
 mishandling of DOM element attributes and properties.

 To get consistency across browsers, you have to read the attributes
 using getAttribute and set them (using code) with setAttribute.
 Because IE munges attributes and properties, you should only ever use
 DOM properties for HTML atributes.

 So you need to be careful to distinguish between the two and only use
 the appropriate method, which is why it is usually suggested to not
 use custom attributes and to use a data object instead, that way you
 only ever use one method that is consistent for all browsers.

   which should result in:
   div customerID=1234/div

 Should being the operative word. Note that in IE, the div DOM
 element will have a property of customerID, but it will not in
 Firefox. That sort of inconsistency is why you should avoid custom
 attributes and properties.

 Perhaps that issue is fixed in IE 9, but it will be a very long time
 before you can ignore all other versions of IE on the web.

  HTML5 lets you do this, and pretty much anything else you like, by  
  adding a data- prefix to the attribute name. Have at it.

 HTML5 is not a standard, nor is it widely supported yet.

 --
 Rob

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.



[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-03-28 Thread Moo
Hi,

I created a little helper for custom data-attributes:
http://mstuhlmann.wordpress.com/2011/01/10/working-with-custom-data-attributes/

Greets,
mstuhlmann

On 28 Mrz., 12:18, T.J. Crowder t...@crowdersoftware.com wrote:
  Because IE munges attributes and properties, you should only ever use
  DOM properties for HTML atributes.

 This is (as I understand it) one part of the rationale for the `data-`
 prefix: There aren't any DOM element properties with those names, and
 so IE's broken behavior isn't an issue with them. Yes, it does dump
 them on the element instance (if you put a data-foo attribute on a
 div, the element instance for that div will indeed have a property
 called data-foo on it -- prior to IE9), but it's harmless (though as
 always, YMMV).

 For instance, try this:http://jsbin.com/ewade3/2

 That works fine on IE6, IE7, (I don't have IE8 handy), IE9, Chrome 10,
 Safari 5, Firefox 3.6, and Opera 11 under Windows; and Chrome 10,
 Firefox 3.6, and Opera 11 under Linux (Ubuntu 10.04 LTS). I don't have
 a Mac handy, but it works in Mobile Safari on my iPhone. :-) The IE
 checks show that IE6 and IE7 and presumably IE8 (but not IE9, yay) do
 dump the data- properties on the element, but you wouldn't look for
 them there anyway since no one else does -- stick to `getAttribute`
 (or better yet, Prototype's `readAttribute` because of the *other*
 insane things IE does with attributes) and you're fine.

   HTML5 lets you do this, and pretty much anything else you like, by  
   adding a data- prefix to the attribute name. Have at it.

  HTML5 is not a standard, nor is it widely supported yet.

 True. But there are two very different aspects to HTML5: Codifying and
 standardizing the things browsers were already doing and had been
 doing forever, and defining new things for them to do. By its very
 nature, the first part is widely supported. :-) data- attributes
 fall into that category (every browser I've ever seen supported custom
 attributes on elements; HTML5 reins it in a bit). I dare say that that
 subset of HTML5 is a better specification for HTML in the real world
 than the HTML4.01 standard from over 11 years ago. Of course, the
 trick with the HTML5 spec is knowing which bits are which. ;-)

 -- T.J.

 On Mar 28, 7:23 am, RobG rg...@iinet.net.au wrote:

  On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote:

   On Mar 26, 2011, at 9:37 PM, kstubs wrote:
Is it bad, or does it make parsing objects unstable if you append
custom attributes to an HTML tag?  Lets say I want to keep track of
a number, maybe a customers ID, so I do something like:

var div = new Element('div', {'customerID':1234});

  The issues are inadvertent overwriting of HTML attributes (so you
  can't just use any attribute name, you have to be careful) and IE's
  mishandling of DOM element attributes and properties.

  To get consistency across browsers, you have to read the attributes
  using getAttribute and set them (using code) with setAttribute.
  Because IE munges attributes and properties, you should only ever use
  DOM properties for HTML atributes.

  So you need to be careful to distinguish between the two and only use
  the appropriate method, which is why it is usually suggested to not
  use custom attributes and to use a data object instead, that way you
  only ever use one method that is consistent for all browsers.

which should result in:
div customerID=1234/div

  Should being the operative word. Note that in IE, the div DOM
  element will have a property of customerID, but it will not in
  Firefox. That sort of inconsistency is why you should avoid custom
  attributes and properties.

  Perhaps that issue is fixed in IE 9, but it will be a very long time
  before you can ignore all other versions of IE on the web.

   HTML5 lets you do this, and pretty much anything else you like, by  
   adding a data- prefix to the attribute name. Have at it.

  HTML5 is not a standard, nor is it widely supported yet.

  --
  Rob

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.



[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-03-27 Thread kstubs
Perfect, thanks!

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.



[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes

2011-03-26 Thread T.J. Crowder
On Mar 27, 4:41 am, kstubs kst...@gmail.com wrote:
 Data prefix?

Yes. Literally:

div data-customer='1234'

As of HTML5, any attribute whose name starts with data- is valid on
any element; they're ignored by browsers (other than being put on the
elements in the DOM so you can access them) and other tools:
http://www.w3.org/TR/html5/elements.html#embedding-custom-non-visible-data-with-the-data-attributes

It was added because people were doing exactly what you describe,
resulting in invalid documents and the potential for issues where
little-known attributes were inadvertently used, etc.

So for your requirement, you might want a `data-customer` attribute.

HTH,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

-- 
You received this message because you are subscribed to the Google Groups 
Prototype  script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.