Thanks Daryl. I'm fine rolling this back and certainly don't want to step on the design here. If there's any other feedback from committers/devs, please let me know before I do the roll back.
Carlin On 3/20/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > > Overall, I vote we roll back this change. > > On 3/20/06, Carlin Rogers <[EMAIL PROTECTED]> wrote: > > > > Hi Daryl, > > > > Thanks for the input and sharing the history and overall design pattern > > for > > the tags. I appreciate the help and feel it's a reasonable design to > > follow > > the rule of only accepting lower case values, implying our tags are > XHTML > > that can also produce HTML. I also had a concern about performance and > > tried > > to minimize any overhead of converting by not converting if to was a > match > > as lower case or an XHTML document. > > Just curious about your thoughts if someone requests or wants support so > > that we follow the HTML spec as strictly as possible and avoid deviating > > from it, even in terms of case-insensitivity. It would be pointed out > that > > the restriction to lower case values is correct only for XHTML content > > type. > > Also, what are or how many "enums" are there in our tags that would need > > to > > be changed? > > > We support HTML on output just fine. This is actually a tag design issue. > We aren't really either HTML or XHTML (for example, we camel case the > JavaScript event names for readability). In this case, we simply require > all enums to be lower case across the whole API set. The end result is > that > we will always output legal HTML or XHTML, but the tags are not HTML or > XHTML. We are a higher level abstraction. > > It might be pointed out that the restriction to lower case is also correct > in HTML, it's a subset of the valid values because SGML doesn't enforce > casing on either elements or enums. So you can make the argument that we > should support <netui:HTML> and <netui:HtMl> etc. > > I'm not sure if we enforce all of these but: > dir, > the checked, disabled, selected and readonly flags, would need to be > looked > at. > if we expose any of the input "type" fields, button may do this > > I guess there aren't too many of them beyond the form. > > > > Thanks again for the feedback Daryl. I'm good with your suggestion, and > > since you've lead the design of the tags I appreciate this input. > > > > Carlin > > > > On 3/20/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > > > > Carlin, > > > > > > I noticed that you changed the behavior of the form tag (Beehive-1080) > > > **to > > > allow the method to be specified in a case insensitive manner. This > > > doesn't > > > seem like the right thing to do. Today, all of the "enums" in the > HTML > > > tags > > > are lower case as far as I know and they don't do case insensitive > > > comparisions. If you change one, you really should change all of > > > them. The > > > reasons they are lower case is so you can switch back and forth > between > > > XHTML and HTML 4.01. In XHTML these values must be lower case. So if > > you > > > allow "PoSt" you then need to make sure these are lower cased when > > > generating XHTML. The bias of the tags is actually XHTML because > that > > is > > > the long run proper thing for generating HTML. The overhead of all > this > > > case work, and conversion always seemed better handled by a simple > rule > > > that > > > our tags are really XHTML and they will generate the old HTML. This > is > > a > > > design decision on our part, the tags are not the HTML spec. > > > > > > The overall design pattern for the tags is to only accept lower case > > > values > > > for all of the "enums". This is very easy to learn and understand. I > > > think > > > if we change this, then we need to take the overhead of converting all > > of > > > the value into lower case when the property is set and always output > > them > > > as > > > lower case. > > > > > > Overall, I don't think I would make this change. and if we do, we need > > to > > > make it for all of the enums in the tags. > > > > > > > > > > > >
