Changes between Initial Version and Version 1 of Ticket #12476


Ignore:
Timestamp:
Mar 19, 2011, 1:20:55 AM (8 years ago)
Author:
bill
Comment:

Yes, Pete, you, and unscriptable have expressed this concern, I can see the argument.

I imagine you don't care too much, but what's the exact description of "standard attribute"? For example, say that an app wants to use <div> instead of <input> so that it can use <script> tags, like:

<div data-dojo-type="dijit.form.TextBox" type="password">
    <script type="dojo/method" event="onChange> ... </script>
</div>

(IIRC you can't use <input> above since it can't have children.)

Are you saying that:

  1. above example should work
  2. type needs to be in data-dojo-props, since it's not a standard attribute on <div>
  3. html5 syntax shouldn't support the <script> tag to setup handlers, just use data-dojo-props
  4. you also want onChange to be specified as a standard attribute <input data-dojo-type=dijit.form.TextBox onChange="myHandler"/>
  5. don't care

PS: updated the above description to link directly to unscriptable's comment.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12476

    • Property Cc John Hann added
    • Property Component changed from General to Parser
    • Property Summary changed from Seems that html5 fastpath option introduced in 1.6 should at the very least parse the name attribute of input elements to make html5 fastpath option parse standard attributes directly on DOMNode, outside of data-dojo-props
    • Property Milestone changed from tbd to future
    • Property Owner changed from anonymous to bill
    • Property Type changed from defect to enhancement
  • Ticket #12476 – Description

    initial v1  
    1 Refs #12470 and the infamous #11490.
     1Refs #12470 and the infamous comment:ticket:11490:60,
    22
    33This is obviously late in the HTML5 discussion but I have to voice that I completely agree with @unscriptable's post on #11490.  I realize the decision has already been made for an "all-or-nothing" use of html5 valid data-dojo-type & data-dojo-props in 1.6 but I hope things can be worked out for 2.0 because as it stands right now, the "fastpath" option is completely unusable to me.  It makes sense to me that native attributes e.g.
     
    2323appearing to only "half-work" because it seems clear that any non-standard HTML attributes shouldn't be parsed because they don't belong in valid HTML5 markup anyways.
    2424
    25 I agree that a performance hole exists in trying to parse an unknown number of attributes on a dom node but I think parsing a known number of native attributes is acceptable and expected.  I also agree with certain instances where we don't want a native attribute to be parsed into a dijit (e.g. ContentPane title attribute). 
     25I agree that a performance hole exists in trying to parse an unknown number of attributes on a dom node but I think parsing a known number of native attributes is acceptable and expected.  I also agree with certain instances where we don't want a native attribute to be parsed into a dijit (e.g. !ContentPane title attribute). 
    2626
    2727The whole benefit behind the dijit templating system for me has always been that I can write an html node and dijify it (which for me means ''extending'' it) if I want to - without having to do anything "weird" (e.g specify attributes twice).  This way if I have a framework that is "html-aware", it's perfect - because I don't have to modify the framework I'm using to be "dojo-aware".