beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <carlin.rog...@gmail.com>
Subject Re: case insensitivity in the tags
Date Mon, 20 Mar 2006 18:51:03 GMT
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 <dolander@gmail.com> wrote:
>
> 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