case insensitivity in the tags

[Daryl Olander <do...@gmail.com>]

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.

Re: case insensitivity in the tags

[Carlin Rogers <ca...@gmail.com>]

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 <do...@gmail.com> wrote:
>
> Overall, I vote we roll back this change.
>
> On 3/20/06, Carlin Rogers <ca...@gmail.com> 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 <do...@gmail.com> 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.
> > >
> > >
> >
> >
>
>

Re: case insensitivity in the tags

[Daryl Olander <do...@gmail.com>]

Overall, I vote we roll back this change.

On 3/20/06, Carlin Rogers <ca...@gmail.com> 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 <do...@gmail.com> 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.
> >
> >
>
>

Re: case insensitivity in the tags

[Carlin Rogers <ca...@gmail.com>]

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?

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 <do...@gmail.com> 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.
>
>