beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryl Olander" <dolan...@gmail.com>
Subject Re: case insensitivity in the tags
Date Mon, 20 Mar 2006 18:35:15 GMT
Overall, I vote we roll back this change.

On 3/20/06, Carlin Rogers <carlin.rogers@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 <dolander@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.
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message